linux-kernel - Re: [PATCH v5 09/16] x86/percpu/64: Use relative percpu offsets

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: <CAFULd4ZgJt3ZifEQFPFuT-YRN0-p6w-=rFRKuwoEhBS84JSmiw@mail.gmail.com>
Date: Thu, 7 Nov 2024 14:34:34 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: Brian Gerst <brgerst@...il.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, 
	Ingo Molnar <mingo@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Borislav Petkov <bp@...en8.de>, Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v5 09/16] x86/percpu/64: Use relative percpu offsets

On Thu, Nov 7, 2024 at 1:05 PM Brian Gerst <brgerst@...il.com> wrote:
>
> On Thu, Nov 7, 2024 at 6:28 AM Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > On Tue, Nov 5, 2024 at 4:58 PM Brian Gerst <brgerst@...il.com> wrote:
> > >
> > > The percpu section is currently linked at absolute address 0, because
> > > older compilers hardcoded the stack protector canary value at a fixed
> > > offset from the start of the GS segment.  Now that the canary is a
> > > normal percpu variable, the percpu section does not need to be linked
> > > at a specific address.
> > >
> > > x86-64 will now calculate the percpu offsets as the delta between the
> > > initial percpu address and the dynamically allocated memory, like other
> > > architectures.  Note that GSBASE is limited to the canonical address
> > > width (48 or 57 bits, sign-extended).  As long as the kernel text,
> > > modules, and the dynamically allocated percpu memmory are all in the
> > > negative address space, the delta will not overflow this limit.
> > >
> > > Signed-off-by: Brian Gerst <brgerst@...il.com>
> > > ---
> > >  arch/x86/include/asm/processor.h |  6 +++++-
> > >  arch/x86/kernel/head_64.S        | 19 +++++++++----------
> > >  arch/x86/kernel/setup_percpu.c   | 12 ++----------
> > >  arch/x86/kernel/vmlinux.lds.S    | 29 +----------------------------
> > >  arch/x86/platform/pvh/head.S     |  5 ++---
> > >  arch/x86/tools/relocs.c          | 10 +++-------
> > >  arch/x86/xen/xen-head.S          |  9 ++++-----
> > >  init/Kconfig                     |  2 +-
> > >  8 files changed, 27 insertions(+), 65 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > > index a113c3f4f558..ae50d5d4fa26 100644
> > > --- a/arch/x86/include/asm/processor.h
> > > +++ b/arch/x86/include/asm/processor.h
> > > @@ -428,7 +428,11 @@ DECLARE_INIT_PER_CPU(fixed_percpu_data);
> > >
> > >  static inline unsigned long cpu_kernelmode_gs_base(int cpu)
> > >  {
> > > -       return (unsigned long)per_cpu(fixed_percpu_data.gs_base, cpu);
> > > +#ifdef CONFIG_SMP
> > > +       return per_cpu_offset(cpu);
> > > +#else
> > > +       return 0;
> > > +#endif
> > >  }
> > >
> > >  extern asmlinkage void entry_SYSCALL32_ignore(void);
> > > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> > > index c3028b4df85f..ffbcb0aea450 100644
> > > --- a/arch/x86/kernel/head_64.S
> > > +++ b/arch/x86/kernel/head_64.S
> > > @@ -61,11 +61,14 @@ SYM_CODE_START_NOALIGN(startup_64)
> > >         /* Set up the stack for verify_cpu() */
> > >         leaq    __top_init_kernel_stack(%rip), %rsp
> > >
> > > -       /* Setup GSBASE to allow stack canary access for C code */
> > > +       /*
> > > +        * Set up GSBASE.
> > > +        * Note that, on SMP, the boot cpu uses init data section until
> > > +        * the per cpu areas are set up.
> > > +        */
> > >         movl    $MSR_GS_BASE, %ecx
> > > -       leaq    INIT_PER_CPU_VAR(fixed_percpu_data)(%rip), %rdx
> > > -       movl    %edx, %eax
> > > -       shrq    $32,  %rdx
> > > +       xorl    %eax, %eax
> > > +       xorl    %edx, %edx
> >
> > You can use cltd after "xor %eax, %eax", it is one byte shorter with
> > the same effect ...
>
> I suppose that would work, but I'm not sure it's worth it to
> hyper-optimize boot code like this.  It's also confusing since the SDM
> calls this instruction CDQ instead of CLTD.

No big deal, indeed.

Reviewed-by: Uros Bizjak <ubizjak@...il.com>