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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250227184133.lxm43awa2jgdpl4q@desk>
Date: Thu, 27 Feb 2025 10:41:33 -0800
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: x86@...nel.org, Josh Poimboeuf <jpoimboe@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/speculation: Simplify and make CALL_NOSPEC consistent

On Thu, Feb 27, 2025 at 12:49:48AM +0000, Andrew Cooper wrote:
> On 26/02/2025 9:03 pm, Pawan Gupta wrote:
> > @@ -420,20 +420,28 @@ static inline void call_depth_return_thunk(void) {}
> >  
> >  #ifdef CONFIG_X86_64
> >  
> > +/*
> > + * Equivalent to -mindirect-branch-cs-prefix; emit the 5 byte jmp/call
> > + * to the retpoline thunk with a CS prefix when the register requires
> > + * a REX prefix byte to encode. Also see apply_retpolines().
> > + */
> 
> Technically, both comments aren't quite accurate.  __CS_PREFIX() emits a
> conditional CS prefix in a manner compatible with
> -mindirect-branch-cs-prefix, not the full 5/6 byte jmp/call.

You are right, I will update the comment, and also the ASSEMBLY version
where this comment came from:

  /*
   * Equivalent to -mindirect-branch-cs-prefix; emit the 5 byte jmp/call
   * to the retpoline thunk with a CS prefix when the register requires
   * a REX prefix byte to encode. Also see apply_retpolines().
   */
  .macro __CS_PREFIX reg:req
          .irp rs,r8,r9,r10,r11,r12,r13,r14,r15
          .ifc \reg,\rs
          .byte 0x2e
          .endif
          .endr
  .endm

> > +#define __CS_PREFIX(reg)				\
> > +	.irp rs,r8,r9,r10,r11,r12,r13,r14,r15;		\
> > +	.ifc \\rs, \reg;				\
> 
> Why are these escaped differently?  Given they're all \r of some form or
> another, I guess something is going wonky with __stringify(), but its
> still weird for them to be different.
> 
> Do you have a fully pre-processed source to hand to see how CALL_NOSPEC
> ends up?

Below is the pre-processed source for test_cc() generated with "make arch/x86/kvm/emulate.i".

- This is with double backslash in ".ifc \\rs, \reg":

	asm("push %[flags]; popf; " ".irp rs,r8,r9,r10,r11,r12,r13,r14,r15; .ifc \\rs, \%V[thunk_target]; .byte 0x2e; .endif; .endr;" "call __x86_indirect_thunk_%V[thunk_target]\n"
                                                                                  ^
	This ends up emitting the CS prefix byte correctly:

	2e e8 51 c9 32 01       cs call ffffffff824289e0

- This is with single backslash in ".ifc \\rs, \reg":

	asm("push %[flags]; popf; " ".irp rs,r8,r9,r10,r11,r12,r13,r14,r15; .ifc \rs, \%V[thunk_target]; .byte 0x2e; .endif; .endr;" "c      all __x86_indirect_thunk_%V[thunk_target]\n"
                                                                                  ^
	This version does not emit the CS prefix byte:

	e8 52 c9 32 01          call   ffffffff824289e0

I tried looking in gcc inline assembly documentation but could not find
anything that would explain this. :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ