benlyn has quit [Remote host closed the connection]
benlyn has joined #osdev
benlyn has quit [Remote host closed the connection]
Gurkenglas has joined #osdev
foudfou has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Gurkenglas has quit [Ping timeout: 250 seconds]
edr has joined #osdev
joe9 has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
Left_Turn has joined #osdev
srjek has joined #osdev
dude12312414 has joined #osdev
pebble has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
eddof13 has joined #osdev
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
craigo has joined #osdev
<immibis>
the only spectre solution that actually works will be some kind of cache segregation
<immibis>
which won't happen
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
qubasa has quit [Remote host closed the connection]
Vercas has quit [Ping timeout: 240 seconds]
Vercas has joined #osdev
pebble has quit []
<gorgonical>
How is it going on this Thursday afternoon my kernal developers
danilogondolfo has quit [Quit: Leaving]
<gorgonical>
I have an actual question, too: why does musl ld.so use mmap MAP_FIXED to change permissions of a region and not mprotect?
<zid`>
post your advent day 7 or riot
<gorgonical>
I have difficulty completing the aoc. I have tried at least three times and never finished it
<zid`>
MAP_FIXED is essentially dup2 isn't it
<zid`>
nobody *finishes* aoc
<zid`>
you get 2 weeks in then give up
<gorgonical>
oh then I have done that several years now
<gorgonical>
lol
<gorgonical>
but yes map_fixed is basically the mmap variant of dup2 I think
<gorgonical>
musl's ld.so uses it to map in rw segments because it already maps all the segments as ronly so it has to change some to rw
<gorgonical>
I have heard glibc's does this too
<gorgonical>
but mprotect does exactly the same thing as map_fixed with fd=-1 with much less overloading
<zid`>
overloading?
<gorgonical>
mmap is about mapping some data into memory. map fixed says put it where I want. map fixed with fd -1 says actually dont map new memory in, just change the mappings of old memory
<gorgonical>
It does a new kind of job, one that mprotect already did
<bslsk05>
github.com: Onyx/kernel/kernel/binfmt/elf.cpp at master · heatd/Onyx · GitHub
<heat_>
yess bss sections have a defined length
<heat_>
all sections do
<gorgonical>
of course
<gorgonical>
just making sure I still have my head on right
<zid`>
no bss is infinite length
<zid`>
nobody has managed to map one yet, we're still trying
<gorgonical>
but if you have an in-memory so when you mmap it you *could* file-back the bss
<gorgonical>
but then nobody can reuse it lol
<zid`>
I have no idea what any of those words means
<zid`>
bss is just the part of the C program where the statics are allocated
<zid`>
done
<gorgonical>
if your .so is on an in-memory fs
<zid`>
how are you supposed to reuse it?
<gorgonical>
then you could just actually put the bss where the elf lives, in memory
<zid`>
it doesn't exist on the fs
<heat_>
you can't file-back the bss because it can be larger than the file
<zid`>
that's the point of the bss
<zid`>
it's "this area is just 0s, so I'm only recording the size"
<zid`>
then you mmap some space for it, p->phr_memsz or whatever it is, and memset it to 0, or use a real OS that returns zero'd memory
<gorgonical>
I am just generating bad ideas, but you could totally allocate the bss space directly after the end of the elf in memory, so when you mapped it in you could just do one big contiguous map
<zid`>
rather than _filesz like .data
<zid`>
yes, you could, but then that's not bss
<gorgonical>
because then it would be shared between all uses of that .so which is not correct
<zid`>
and you can do it anyway with .data : { .data (*.o); .bss (*.o); }
<zid`>
which is how you make rom images
<gorgonical>
yes exactly
<zid`>
it's pointless unless you are infact, nommu
<heat_>
gorgonical, no it wouldn't??
<heat_>
MAP_PRIVATE bud
<zid`>
I don't understand how you intend to reuse data
<gorgonical>
yeah but then you have to do some copy on write shit or you have to allocate anonymous backings anyway
<zid`>
.bss is for *statics*, not immutable stringibois
<zid`>
exactly
<zid`>
now we're eating loads of page faults for no reason, yay
<heat_>
MAP_PRIVATE does copy on write shit per the POSIX spec
<zid`>
just fukin allocate it
<zid`>
like a real woman
<heat_>
you'd eat exactly as many page faults as you would, normally
<zid`>
none
<zid`>
is how many I'd normally eat
<gorgonical>
why does posix specify how my os has to implement map_private?
<heat_>
page faults are yummy have you tried them?
<heat_>
what
<gorgonical>
that's what you just said
<gorgonical>
to be posix-compliant my OS *must* do COW for private mappings?
<heat_>
oh sorry
<heat_>
mmap(2) is not quite like POSIX there
<heat_>
it just says "If MAP_PRIVATE is specified, modifications to the mapped data by the calling process shall be visible only to the calling process and shall not change the underlying object."
<gorgonical>
that makes more sense
<gorgonical>
obv cow is faster but certainly not the only way to accomplish that
<heat_>
>The MAP_PRIVATE function can be implemented efficiently when memory protection hardware is available. When such hardware is not available, implementations can implement such "mappings" by simply making a real copy of the relevant data into process private memory, though this tends to behave similarly to read().
<heat_>
this implies you want CoW
<heat_>
as was done always
<zid`>
this is the "I would like cow behavior" flag
<gorgonical>
moo moo
<gorgonical>
of course
<heat_>
i'm not sure if MAP_PRIVATE was ever implemented in a real UNIX without CoW
<gorgonical>
well then in what way is an anonymous mapping not just malloc? you can specify protections for it?
<zid`>
that is infact
<zid`>
how you implement malloc
<zid`>
malloc ain't a syscall baby, it needs something behind it to back it
<gorgonical>
sure sure
<gorgonical>
but now you can argue that direct use of mmap like this is a code smell
<gorgonical>
stinky
<heat_>
what
<zid`>
why?
<zid`>
why would you use the mmap wrapper with byte tracking
<zid`>
if you're not tracking bytes
<heat_>
also IN WHAT WAY IS ANONYMOUS MEMORY NOT A FILE MAPPING WITH /DEV/ZERO
<heat_>
EXPLAIN THIS LIBERAL DEMOCRATS
<gorgonical>
it is only if you don't have write
<zid`>
mmap pool allocators are the coolest innovation that C++ can't afford
<heat_>
IT'S ALWAYS THE SAME
<zid`>
"whaa I have to use new"
q3lont has quit [Ping timeout: 256 seconds]
<heat_>
NICK CLEGG CAN'T EXPLAIN WHY HIM AND HIS BUDDIES CREATED ANONYMOUS MEMORY, WHEN FILE MAPPINGS OF /DEV/ZERO WERE JUST FINE
<gorgonical>
this is a limitation of the design I've chosen then
<heat_>
what are you on about
<gorgonical>
my mmap allocator puts anon mappings at the top of the heap
<gorgonical>
and it grows toward the heap's end, so they could collide if the heap's not big enough
<gorgonical>
this is possible because applications get a pre-alloced heap
<zid`>
what is
<zid`>
the heap
<zid`>
the heap is an abstraction on *top* of this decision, not below it
<gorgonical>
the data segment
<zid`>
that's an ELF abstraction
<heat_>
>my mmap allocator puts anon mappings at the top of the heap
<heat_>
>and it grows toward the heap's end, so they could collide if the heap's not big enough
<heat_>
how? if it's already at the top?
<gorgonical>
like in zid`'s diagram, if map and brk keep growing they'll hit each other eventually
<zid`>
that's called
<zid`>
running out of memory
<gorgonical>
yes
<zid`>
you can't do anything about that
<zid`>
for.. obvious reasons
<gorgonical>
indeed you cannot
<heat_>
right
<gorgonical>
no demand paging means you get some memory at the beginning of your life and it's yours until you die
<gorgonical>
and that's all you get basically
<gorgonical>
though i guess applications could do some exciting tricks to acquire new memory, like abusing the in_mem_fs to create files and then map thoes in
<zid`>
heat_: Can I have enough dimms to allocate 48 bits of memory pls
<bslsk05>
modarchive.org: The Mod Archive v4.0b - A distinctive collection of modules - longstabben - longstab.xm (XM)
* kof123
blinks
<ghostbuster>
do the brk/sbrk posix syscalls depend on memory segmentation? does that mean they don't work on ARM (because no segmentation)
<ghostbuster>
or aarch64 if you prefer
<Cindy>
there's a mistake in the m68000 family programmer book
<Cindy>
where BFFFO and BFEXTU has the same opcode format
<Cindy>
like wtf
<Cindy>
i keep flipping between pages to realize the opcode format is the EXACT same between 2 instructions, even though it shouldn't be
<nortti>
ghostbuster: no. why would they?
<ghostbuster>
a lot of the descriptions of sbrk i've found say it manages memory by resizing the "data segment"
<nortti>
ah, that's a different sense of "segment"
<ghostbuster>
is it the same segment as in "segmentation fault"
<nortti>
yeah
<nortti>
to simplify a bit, in early unix the program was split into text segment (code) and data segment (data). by default the data segment would be only as big as needed to hold the .data section of the executable
<ghostbuster>
those segments were initially implemented with the help of the segment registers on x86?
<nortti>
no. this was on the pdp-11 which (again, to simplify a bit) has a similar but different mechanism that's also called segments
<nortti>
the whole segment thing became no longer relevant once unix was ported to 32-bit architectures with paging
<nortti>
it's just stuck around in some terminology
<ghostbuster>
where do the funky x86 registers come in
<zid`>
nowhere
<zid`>
unless you want them to
<zid`>
do you want them to?
<heat_>
there was never an x86 UNIX with segmentation
eddof13 has quit [Quit: eddof13]
<heat_>
xenix already used the MMU
<nortti>
I *think* there was a 286 port of xenix that used segments, but don't quote me on that
<heat_>
286? that doesn't sound very plausible, sysv was 32-bit only
<ghostbuster>
my angle is to learn about malloc internals, from a security perspective
craigo has quit [Ping timeout: 255 seconds]
<zid`>
286 had PROTECTION
<zid`>
go read the source then?
<ghostbuster>
thanks
<zid`>
glibc malloc, jemalloc,etc
<zid`>
are all just.. out there
<nortti>
heat_: early xenix was v7-based, not sysv
<ghostbuster>
yeh, just trying to understand the history of brk
<ghostbuster>
i guess it has nothing to do with SS/DS/etc so I don't need to worry about those