linux-kernel - Re: [PATCH v6 00/15] x86-64: Stack protector and percpu improvements

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]

Message-ID: <CAMzpN2h=Mc_7MNg5RiqxEvchV_BGAiThG4a5_Xt_HHB=0+vmEg@mail.gmail.com>
Date: Thu, 20 Feb 2025 12:24:34 -0500
From: Brian Gerst <brgerst@...il.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Uros Bizjak <ubizjak@...il.com>, Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org, 
	x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v6 00/15] x86-64: Stack protector and percpu improvements

On Thu, Feb 20, 2025 at 5:52 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Thu, 20 Feb 2025 at 11:46, Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 11:05 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> > >
> > > Hi Uros,
> > >
> > > On Thu, 20 Feb 2025 at 10:51, Uros Bizjak <ubizjak@...il.com> wrote:
> > > >
> > > > On Wed, Feb 19, 2025 at 2:18 PM Brian Gerst <brgerst@...il.com> wrote:
> > > > >
> > > > > On Wed, Feb 19, 2025 at 6:47 AM Ingo Molnar <mingo@...nel.org> wrote:
> > > > > >
> > > > > > * Uros Bizjak <ubizjak@...il.com> wrote:
> > > > > >
> > > > > > > I wonder if there would be any benefit if stack canary is put into
> > > > > > > struct pcpu_hot?
> > > > > >
> > > > > > It should definitely be one of the hottest data structures on x86, so
> > > > > > moving it there makes sense even if it cannot be measured explicitly.
> > > > > >
> > > > >
> > > > > It would have to be done with linker tricks, since you can't make the
> > > > > compiler use a struct member directly.
> > > >
> > >
> > > Interesting take. I'd have tried to put the canary at offset 0x0, and
> > > simply use pcpu_hot as the guard symbol.
> > >
> > >
> > > > It boots and runs without problems.
> > > >
> > > > However, when building the kernel, I get "Absolute relocations
> > > > present" warning with thousands of locations:
> > > >
> ...
> > >
> > > The warning is about the type of __ref_stack_chk_guard, not about the
> > > type of the relocation.
> >
> > Thanks, I got distracted by the text of the warning that mentions relocation.
> >
> > > $ nm vmlinux |grep \\s__ref_sta
> > > ffffffff8350c620 A __ref_stack_chk_guard
> > >
> > > Without your patch:
> > >
> > > $ nm vmlinux |grep \\s__ref_sta
> > > ffffffff834fba10 D __ref_stack_chk_guard
> >
> > Is this a problem in our specific case?
>
> I don't think so - the whole notion of absolute ELF symbols is rather
> flaky IME, so I don't think we should be pedantic here.

>From what I understand it stayed relative because there wasn't a
constant added.  As soon as you add a constant (which the linker
treats as absolute), it becomes absolute.

> > We can list the symbol in arch/x86/tools/relocs.c to quiet the
> > warning, but I would need some help with auditing the symbol itself.
> >
> > OTOH, we could simply do it your way and put stack canary at the
> > beginning of pcpu_hot structure, with
> >
> > static_assert(offsetof(struct pcpu_hot, stack_canary) == 0));
> >
> > for good measure.
>
> I think this would be the most straight-forward if there are no other
> locality concerns this might interfere with.

I'd prefer it at the end of pcpu_hot, that way the disassembler
doesn't latch on to the __stack_chk_guard symbol when referencing the
other fields of pcpu_hot.


Brian Gerst