Follow @Openwall on Twitter for new release announcements and other news
[<prev] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DC1GVQIEOL4E.3T0528AJKVKMG@posteo.net>
Date: Wed, 13 Aug 2025 17:13:56 +0000
From: "Sertonix" <sertonix@...teo.net>
To: "Rich Felker" <dalias@...c.org>, "David Edelsohn" <dje.gcc@...il.com>
Cc: <musl@...ts.openwall.com>
Subject: Re: ctr registry after syscall on powerpc

On Thu Aug 7, 2025 at 9:47 PM CEST, Rich Felker wrote:
> 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?

Thanks, for all the comments. I don't think I can help much with the
final patch but it seems to work to me.

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.