asmutils libc fun and games

asmutils libc fun and games

[Paul Furber]

Hello fellow asm heads,
I've discovered the joys of the asmutils boot disk and now want to make 
it possible to include statically linked code written in C and the 
asmutils libc library on the distro. But I can't get the static versions 
working. Here's the problem:

In the Makefile (in asmutils-0.16/lib/) I have:

BUILD_STATIC = y
BUILD_SHARED = y

But when building the static test proggie I get:

gcc -D__CPU__=386 -Wall -O1 -m386 -g -D__NO_STRING_INLINES -fno-builtin 
-nostartfiles -nostdlib  -static -o test1-static test1.c libc_stub.o libc.a
libc.a(libc.o): In function `_start':
libc.o(.text+0x4): multiple definition of `_start'
libc_stub.o(.text+0x0): first defined here
collect2: ld returned 1 exit status
make: *** [test1] Error 1

If I comment out STUB_OBJS and remake the static portion, then some of 
the static versions are compiled but output the __libc_banner file which 
reads:
A r e  y ou   s i c k ?

To which I reply yes! :) I would like a tiny libc written in asmutils 
that links statically so as to include some demo-style progs on the 
bootdisk. Am Imissing the point of this libc? Even the shared libraries 
that build correctly are dynamically linked to libNoVersion and GNU libc 
when you ldd them. What's up with that?

Paul.

Re: asmutils libc fun and games

[h-peter recktenwald]

On Fri, 17 May 2002 15:24:47 +0200
Paul Furber <paulf@gam.co.za> wrote:

> bootdisk. Am Imissing the point of this libc? Even the shared libraries 
> that build correctly are dynamically linked to libNoVersion and GNU libc 
> when you ldd them. What's up with that?

I made a similar experience, -nostdlib &c just useless. found a workaround 
having "libc.a" first in the search path, which apparently keeps the GNU-ish 
stuff happy but, doesn't forcedly include such nonsense.

regards,
	hp

=====
compiled, tests passed:

> /usr/src/asm/nasm-98-3e-21/nasm 0.98.21 may miscompile asmutils, please 
>	use only clean /usr/src/asm/nasm-98-3e-21/nasm 0.98!
patched version 98.03 (with %xdefine and un-deleted listing output)

> /usr/src/asm/nasm-98-3e-21/nasm -Llibc.lis -w+orphan-labels \
>	-w+macro-params -i/usr/src/asm/asmutils/inc/ -g -f elf \
>	-D__LINUX__ -D__KERNEL__=22 -D__SYSCALL__=__S_KERNEL__ \
>	-D__OPTIMIZE__=__O_SIZE__ -D__ELF__ -DDEBUG libc.asm||:
> libc.asm:154: message:
>	section attributes ignored on redeclaration of section `.text'
(always, as usual...)

> /usr/src/asm/nasm-98-3e-21/nasm -Llibc_stub.lis -w+orphan-labels \
>	-w+macro-params -i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ \
>	-D__KERNEL__=22 -D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__ \
>	-D__ELF__ -DDEBUG libc_stub.asm||:
> ar rcv libc.a libc.o
> a - libc.o
> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -o test1-static test1.c \
both! 	^^^^^^^^^^^^^^^^^^^^^^^^
>	libc_stub.o libc.a

> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -mregparm=3 -D__FASTCALL__\
> 	-o test1-static-fastcall test1.c libc_stub.o libc.a
> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -o test2-static test2.c \
>	libc_stub.o libc.a
> gcc -mcpu=k6 -march=k6 -Wall -O1 -g -D__NO_STRING_INLINES -fno-builtin \
>	-nostartfiles -nostdlib  -static -mregparm=3 -D__FASTCALL__\
> 	-o test2-static-fastcall test2.c libc_stub.o libc.a
> /usr/src/asm/nasm-98-3e-21/nasm -Lmd5.lis -w+orphan-labels -w+macro-params \
>	-i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ -D__KERNEL__=22 \
>	-D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__ -D__ELF__ \
>	-DDEBUG md5.asm||:
> /usr/src/asm/nasm-98-3e-21/nasm -Lrc6.lis -w+orphan-labels -w+macro-params \
>	-i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ -D__KERNEL__=22 \
>	-D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__ -D__ELF__ \
>	-DDEBUG rc6.asm||:
> /usr/src/asm/nasm-98-3e-21/nasm --Lrmd.lis --w+orphan-labels \
>	--w+macro-params -i/usr/src/asm/asmutils/inc/ -g -f elf -D__LINUX__ \
>	-D__KERNEL__=22 -D__SYSCALL__=__S_KERNEL__ -D__OPTIMIZE__=__O_SIZE__\
>	-D__ELF__ -DDEBUG rmd.asm||:
> ar rcv libcrypto.a md5.o rc6.o rmd.o
> a - md5.o
> a - rc6.o
> a - rmd.o

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
NO abusive software patents http://petition.eurolinux.org/pr/pr17.html
-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

asmutils - Linux 2.4.18

[h-peter recktenwald]

hi...

found some funny differences w Linux 2.4.18 kernel wrt its predecessors 
where, for instance, the 'umount' system call doesn't work on devices 
and mountpoints, any more, but, only on the device names.

i.e, some systemcalls' names were silently changed, previously valid 
names assigned to different(ly operating) new/old syscalls.

I found this when trying the "eject" program from asmutils which was 
non functional w. 2.4.18. The patch cures the problem:
------
; patch eject.asm for Lx 2.4.18 sys_umount
.eject:
        push ecx                ; mountpoint
        push ebx                ; specialfile
    %ifdef ONLY_CCD
    %else
        test byte[edi],-1
        jnz .opn                ;?; not -ccd, just the syscall
    %endif; <= ONLY_CCD
%if __KERNEL__ < 24; new inconsistency in kernel 2.4.18!	<== !
        sys_umount              ; eject won't work on a mounted device
%else
        sys_umount dword[esp+4] ; 'oldumount' w/ #mountpoint#, only
        mov ebx,[esp]
%endif
.opn:
------

Further, the macro "_xchg" in asmutils' 'system.inc' is not correct 
(which I didn't recognize earlier because I'm using my own version;):

1) ---
 %macro _xchg 2
-%if __OPTIMIZE__=__O_SPEED__
+%if __OPTIMIZE__=__O_SIZE__;
 %assign ea 4
2) ---
@@ -721,7 +723,7 @@
 ;  2 clocks w. reg,reg
 ;      (lea variant wasn't faster, may be cpu dependent?)
 ; 33 clocks w. reg,mem or mem,reg - either case
-    xchg %{1},%{3}
+    xchg %{1},%{2};
-----
btw. the attempts to finding out about the actual addressing mode 
seem useless, "nasm" apparently providing no such means, at all.


regards,
	hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
NO abusive software patents http://petition.eurolinux.org/pr/pr17.html
-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is this list dead?

[halfdead]

Hi guys,

I have been out for too long and now i see that there is no activity on
this list. Is it like dead or something?

- halfdead

Re: Is this list dead?

[Frederic Marmond]

nope, still alive...
working hard!
(for info: if you want to boot a kernel from an already running kernel, 
you can use 'monte' project. Very good! (for x86 only))

Fred
halfdead wrote:

>Hi guys,
>
>I have been out for too long and now i see that there is no activity on
>this list. Is it like dead or something?
>
>- halfdead
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

Re: Is this list dead?

[lx]

On Fri, 13 Sep 2002 11:09:54 +0300 (EEST)
halfdead <halfdead@cannabis.daphnes.ro> wrote:

> Hi guys,
> 
> I have been out for too long and now i see that there is no activity on
> this list. Is it like dead or something?
> 
> - halfdead

nice to know that you still seem just half of what this list is not.
all questions answered, nothing new in the kernel which none understands.

best,
	hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de

kernel vulnerabilities

[halfdead]

Hey,
Its been rumoured for a while that certain vulnerabilities reside at
kernel level in different unix flavours (solaris/bsd/linux). Some of them
claim to be remotely exploitable (ABfrags.c, ABremkrnl.c, etc.). I have
seen local kernel vulnerabilities and they seem to be pretty tricky to
exploit hence i highly doubt that anyone would be able to work out a
clean remote exploitation. Is any of you guys aware of any method or is
this just FUD?

- halfdead

Re: kernel vulnerabilities

[Robin Miyagi]

Wouldn't a venue such as comp.os.linux.security be a more appropriate venue 
for such a question?

Or are you trolling for help exploiting such vulnerabilities :)

On Sunday 22 September 2002 05:29, halfdead wrote:
> Hey,
> Its been rumoured for a while that certain vulnerabilities reside at
> kernel level in different unix flavours (solaris/bsd/linux). Some of them
> claim to be remotely exploitable (ABfrags.c, ABremkrnl.c, etc.). I have
> seen local kernel vulnerabilities and they seem to be pretty tricky to
> exploit hence i highly doubt that anyone would be able to work out a
> clean remote exploitation. Is any of you guys aware of any method or is
> this just FUD?
>
> - halfdead
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-assembly"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Robin Miyagi<penguin@dccnet.com>
http://www.geocities.com/SiliconValley/Ridge/2544/asm/assembler.html
The funny thing about brakes, is that when they break, they don't brake.