<Mondenkind>
but instead we get canaries and cfi junk and whatever, and nobody enables it anyway
<heat>
>just as fast
<heat>
nope
<Mondenkind>
why not?
<heat>
because it's simply not as fast
<heat>
in fact, it's not abi compatible
<heat>
see x86 and shadowcallstack
<Mondenkind>
methinks we are thinking of different mechanisms, then
<heat>
it's fast on arm64 because you can just ffixed-x18 your way into manipulating the shadow stack ez pz
<Mondenkind>
my proposed mechanism: rbp is datastack, rsp is callstack. You push/pop current rbp onto rsp right after the return address
<heat>
but that's not abi compatible
<Mondenkind>
it's fast because you still get ras, prolog is the same size, etc.
<Mondenkind>
and you can call other people while maintaing abi--they'll just think you happened to only use 8 bytes of stack space
<Mondenkind>
and they'll push data onto the 'return' stack, meaning they're still vulnerable, but can't really do anything about that
<heat>
and you break stack frame-based unwinding in the process
<Mondenkind>
-fomit-frame-pointer is already a thing, and the world hasn't exploded
<Mondenkind>
because of fancy dwarf shit
<heat>
fwiw its quite possible push and pop are quite a bit faster than manual stack allocation + store
zoey has joined #osdev
zoey has quit [Client Quit]
<Mondenkind>
not really
<Mondenkind>
the basic problem is that if you say push x; push y, it's hard to do x and y in parallel
<Mondenkind>
because the first push modifies the stack pointer, and the second push reads it
<Mondenkind>
x86 impls have a fancy stack engine and renamer to deal with this
justache has joined #osdev
<Mondenkind>
so it doesn't suck as hard
<Mondenkind>
but there's no way it's faster than mov [rbp - 16], x; mov [rbp - 24], y
<Mondenkind>
note compilers basically never use push/pop
<heat>
then idk man
<heat>
try it
<Mondenkind>
oh it's not strictly compatible because you could have calls going the other way
<Mondenkind>
so probably have a tls for the data stack pointer, and multiple entry points
nyah has quit [Ping timeout: 248 seconds]
<Mondenkind>
ok one thing I'm actually not sure about is signals. Obviously you can make them work, but the c runtime has to be aware of them to swap out the new stack. Is there a way to do it that's binary-compatible with legacy c runtimes?
<Mondenkind>
and I guess the same goes for any userspace implementation of green threads/coroutines/whatever. I don't think there's any hope for handling the latter without patching, though
<Mondenkind>
ugh ... I guess you can duplicate _everything_ and use use GNU_IFUNC
tacco has quit [Remote host closed the connection]
[itchyjunk] has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #osdev
<mjg>
static int
<mjg>
mountnfs(struct nfs_args *argp, struct mount *mp, struct sockaddr *nam, char *hst, u_char *krbname, int krbnamelen, u_char *dirpath, int dirlen, u_char *srvkrbname, int srvkrbnamelen, struct vnode **vpp, struct ucred *cred, struct thread *td, int nametimeo, int negnametimeo, int minvers, uint32_t newflag, char *tlscertname, int aconn)
<mjg>
{
<mjg>
:[
<mjg>
winner
<CompanionCube>
that's a lot of arguments
<mjg>
probably a result of a sigma grindset
weinholt has quit [Ping timeout: 255 seconds]
heat has quit [Ping timeout: 252 seconds]
wand has quit [Ping timeout: 255 seconds]
dude12312414 has joined #osdev
wand has joined #osdev
dude12312414 has quit [Remote host closed the connection]
[itchyjunk] has quit [Read error: Connection reset by peer]
srjek|home has quit [Ping timeout: 252 seconds]
Terlisimo has quit [Quit: Connection reset by beer]
bradd has joined #osdev
kof123 has quit [Ping timeout: 268 seconds]
Terlisimo has joined #osdev
potash has quit [Read error: Connection reset by peer]
<mrvn>
heat: neat. He has the same fear as I have, that a bss in the middle might overwrite a later segment because you align to page size.
<heat>
*heat
<heat>
no, that's not the fear
<mrvn>
on that note: What happens if an elf has segments that overlap?
<heat>
you can't have elf segments with alignment < PAGE_SIZE
<heat>
it just won't work
<mrvn>
heat: you can put anything in the file
<heat>
sure you can, and it will get -ENOEXEC'd
<mrvn>
then why do you need to align the start/end to pages if it's already aligned according to you?
<mrvn>
I think you are wrong about the alignment. You just have the lower 12 bit of the file offset and VMA match and all segments in a page have to have the same flags.
<mrvn>
s/just have/just have to have/
<heat>
sorry, you can but the kernel will fuck around and try to get that offset to be 4K aligned
<mrvn>
heat: I think as is the kernel doesn't handle .bss segments in the middle of files at all. So it might be a none issue.
<mrvn>
>+unsigned long start = load_addr + vaddr + eppnt->p_filesz;
<mrvn>
>+unsigned long end = load_addr + vaddr + eppnt->p_memsz;
<heat>
you know, you might be right
<mrvn>
>can't have a NOLOAD segment in the middle of the file and have it seroed with thAT.
<heat>
if there's a weird out of order segment (that was already loaded) padzero as is will overwrite it
<heat>
but that was already the case?
<mrvn>
On the other hand the linker should zero the bytes in the file so having the file mapped would put zeroes there already.
<heat>
well, not a will, but a possibly will
<heat>
if the OoO segment doesn't start at a page aligned boundary and was loaded previously, you just overwrite it don't you
<heat>
unless... you already overwrote it to begin with, you mapped p_vaddr, p_vaddr + p_filesz yourself, and that rounds up to 4K
<mrvn>
heat: not sure. It might create a annonymous mapping for the segment and then when it tries to load the next segment it sees there is already something mapped.
<heat>
for what segment?
<mrvn>
Say you have .text, .bss, .data. Then loading .bss would map pages and then loading .data has a problem when it overlaps .bss
<heat>
the problem is that it unzeroes bss
<mrvn>
I think you should make some evil elf files with the segments out of order, or overlapping, or segments not aligned to pages with the same or different flags. Anything bad you can think of.
<heat>
i don't know what overlapping will ever mean in the context of elf file loading
<heat>
as in, what's the correct behavior
heat has quit [Remote host closed the connection]
<mrvn>
heat: You removed the "padzero(elf_bss)" after the loading loop and instead have "zero_bss(start, end, elf_prot);" inside the loop. I think that is a problem.
heat has joined #osdev
<mrvn>
heat: overlaping should just fail I think
Dyskos has joined #osdev
<mrvn>
unaligned with the same flags should work, unaligned with different flags should fail since the MMU can't do that.
<mrvn>
heat: What I expect from your patch is this: Old code used to only zero from after the last mapped block to the end of bss (if there is one at the end). Your code zeroes every BSS segment aligning start+end, which might overwrite other segments.
<mrvn>
The overwriting you have to test with some hand crafted elf files. Otherwise your code sounds more correct.
<heat>
yeah i... have some thinking to do
<heat>
it doesn't have a clear and obvious solution atm
bauen1 has joined #osdev
<mrvn>
first thing I think is to make test files so you can test for changes and regressions
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
<heat>
sweetie, this is the linux kernel
<heat>
tests? hold my io_uring
<qookie>
linux tests? you mean `make install && reboot` :^)
<heat>
a distro is just a very large smoketest
<mrvn>
Why are time travelers always late?
<zid>
-next tree is what you want, it'd a massively distributed make install && reboot smoketest
<GeDaMo>
"A wizard is never late, nor is he early, he arrives precisely when he means to."
<mrvn>
"Early is on time, on time is late and late is unacceptable!"
<Bitweasil>
My band director in HS was a fan of that approach.
<Bitweasil>
"If you're on time, you're *late*!"
xenos1984 has quit [Ping timeout: 248 seconds]
wand has quit [Ping timeout: 255 seconds]
zoey has joined #osdev
xenos1984 has joined #osdev
wand has joined #osdev
gog has joined #osdev
<gog>
helo
<gog>
welcome to osdev
<gog>
this is osdev
<GeDaMo>
Then who was phone? :|
srjek|home has joined #osdev
einkoder has quit [Ping timeout: 252 seconds]
srjek_ has quit [Ping timeout: 260 seconds]
fatal1ty has joined #osdev
<fatal1ty>
what's up badasses ?
<heat>
gog, welcome to osdevorg
<fatal1ty>
mjg: btw it's the last time you underestimating my boys
<fatal1ty>
regarding their trade as "unmanly"
pitust has quit [Ping timeout: 246 seconds]
maksy has quit [Ping timeout: 246 seconds]
basil has quit [Ping timeout: 246 seconds]
Gooberpatrol66 has quit [Ping timeout: 246 seconds]
sakasama has quit [Ping timeout: 246 seconds]
basil has joined #osdev
pitust has joined #osdev
<geist>
hihi everyone
<geist>
it's a monday!
<geist>
okay i guess unless you're in au
<heat>
i hate mondays
<fatal1ty>
geist: hi
<geist>
lo
<fatal1ty>
heat: you got some swag i'll give you that
<geist>
heat has a case of the mondays
srjek|home has quit [Ping timeout: 260 seconds]
sakasama has joined #osdev
bgs has joined #osdev
pbx_linux is now known as pbx
<gog>
yes
<Mondenkind>
heat: you can do anything at osdevorg
fatal1ty has quit [Quit: WeeChat 3.7.1]
<gog>
i had a decent monday so far
<heat>
i came to the conclusion that I think my patch is slightly broken on really exotic configurations
<gog>
dang
<heat>
don't get me wrong, the old code was also slightly broken on really exotic configurations
<gog>
if yours is less broken it's a step forward
<zid>
no code, only perfect
<heat>
my problem is that if a .bss segment and .data segment share a page, the bss clearing code will clear the bss, and when mapping .data you will overwrite the old bss mapping
<heat>
... which means you effectively zeroed shit
<zid>
are you going to range the bss clear, or just leave it
<heat>
the solution is to zero everything after mapping everything
<heat>
so for phdr in phdrs: map(phdr) for phdr in phdrs: zero_bss(phdr)
<heat>
which mostly kinda works, it will fail to zero if instead of .data in this situation, we have something that's not writeable such as .text or .rodata
<heat>
...but the old code had that issue too
<zid>
You know what the correct patch for this is though?
<zid>
Refuse to load anything with overlapping sections.
<zid>
stupid nommu users can die
<mats1>
fight them
gareppa has joined #osdev
<Mondenkind>
I approve this messag
<zid>
I don't aprob of your lifestyle heat
<zid>
just in case you weren't aware
<heat>
what's my lifestyle
<gog>
c
<gog>
c
<zid>
appealing to nommu users
<gog>
c++
<zid>
and C++
<gog>
sorry stuttering
<heat>
C lifestyle
<gog>
my lifestyle is even worse
<heat>
your lifestyle is programming socks and C++
<gog>
no i've added another notch to that measure
<zid>
Get yourself a nice young gender-fluid beard with stripey socks or something idk
<zid>
I'm not very good at this stuff I just got here
<gog>
i'm becoming a fitness dork
<zid>
I'd like to become a fitness, but fitness dorks are horrendous people
<bslsk05>
en.wikipedia.org: Cosmos (operating system) - Wikipedia
<GeDaMo>
"is a toolkit for building GUI and command line-based operating systems, written mostly in the programming language C# and small amounts of a high level assembly language named X#"
<geist>
zid: omg, i can imagine the interpreter looking at the opcode, generating an insdtruction object and then running it?
<zid>
yup
<zid>
He was doing multiple allocations per byte of machine code
<gog>
zid: factoryfactory is the only class that matters
<zid>
It is the mother of all code
<gog>
yes
<zid>
honzuki upload is late :(
<zid>
*withdrawl symptoms*
<gog>
weeb
<zid>
read honzuki and say that
<gog>
no
<zid>
It's only 530MB of pdfs, what are you scared of
<gog>
commitment
<zid>
same
<zid>
let's get married
<zid>
oh phew, it's not late, jnovelclub just runs off an american state with DST
<zid>
so it changed release time 3 times this month
<mats1>
is there boob in it
GeDaMo has quit [Quit: I'm going to show these people something you don't want them to see. I'm going to show them a world without you.]
<heat>
InstructionFactory is a genius concept
terminalpusher has quit [Remote host closed the connection]
<mrvn>
gog: GeneratorFactoryFactoryGeneratorBase
<heat>
the best part of C# is that it's not java
<heat>
so be happy it's not java
<mrvn>
I'm still trying to figure out how to make a coroutine factory coroutine in C++.
<mrvn>
or range factory range
<mrvn>
goal: make a prime number generator via adding filters on top of filters. skip all even, skip all divisible by 3, skip all disible by 5, ... every prime you generate adds a filter.
<Mondenkind>
linq et al are just knockoff apl
<mrvn>
"roads, where we are going we don't need roads"
clever has quit [Ping timeout: 246 seconds]
clever has joined #osdev
<geist>
Re instruction factory. If you could alloc on the stack I guess you could do it fairly efficiently
<geist>
Though you probably still end up relying on a virtual dispatch for the handler
<heat>
makes me wonder, does jvm/whatevercsharpvm alias heap allocations to the stack?
<mrvn>
heat: you mean when it sees the alloc and free in the same function?
<clever>
haskell basically doesnt use the stack at all, the haskell stack is just a linked-list in the heap
<heat>
mrvn, sure. it it can tell it won't need to GC
<heat>
if it*
<heat>
so something with a very limited, stack-like lifespan
<mrvn>
big if in a language without explicit free
<heat>
mrvn, ah yeah fun fact ELF segments can't overlap
<mrvn>
You need to look ahead through all the function calls to see if any store the address. Probably exceeds the jit.
<mrvn>
heat: why? What stops me from doing nasty stuff like overlapping and reusing the file offset / LMA / VMA in the file?
<heat>
nothing, but nothing forces me to load you, or load you ""correctly""
<heat>
PT_LOAD addresses are also required to be sorted in rising order
<mrvn>
sure. The test is to see if the kernel actually fails to load nicely. Gives a proper error and not map something broken.
<heat>
it doesn't
<mrvn>
time to add some checks and errors then :)
<clever>
heat: sorted by LMA or VMA?
<heat>
VMA
<heat>
i'm not so sure if checks are needed
<heat>
or wanted really
<mrvn>
you can't trust the user to actually sort by PT_LOAD
<heat>
we don't break userspace - linux torwald or something like that, idk
<mrvn>
the alternative would be to remove the requirement that it's sorted and handle it properly if not.
<heat>
you can't trust the loader to load your broken elf
<heat>
basically, play stupid games win stupid prizes
<hmmmm>
<heat> PT_LOAD addresses are also required to be sorted in rising order
<hmmmm>
i did not know this
* hmmmm
scrambles to fix elf loader
<heat>
how did you fuck that up
<heat>
haha the linux loader is broken right now
<hmmmm>
because I just iterate thru the segment table, don't make sure anything is sorted. at least i check for loaded segment overlap?
<heat>
what's the point
<heat>
<heat> basically, play stupid games win stupid prizes
<hmmmm>
lol
<hmmmm>
i'm sure the big OSes do it correctly
<heat>
wrong
<heat>
wrongest you've ever been in your life
<heat>
i've been talking about linux's loader and its bugs this whole time
<mrvn>
hmmmm: can you handle 2 segments sharing a page with the same flags and not overlapping?
<mrvn>
also having the same page in the file
<heat>
wdym?
<mrvn>
.text.foo going from 4096-5999, .text.bla going from 6000 - 8191
<hmmmm>
ha, no i can't
<hmmmm>
nobody can because that's an architecture dependent detail. is there some provision for this in the ELF spec, or sysv abi or something?
<mrvn>
do you catch it and give an error or just blow up?
<hmmmm>
that they need to be at least PAGE_SIZE granularity?
<heat>
no
<heat>
this works
<mrvn>
hmmmm: those 2 segments can be mapped as 1 page just fine
<heat>
offset doesn't need to be 4096 aligned, you'll need to adjust the offset when mapping
<heat>
(if your offset after the adjustment isn't 4096 mapped, then you'll break and crash and burn)
<heat>
s/mapped/aligned/
<hmmmm>
true
<Griwes>
Or you can refuse to load ELFs that have more than one segment per each page
<mrvn>
assume the offset in the file is aligned.
<Griwes>
Which is why my OS's target in my patched clang sets a bunch of funny linker flags
<mrvn>
Griwes: you can. But you should give a good error and not just fail obscurely.
<Griwes>
Indeed
<mrvn>
I bet a bunch of people check for overlapping segments but not segments that don't overlap but share a page.
<zid>
oh god, fuck, shit, honzuki oh pls stop, this is bad news
<clever>
zid: ?
<zid>
A very very big big big flag just got tripped
<zid>
and by tripped I mean loaded, locked, fuse lit, will written
<clever>
ah
srjek|home has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Burgundy has left #osdev [#osdev]
<mjg>
ugh
<mjg>
anyone well versed with coccinelle?
<mjg>
trying to replace:
<mjg>
foo(p);
<mjg>
bar(p);
<mjg>
with:
<mjg>
baz(p);
<heat>
isn't that a linux thing?
<mjg>
it is a general thing
<mjg>
so far i only had to modify singular lines which works fine
<heat>
use sed?
<mjg>
i don't see what to do about *two* lines to whack
<mjg>
dude
<mjg>
's missing the point
<mjg>
i got liek 4 places to patch, i can do that by hand
<heat>
mjg, do you have gcc + ld.bfd installed in freebsd?
<mjg>
no
<heat>
could you? for a quick test
<heat>
or just bfd really
<mjg>
i could in 30 mins
<mjg>
i mean i can
<heat>
no need, i'll spin up my vm
k0valski1889 has quit [Quit: Ping timeout (120 seconds)]
hmmmm has quit [Changing host]
hmmmm has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
my freebsd vm crashed my whole DE
<heat>
thanks freebsd
<mrvn>
what shitty VM do you have?
<heat>
im now typing this from a super fucked up 90% transparent window
<heat>
virtual box
<heat>
i bet it was fucking zfs
<heat>
must've been
heat has quit [Remote host closed the connection]
<mrvn>
I would say it's virtual box
<mjg>
lol
<mrvn>
messing around with X resources of other apps. tsss
heat has joined #osdev
<mrvn>
You could also blame Xorg for not sandboxing clients.
<mrvn>
heat: virtualbox might disable the OOM killer for the VM and if it then uses up to much ram ...
<zid>
nommu is for plebs, and not putting bss last is for insane people
<heat>
the loader loads .bss, zeroes it, then loads .data on top of it (with mmap MAP_FIXED)
<heat>
my program basically forces .bss and .data to share a page (with .data after .bss), and then explicitly checks if it was loaded correctly
<mjg>
heat: can you be arsed to report this to freebsd-current@freebsd.org
<zid>
what defines correctly here?
<zid>
section order in the elf?
<heat>
correctly = bss zeroed, data loaded properly
<zid>
yes what defines it
<heat>
yeah sure section order
<heat>
because .data is misaligned
<heat>
(which is 100% valid)
<heat>
all loaders do for phdr in phdrs: map(phdr); if phdr.is_bss(): zero(phdr)
<zid>
I just check filesz < memsz
<zid>
and insert blank *pages*
<heat>
when doing .data's map, the loader maps them using mmap
<zid>
cus non-aligned images are illegal
<mrvn>
zid: that's wrong if bss is in the middle
zoey has quit [Remote host closed the connection]
<heat>
if its misaligned, it aligns p_vaddr and p_offset and does it
<mrvn>
zid: or at least insufficient
<heat>
so, <map bss pages and zero any already mapped page with a leftover>, <map .data, but since it's misaligned, map it over .bss>
<heat>
now .bss isn't zeroed
<heat>
mjg, just to be clear, it's not the same bug that was addressed in my patch. your loader handles it correctly
<heat>
it's just another separate problem
<zid>
does mjg run freebsd
<heat>
that's not handled in my patch, not handled in mainline linux, not handled in freebsd
<zid>
or boros
<heat>
boros for sure
<zid>
I should build one of these binaries and look at it
<zid>
actually just dump me the readelf?
<zid>
I know what my loader does with it
<mrvn>
heat: now if only one could use this to exploit something. Maybe replace the vdso with your own data and then on syscall you run code as kernel.
<heat>
zid, just git clone and make, its pretty easy
<zid>
ergh
<zid>
readelf is easier
<heat>
mrvn, the vdso isn't kernel code
<mrvn>
heat, mjg; Does "ld.so a.out" work?
<heat>
this is not exploitable
<heat>
right now, no, because ld.so wants a dynamic executable
<heat>
at least the musl one, which I was testing
<mrvn>
.oO(does it?)
<heat>
musl is 100% buggy as well
<klange>
i had to replace your syscall, but runs to completion in toaru
<heat>
i'm curious if theres a mmap UNIX out there that isn't vulnerable