IRC channel logs
2023-12-11.log
back to list of logs
<stikonas>well, something is probably broken, because with this commit kaem.hex0 file somehow gets corrupted <oriansj>well and_rsp, !-16 would make the stack align but I don't see you adding 16 to the stack to prevent stack overwrites nor you cleaning up that operation <stikonas>in read function 88B6424 10 ; mov_rsp,[rsp+BYTE] !16 should clean it back <stikonas>hmm, wouldn't and rsp, -16 either leave stack in place <stikonas>or allocate 8 more bytes (i.e. like one more push) <oriansj>and not all pushes push 8bytes, some push single bytes <stikonas>even push 0 I think pushes 64-bit number <oriansj>well x86/amd64 does grow down; I'd make a label like RSP_HOLD; do a store then the andi and after the call do a load from the label to clean up <stikonas>well, we could though, that's extra jump in hex0 code... <oriansj>none of the syscall functions are falling into right? <oriansj>you could do a RSP_HOLD_$name ahead of the function $name <oriansj>so that each syscall has their own and you can just do -8 to get its address <stikonas>though that extra storage for each syscall, but maybe cheaper to restore... <oriansj>well it is a tradeoff between memory size and reducing the number of addresses and offsets you need to manually calculate <oriansj>a tradeoff that only ever appears in hex0 <stikonas>well, in C code all that would be fairly simple <stikonas>all UEFI calls are using common wrappers (only depending on number of args) in M2libc... <stikonas>I wonder if I misread another thing too from the calling convention... <stikonas>it might be that shadow space has to be 32-bytes even for functions with less than 4 arguments... <oriansj>might as well make an even 256bytes; not that wasting of stack space really counts for anything if you do it only during syscalls <oriansj>after it works perfectly, you then can shrink it down when you feel like it or leave it for someone else to have an easy win <matrix_bridge><Andrius Štikonas> Anyway, I'll have to try various things...