Archive for ◊ December, 2011 ◊

[TechBlog] Stack Allocation
Sunday, December 18th, 2011 | Author:

[Originally posted on techblog.rosedu.org]

Stack space is the part of each process’ virtual memory where function arguments and return addresses are stored, along with local variables declared within a function. Usually, the stack begins at the high address space of the virtual memory and grows down.

At every function call, a new stack frame is created on the stack. It contains the parameters sent to the function, the return address (the address of a code in the caller function) and the locally declared variables.

For each function call, the SP/ESP (Stack Pointer/Extended Stack Pointer) is set so the stack has a big enough size to accommodate local variables. For example, in theory, if you have a local char variable and an int variable, the SP should be set (moved) to 5 bytes.

In practice, the compiler will allocate stack space a little different than expected. It will allocate local variables space in increments of a fixed size, so sometimes having two int variables or three int variables will be the same.

As an example, gcc will allocate in increments of 16 bytes. Let’s make an experiment… we take a simple C program and turn into assembly code.

The C file looks something like this:

int main(void)
{
	int a=1, b=2;
	return 0;
}

The variables must be used after declaration or they will be ignored by the compiler.

The resulting assembly code (with an gcc -S) looks like this:

main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	movl	$1, -4(%ebp)
	movl	$2, -8(%ebp)
	movl	$0, %eax
	leave
	ret

Notice the subl instruction that clears 16 bytes in the stack space by decrementing the ESP. Those 16 bytes are enough for four 32bit integers. If you have 1,2,3 or 4 local variables declared (and used), you get those 16 bytes.

If we declare 5 integers, the allocated space will now be 32bytes. Same thing for 6, 7, or 8. If we have 9 to 12 integers the compiler will allocate 48 bytes. An so on…

What if we don’t only have integers? Let’s add some chars.

int main(void)
{
	int a=1, b=2;
	char c=3, d=4;
}

Result:

main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$16, %esp
	movl	$1, -8(%ebp)
	movl	$2, -12(%ebp)
	movb	$3, -1(%ebp)
	movb	$4, -2(%ebp)
	movl	$0, %eax
	leave
	ret

The function would need 10 bytes, but still gets 16. So the allocation is in increments of 16 bytes no matter what.

The question remains why? It has to do with the cache alignment. The compiler will try to structure the memory usage so that the executed code can be easily fetched from memory and cached. A correct alignment will cause minimum cache misses for memory access.

Credits to SofiaN for help with initial observations and tests.

[CCIELab] Output manipulation in Cisco IOS
Wednesday, December 14th, 2011 | Author:

[Originally posted on ccielab.ro]

Unlike Linux’s iptables, Cisco’s filtering via Access Control Lists sometimes has hidden behavior.

Let us test how ACL filtering works using the following topology. We assume that we have Layer 3 connectivity via static routes. We will apply ACLs on the outbound direction of F1/0 on R2 (we want it to be somewhere in the path from R1 to R3)

3r

With no ACLs applied anywhere, all traffic will flow.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent

Let’s start with the basics and make a classic standard access list that denies R1′s loopback.

R2(config)#access-list 42 deny host 1.1.1.1
R2(config)#int f1/0
R2(config-if)#ip access-group 42 out

The loopback on R1 is blocked…

R1#ping 3.3.3.3 source 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

… but so is any other traffic that goes out of R2′s F1/0.

R1#ping 3.3.3.3 source F0/0
U.U.U
Success rate is 0 percent (0/5)

The first rule of Cisco’s ACLs is that there is an implicit deny (ip) all (all) rule at the end of every ACL. But this is not visible anywhere. You have to know it.

R2#sh access-lists
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

But if that ACL is empty? What if you apply an access list that does not contain any rules (was not declared)?

R2(config)#int f1/0
R2(config-if)#ip access-group 28 out
R2(config-if)#do sh access-lists
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic passes. The inexistent ACL applied on an interface is ignored. But this is because you can’t have an empty classical (numbered) ACL. What if you do the same thing with a named ACL?

R2(config)#ip access-list standard EMPTY_ACL
R2(config-std-nacl)#exit
R2(config)#do sh ip access-list
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Standard IP access list EMPTY_ACL
Extended IP access list BLOCK_HTTP
R2(config)#int f1/0
R2(config-if)#ip access-group EMPTY_ACL out

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic is still not filtered. So, the rule is that a empty (inexistant or deleted) ACL is ignored by the interface filter.

One more ACL applied on R2 with a deny all rule (no traffic should pass out of F1/0).

R2(config)#ip access-list standard DENY_ALL_ACL
R2(config-std-nacl)#deny any
R2(config-std-nacl)#do sh ip access
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Standard IP access list DENY_ALL_ACL
10 deny any (8 matches)
Standard IP access list EMPTY_ACL
10 deny any (8 matches)
Extended IP access list BLOCK_HTTP
R2(config-std-nacl)#int f1/0
R2(config-if)#ip access-group DENY_ALL_ACL out

Ping form R1 is filtered.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

Since no traffic should go out the interface, a ping from R2 to R3 should also fail, yet it doesn’t.

R2#ping 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/44 ms

As a final rule, traffic generated by a router is never filtered by an ACL applied any interface of that router.