Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Layout of a Program in C

web.eecs.utk.edu

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Memory Layout of a Program in C

#31

Post by adito »

comex wrote: post #24
adito wrote: post #22

A noob question here. As it turns out, the first 8 pages on our hydra machines are void. This means that trying to read to or write from any address from 0 to 0xffff will result in a segmentation violation. I have similar issue. I was following "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux"[0]. And decided to put the start of .text section at virtual address 0x0: ; tiny.asm BITS 32 org 0x0…

You may be running afoul of mmap_min_addr: https://wiki.debian.org/mmap_min_addr It's a security feature meant to protect the kernel from null pointer attacks.

Thanks. It's been bugging me for a while.

Re: Memory Layout of a Program in C

#32

Post by dathinab »

monocasa wrote: post #2

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

Also very important with 64 bit there is a lot more room to play with. Also there is address layout randomization which at last on 64bit every program _should_ be compiled with.

Also on 64 bit isn't the last memory page like the first unmappable (I think at last on linux it is).

Lastly isn't there a region of unmapable virtual address space on 64 bit in the middle of the virtual address space due to the chips which are doing mmap not handling full 64bit of virtual address space?? I sadly can't find any info about this but I remember having read about it before? Maybe I mixed something up.

Re: Memory Layout of a Program in C

#33

Post by masklinn »

dathinab wrote: post #32
monocasa wrote: post #2

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

Also very important with 64 bit there is a lot more room to play with. Also there is address layout randomization which at last on 64bit every program _should_ be compiled with. Also on 64 bit isn't the last memory page like the first unmappable (I think at last on linux it is). Lastly isn't there a region of unmapable virtual address space on 64 bit in the middle of the virtual address space due to the chips which a…

> Lastly isn't there a region of unmapable virtual address space on 64 bit in the middle of the virtual address space due to the chips which are doing mmap not handling full 64bit of virtual address space?

Yes. ARM64 currently has a 48b address space split in two ranges (0 to 00007FFFFFFFFFFF and FFFF800000000000 to FFFFFFFFFFFFFFFF), ARMv8 requires 48b and allows 52 but apparently the sizes of the userspace and kernel regions are configurable (though limited by the chip aka you could reduce the size of the kernel space down from 48b but can't increase it).

Re: Memory Layout of a Program in C

#34

Post by simias »

emilfihlman wrote: post #16
monocasa wrote: post #2

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

man syscalls disagrees with you, brk is there just fine.

They probably mean that it's no longer used by the allocator which will be using nmap instead (although obviously that will depend on what allocator you use). The syscall itself is going nowhere.

Re: Memory Layout of a Program in C

#35

Post by floor_ »

Fun trick you can do, at least on windows, it to append your data to the program's file with the offset as the very last thing you write so that it's easy for it to find. I've run various programs like this through virus scanners and the only type to false flag it were the "neural network ai" scanners. So that shouldn't be a problem.

Re: Memory Layout of a Program in C

#36

Post by mschuster91 »

floor_ wrote: post #35

Fun trick you can do, at least on windows, it to append your data to the program's file with the offset as the very last thing you write so that it's easy for it to find. I've run various programs like this through virus scanners and the only type to false flag it were the "neural network ai" scanners. So that shouldn't be a problem.

Works in bash, too (https://makeself.io/), as well as in PHP (https://www.php.net/manual/de/function.halt-compiler.php).

Re: Memory Layout of a Program in C

#37

Post by rayiner »

comex wrote: post #25
rayiner wrote: post #14

Earlier quoted context omitted.

The issue is that C does not work that way on modern machines. Not that old Alpha machines had doubleword aligned pointer and no byte or word load instructions. So indexes into the array had to be multiples of 4. More important, aliasing rules preclude treating memory like one big array: https://gist.github.com/shafik/848ae25ee209f698763cffee272a5... . C99 and newer go to some lengths to permit the optimizer for trea…

Nitpick: The same rules were also present in C89.

Thanks for the correction!

Re: Memory Layout of a Program in C

#38

Post by jdmoreira »

floor_ wrote: post #35

Fun trick you can do, at least on windows, it to append your data to the program's file with the offset as the very last thing you write so that it's easy for it to find. I've run various programs like this through virus scanners and the only type to false flag it were the "neural network ai" scanners. So that shouldn't be a problem.

Can you give me an example of the C code with the offset. I'm not sure I follow but I'm interested in trying this out.

Thanks

Post reply on HN