21–30 of 38 posts
That's rather fortunate, instead. Programming (esp. in C) under an operating system/hardware architecture that does not provide this protection is a real pain. Memory protection is a feature that is meant primarily to help developers (to say nothing about security).
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
;
; (the same as the one in the teensy elf tutorial)
;
My question: Is my issue because I create an elf that has .text section inside that void region? Is this void region documented somewhere? What purpose does it serve?
[0]: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht...
Earlier quoted context omitted.
brk() is undefined behavior if mmap is ever called.
Can you post a definite source supporting this?
Source: run strace on almost any useful Linux command (e.g. ls, sort, which, ...), you'll see it makes calls to both brk() and mmap().
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…
https://wiki.debian.org/mmap_min_addr
It's a security feature meant to protect the kernel from null pointer attacks.
Earlier quoted context omitted.
Yes you can implement C in other ways (I've worked on a C JIT that abstracts from this flat memory model, for example) but come on we all know this is how C works on most machines most of the time and they shouldn't need to add a lot of disclaimers that it could theoretically be done a different way when they're just trying to raise awareness of how things work in practice.
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…
Earlier quoted context omitted.
strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.
brk() is undefined behavior if mmap is ever called.
Earlier quoted context omitted.
Can you post a definite source supporting this?
There isn't one, because it's wrong. Source: run strace on almost any useful Linux command (e.g. ls, sort, which, ...), you'll see it makes calls to both brk() and mmap().
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.
strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.
Earlier quoted context omitted.
strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.
Does malloc() use brk() or mmap()? https://stackoverflow.com/questions/30542428/does-malloc-use... there is a mallopt named M_MMAP_THRESHOLD, in general: If requested memory is less than it, brk() will be used; If requested memory is larger than or equals to it, mmap() will be used;
On OpenBSD, DragonflyBSD, NetBSD and OSX:
> The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management.
On FreeBSD:
> The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. They are deprecated and not present on the arm64 or riscv architectures.
It's also somewhat discouraged on Solaris:
> The behavior of brk() and sbrk() is unspecified if an application also uses any other memory functions (such as malloc(3C), mmap(2), free(3C)).
Earlier quoted context omitted.
strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.
Depends on system. In FreeBSD brk() syscall doesn’t even exist on newer platforms, such as RISC-V or aarch64.