[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250808151337.GT1827@brightrain.aerifal.cx>
Date: Fri, 8 Aug 2025 11:13:38 -0400
From: Rich Felker <dalias@...c.org>
To: Daniel Gutson <danielgutson@...il.com>
Cc: musl@...ts.openwall.com, David Edelsohn <dje.gcc@...il.com>,
Sertonix <sertonix@...teo.net>
Subject: Re: ctr registry after syscall on powerpc
On Fri, Aug 08, 2025 at 12:50:03AM -0300, Daniel Gutson wrote:
> El jue, 7 de ago de 2025, 16:47, Rich Felker <dalias@...c.org> escribió:
>
> > On Thu, Aug 07, 2025 at 03:27:18PM -0400, Rich Felker wrote:
> > > On Wed, Aug 06, 2025 at 11:23:50AM -0400, David Edelsohn wrote:
> > > > On Wed, Aug 6, 2025 at 11:07 AM Sertonix <sertonix@...teo.net> wrote:
> > > >
> > > > > (Sorry for the noise, I don't know any better place to ask)
> > > > >
> > > > > With GCC 15 I get a compiled musl libc that stores a value in the ctr
> > > > > registry, doing a syscall which changes the ctr registry and then
> > > > > reading back garbage data when trying to read the original value. I
> > > > > unfortunatly couldn't find any information do determine if this is an
> > > > > issue in musl, gcc or the kernel.
> > > > >
> > > > > The relevant code from src/malloc/mallocng/malloc.c:
> > > > >
> > > > > size_t pagesize = PGSZ; // stored into ctr registry
> > > > > ...
> > > > > ctx.brk = brk(0); // mess up ctr registry
> > > > > ...
> > > > > ctx.brk += -ctx.brk & (pagesize-1); // try to read back ctr
> > > > > registry
> > > > >
> > > > > When I mark ctr as clobber in __syscall1 I don't see this issue. Is
> > > > > that a correct fix?
> > > > >
> > > >
> > > > The CTR register is volatile in the ELFv2 (and other) PowerPC ABIs, and
> > > > that behavior is not changed by the Linux kernel system call ABI. It's
> > > > unusual that GCC is allocating / spilling a value to CTR and that it is
> > > > assuming the register is valid across a call. There must be more that
> > is
> > > > affecting the dataflow analysis and causing this strange behavior.
> > > >
> > > > I would open a GCC bug. Please include details about exactly which GCC
> > > > release and vendor build is being used, and the pre-processed source
> > code.
> > >
> > > It's not across a[n exteral] call. It's just across an (inlineable)
> > > syscall. So apparently this is a bug in our syscall asm constraints.
> >
> > Proposed patch. Anything else like this missing?
> >
>
> What about XER?
I thought it would be unaffected because kernel doesn't use math
facilities, but apparently the kernel zeros it on return, so I'm
adding it to the clobberlist too. Thanks for checking.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
