***muurkha_ is now known as muurkha
<stikonas>still need to do similar changes for amd64 <stikonas>especially those rax -> al bits should make even more of a difference on amd64 <oriansj>probably could get the AMD64 smaller than x86 in terms of code <oriansj>only the bigger elf-header would work against you <stikonas>with x86 now we don't need any global variables <oriansj>and a few less addresses to manually calculate <oriansj>well extra registers and all the same x86 instructions <oriansj>the ELF header will be bigger but hard to avoid that <oriansj>stikonas: only those that talk to R8-R15 <stikonas>hmm, yes and it's probably still more efficient than pushing/poping <stikonas>like I had to do with output file descriptor <stikonas>maybe I'll write to mailing list about a new hex0 seed <stikonas>since that 357 byte number got well known by now <oriansj>sounds fair as you did the work and should get some praise for your progress <oriansj>be sure to express the 256 bytes as 0x100 bytes to nerd snipe those who skip prefixes <stikonas>oh, that's too late, I've sent just a brief message <stikonas>so kaem + hex0 is now 993 bytes on x86, we are now sub 1K (not counting kernel) <stikonas>kaem can probably be compressed quite a bit too <stikonas>oriansj: maybe stupid idea, but in kaem we have a lot of global variables at the end of the binary <stikonas>quite a few of them are just placeholders (zeroes) <stikonas>anyway, it will be a while till I get to kaem <oriansj>stikonas: well the ELF header isn't actually loaded into memory <oriansj>The problem is if the memory addresses prior to the :_start address might not be mapped into a writable page and will result in a page fault <oriansj>So it can be done, it just violates the standard if we use that memory without doing an allocation <oriansj>and the binary can break on Linux with ZERO warning (as has occurred with the linux 4.17 regression where we violated the ELF spec by doing overlapping ELF segments with mismatched permissions) <oriansj>and despite the Linux kernel's legendary reputation for binary compatibility, they will tell us to suck it up and stop violating the spec. <muurkha>typically the ELF header is in the same 4096-byte page as the beginning of your code, so Linux does map it into your program's memory space ***xerox__ is now known as xerox
***furrymcg1e is now known as furrymcgee
<oriansj>muurkha: that wouldn't make any sense if your _start address is on a 4096 page boundary; now if you expressed that Linux will load the first block of disk into RAM which contains the ELF header and potentially part of your code into a single page of RAM. That would be an accurate statement and in the special case that the _start addresses is exactly the size of the ELF header it would be more efficient not to copy that code into a new <oriansj>page, I'd also agree. Did that clarify my perspective or should I add additional details? <stikonas[m]>Well, it sounds like we shouldn't touch elf header... <muurkha>oriansj: agreed, if the beginning of your code segment (which doesn't have to be the _start symbol) is at the beginning of a page, I don't think Linux will map the ELF header <muurkha>OTOH if you're trying to reduce the number of bytes in your binary you probably won't want to pad your code segment start address up to 4096 bytes, though new versions of binutils do this by default unless you ask them not to <muurkha>also it would be perfectly reasonable, and arguably a security improvement, for Linux to use a special mapping type that zeroes the ELF header <theruran>stikonas[m]: well done on the 256-byte hex0-seed! ***ChanServ sets mode: +o janneke
<stikonas>so I've now got hex0 amd64 seed down to 294 bytes <stikonas>so .text section is smaller by 10 bytes compared to x86 (but elf header is larger by 48 bytes) ***ChanServ sets mode: -o janneke