linux-kernel - Re: [PATCH 9/9] um: switch ptrace FP register access to nolibc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0c8abee7-8987-45da-b168-0bf7d78d9184@t-8ch.de>
Date: Mon, 15 Sep 2025 13:22:29 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: "Berg, Benjamin" <benjamin.berg@...el.com>
Cc: "w@....eu" <w@....eu>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>, 
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>, "tiwei.btw@...group.com" <tiwei.btw@...group.com>, 
	"acme@...hat.com" <acme@...hat.com>
Subject: Re: [PATCH 9/9] um: switch ptrace FP register access to nolibc

On 2025-09-15 11:09:40+0000, Berg, Benjamin wrote:
> On Mon, 2025-09-15 at 11:07 +0200, Thomas Weißschuh wrote:
> > On 2025-09-15 09:11:15+0200, Benjamin Berg wrote:
> > > From: Benjamin Berg <benjamin.berg@...el.com>
> > > 
> > > The registers.c file only contain the routines for floating point
> > > register access in ptrace mode and initial size detection. The file can
> > > be moved over to nolibc by replacing the ptrace libc call with a simple
> > > wrapper that does a direct syscall.
> > > 
> > > Signed-off-by: Benjamin Berg <benjamin.berg@...el.com>
> > > ---
> > >  arch/x86/um/os-Linux/Makefile    |  5 ++++-
> > >  arch/x86/um/os-Linux/registers.c | 22 ++++++++--------------
> > >  2 files changed, 12 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/arch/x86/um/os-Linux/Makefile b/arch/x86/um/os-Linux/Makefile
> > > index 77a308aaa5ec..d37320430822 100644
> > > --- a/arch/x86/um/os-Linux/Makefile
> > > +++ b/arch/x86/um/os-Linux/Makefile
> > > @@ -3,10 +3,13 @@
> > >  # Licensed under the GPL
> > >  #
> > >  
> > > -obj-y = registers.o mcontext.o
> > > +obj-y = mcontext.o
> > >  
> > >  obj-$(CONFIG_X86_32) += tls.o
> > >  
> > >  USER_OBJS := $(obj-y)
> > >  
> > > +obj-y += registers.o
> > > +NOLIBC_OBJS := registers.o
> > > +
> > >  include $(srctree)/arch/um/scripts/Makefile.rules
> > > diff --git a/arch/x86/um/os-Linux/registers.c b/arch/x86/um/os-Linux/registers.c
> > > index eb1cdadc8a61..55bce0d3f5d2 100644
> > > --- a/arch/x86/um/os-Linux/registers.c
> > > +++ b/arch/x86/um/os-Linux/registers.c
> > > @@ -6,18 +6,20 @@
> > >  
> > >  #include <errno.h>
> > 
> > Given that you are explicitly disabling errno support for nolibc, is
> > this include necessary?
> 
> I think it is technically correct as we do need ENODEV and ENOMEM to be
> defined. Not that we actually need the include if we pull in nolibc.h.

Yes, indeed.

> Considering we would never build against libc, should we maybe just do
> an explicit nolibc.h include and rely on it pulling in the rest
> automatically? That seems a bit weird to me, but as-is we will never
> notice when we forget an include.

Your choice. nolibc will always include itself fully transitively in any
case. So you won't notice a missing include that way either. The
different headers mostly exist to structure the nolibc sources
themselves and to let the application code look normal.
I would go with normal includes.

> > >  #include <stdlib.h>
> > > -#include <sys/ptrace.h>
> > > +#include <linux/ptrace.h>
> > >  #ifdef __i386__
> > >  #include <sys/user.h>
> > >  #endif
> > >  #include <longjmp.h>
> > >  #include <sysdep/ptrace_user.h>
> > > -#include <sys/uio.h>
> > > +#include <linux/uio.h>
> > 
> > It looks fairly trivial to add sys/uio.h to nolibc.
> > Only 'struct iovec' (already provided by the UAPI) and readv()/writev()
> > are necessary.
> > 
> > >  #include <asm/sigcontext.h>
> > >  #include <linux/elf.h>
> > >  #include <registers.h>
> > >  #include <sys/mman.h>
> > >  
> > > +#define my_ptrace(...) my_syscall4(__NR_ptrace, __VA_ARGS__)
> > 
> > Why not add sys/ptrace.h to nolibc and then use sys_ptrace()?
> 
> Honestly, I just got a bit lazy at that point and this was a reasonable
> proof that mixing nolibc with libc works fine.

Fair enough :-)

> You are absolutely right
> that it would be better to add this to nolibc.
> 
> > In general I'm not a fan of the my_syscall() naming scheme and would
> > like to change this in nolibc itself, so having fewer external users
> > would be nice.
> 
> How about adding a sys_syscall macro? That would match the naming
> scheme of the other functions. Then, once all users are ported, one can
> simply change the my_ prefix to __nolibc_.

sys_syscall() looks weird. Personally I would have gone with _syscall().
Let's just sidestep the issue for now by adding sys_ptrace() to nolibc.

(...)