NASM 0.98.39 vs. NASM 2.03.01 disassembly
in [ASM]
|
Prev: announce: my very first disassembler now available (GPL)
Next: Win32 non blocking console input?
From: Chuck Crayne on 27 Aug 2008 16:39 On Wed, 27 Aug 2008 22:08:07 +0200 Herbert Kleebauer <klee(a)unibwm.de> wrote: > Where can I find the _official_ documentation of the int 80 interface? You can start with "man syscalls", but after that, you either have to read the source code, or trust those of us who have already been there. The secret of translating the C interface to 80h calls is that the syscall number goes in EAX, and the parameters are passed in registers, beginning with EBX. Also, errors are returned as negative values. So, mov eax,__NR_brk ;brk xor ebx,ebx ;get current end int 80h ;query kernel is the functional equivalent of sbrk(0); This particular call cannot fail. But if we followed it with add ebx,10000h ;65k bytes mov eax,__NR_brk ;brk int 80h ;kernel call and the requested memory was not available, then it would return the negative value of ENOMEM in EAX. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Frank Kotler on 27 Aug 2008 17:14 Chuck Crayne wrote: > On Wed, 27 Aug 2008 22:08:07 +0200 > Herbert Kleebauer <klee(a)unibwm.de> wrote: > >> Where can I find the _official_ documentation of the int 80 interface? > > You can start with "man syscalls", but after that, you either have to > read the source code, or trust those of us who have already been there. > > The secret of translating the C interface to 80h calls is that the > syscall number goes in EAX, and the parameters are passed in registers, > beginning with EBX. Also, errors are returned as negative values. So, > > mov eax,__NR_brk ;brk > xor ebx,ebx ;get current end > int 80h ;query kernel > > is the functional equivalent of > > sbrk(0); > > This particular call cannot fail. But if we followed it with mov ebx, eax, of course... > add ebx,10000h ;65k bytes > mov eax,__NR_brk ;brk > int 80h ;kernel call > > and the requested memory was not available, then it would return the > negative value of ENOMEM in EAX. Best, Frank
From: Frank Kotler on 27 Aug 2008 18:12 Rod Pemberton wrote: > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > news:g92t87$5c2$1(a)aioe.org... >> Chuck Crayne wrote: >>> On Tue, 26 Aug 2008 12:27:09 -0400 >>> Frank Kotler <fbkotler(a)verizon.net> wrote: >>> >>>> (I haven't used sys_brk >>>> much, but I thought I remembered, with ebx=0, seeing 0x804A000 from >>>> that... not today) >>> Well, I just tried it, and I do get 0x0804a000. What value did you get? >>> >> 0x080490A1 would you believe...? >> > > Reboot... > > ;) > > > RP > PS. Hate days like that... Good thought. Okay... wouldn't you know /dev/hda1 has been mounted 20 times without being checked... I suppose everybody needs to get fscked everyone in a while... Nope! I've gotta be doing something wrong here... (nasm -f elf32 brktest.asm, ld -o brktest brktest.o) global _start section .text _start: xor ebx, ebx mov eax, 45 int 80h call showeaxh mov eax, 1 int 80h ;------------------------------ showeaxh: push eax push ebx push ecx push edx sub esp, 10h mov ecx, esp xor edx, edx mov ebx, eax ..top: rol ebx, 4 mov al, bl and al, 0Fh cmp al, 0Ah sbb al, 69h das mov [ecx + edx], al inc edx cmp edx, 8 jnz .top ; stuff a newline in there mov byte [ecx + edx], 10 inc edx mov ebx, 1 mov eax, 4 int 80h add esp, 10h pop edx pop ecx pop ebx pop eax ret ;------------------------------ This isn't quite the same as the proposed test of lsl/lar using sys_brk, which returned 0x080490a1 (but didn't print the result, so had to be stepped through to see it). This one returns - even after reboot - 080480B9. (adding a .data section with a single zero byte brings it to 80490DD) Lemme see if I can boot a different kernel... this is *not* what I was expecting! Best, Frank
From: Chuck Crayne on 27 Aug 2008 19:04 On Wed, 27 Aug 2008 18:12:46 -0400 Frank Kotler <fbkotler(a)verizon.net> wrote: > I've gotta be doing something wrong here... I don't think so. Although I get 08049000 from your program on my system, your result of 080480B9 can also be considered correct. The difference is solely whether or not the system rounds to a page boundary. Perhaps one of the kernel maintainers thought that it would improve security if user access were denied to that part of a page which extends beyond the size specified in the ELF header. Which kernel versions are you testing with? -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Frank Kotler on 28 Aug 2008 01:37
Chuck Crayne wrote: > On Wed, 27 Aug 2008 18:12:46 -0400 > Frank Kotler <fbkotler(a)verizon.net> wrote: > >> I've gotta be doing something wrong here... > > I don't think so. Not too much to *do* wrong... but you know me. :) > Although I get 08049000 from your program on my > system, your result of 080480B9 can also be considered correct. Yeah, in a way... but not really, I think. It *does* work, in the sense that adding a "delta" and calling it again does give me the requested amount of memory. Still (mis)reported as "not rounded up". (haven't tested access to that memory - I'm guessing I can access up to the "rounded up" value...) > The > difference is solely whether or not the system rounds to a page > boundary. Yes and no... > Perhaps one of the kernel maintainers thought that it would > improve security if user access were denied to that part of a page > which extends beyond the size specified in the ELF header. That seems logical. Not long after this(?) - 2.6.10 or so - they started checking return values from a call to zero any "slack" in a page. So they were thinking about the issue. However... mov [0x08049ffc], dword 0 ; okay ; mov [0x0804A000], dword 0 ; <- goBoom So in that sense, sys_brk is "lying to me". I think I'm going to consider it a "bug" in this particular kernel version. It was okay before (thus my "expectation"), and it's "been fixed"... > Which kernel versions are you testing with? This one is 2.4.33.3 (Slackware 11). What I booted to that "worked" (except for that tricky "reboot" command...) is 2.6.21.5-smp (Slackware 12 - the one with the "bad ld"! - installed on much too small a partition... just testing...) It worked "as expected" on an earlier 2.4 kernel, too - forget the exact number (Slackware 9). I had intended to continue running the "Slackware 9" install, actually. I installed "Slackware 11", and didn't really see any "improvement", so I went back to booting Slackware 9 by default, intending to overwrite Slackware 11 with... something, when I got around to it. Then a problem was reported with Slackware 12. Turned out that ld (the version number suggested a "snapshot" - 20070615, IIRC - we all have those days...) wasn't doing some "alignment" that other versions did - gave some really strange results - got "killed"(!) if you changed from "mov eax, 1" to "mov al, 1", e.g. So I d/l'ed it and installed on a small partition (~4G)... just to "see for myself"... thinking to maybe install it on a bigger partition if it looked good. At the end of the install, I agreed to install "lilo"... on the mbr. After seeing what I wanted to see, I rebooted, went into "CMOS setup" and swapped the boot drive to the "slackware 9" drive... and it attempted (apparently) to boot the new kernel, mounted on a partition with the wrong (or no) files... I don't know if I told lilo something wrong, or if it threw me a curve ball. At that point, the partition table *may* have been intact (I had the impression lilo wouldn't touch it). After my attempts to recover... it was definitely trash. After determining that lilo's "saved" mbrs weren't "right" either, I wound up using fdisk to claim all one Linux partition - not right, there was a swap partition, but it made the drive readable. I've copied "just about everything I need" to the "Slackware 11" partition. "Pretty soon now", I'll be "sure" I've got everything I need off there, and will repartition it and install... maybe it's time to get away from Slackware... Something to be said for installing the "most common case", but there are advantages to being "away from the mainstream", too - I get to see these differences which *do* turn up... Best, Frank |