lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 2 Jan 2023 09:41:22 +0100
From:   Willy Tarreau <w@....eu>
To:     Sven Schnelle <svens@...ux.ibm.com>
Cc:     "Paul E . McKenney" <paulmck@...nel.org>,
        Josh Triplett <josh@...htriplett.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org, hca@...ux.ibm.com
Subject: Re: [PATCH 2/5] nolibc: add support for s390

Hi Sven,

On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
> > But with this addressed, I'm facing this next error:
> >
> >   $ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
> >     MKDIR   sysroot/s390/include
> >   make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> >   make[2]: Entering directory '/g/public/linux/master'
> >   make[2]: Leaving directory '/g/public/linux/master'
> >   make[2]: Entering directory '/g/public/linux/master'
> >     INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> >   make[2]: Leaving directory '/g/public/linux/master'
> >   make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> >     CC      nolibc-test
> >   /tmp/ccCzaBgD.s: Assembler messages:
> >   /tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
> >   /tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
> >   /tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
> >   make: *** [Makefile:108: nolibc-test] Error 1
> >
> > Thus I'm wondering if specific options are required for the compiler
> > (it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
> > or if there's anything wrong in the asm code (e.g. maybe by accident you
> > sent the patch from an earlier development branch), or anything else ?
> 
> Hmm, tried this on my x86 laptop, and it looks like there are two things
> here:
> 
> The cross compiler needs -m64 to compile in 64bit mode. otherwise it
> assumes 31bit mode, where both lg and lghi are not present. The other
> thing is that lay was introduced with later generations of the
> z/Architecture.

Ah, this explains why along my various tests at some point I managed
to remove two of these errors (likely with -m64)!

> The kernel compiles with z10 as minimum architecture, so
> i'm leaning towards enforcing the same arch for nolibc. What do you think?

Sure, as long as this works for most users, that's likely fine.
Alternately, are there equivalent sequences of instructions that achieve
the same on older architectures, and would that be relevant ?

One future improvement I'll need will be to store the envp value into a
global "environ" variable, and run over it to catch the pointer that
follows the NULL and save it into the "_auxv" variable. I've done it for
all other archs here already:

  https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4

I'll give it a try once I'm able to build and test your code, and may
ask you for some help if I don't succeed in doing it. If you want to do
it yourself, please have a look at the last commits adding environ and
auxv to any arch of your choice, such as x86_64.

Thanks!
Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ