On Sun, 2018-01-14 at 21:52 +0100, Uros Bizjak wrote:
>
> Well, you did say that these are strange times ;)
>
> From the user perspective, it would be more convenient to use the
> thunk names that are the same for 32bit and 64bit targets. If we
> ignore this fact, the difference is only a couple
At the last minute, they were switched from __x86_indirect_thunk_rax to
__x86_indirect_thunk_ax without the 'r' or 'e' on the register name.
Except for the _r[89..] versions, obviously.
This is not entirely an improvement, IMO.
Reluctantly-signed-off-by: David Woodh
On Sun, 2018-01-14 at 15:02 -0800, Linus Torvalds wrote:
> On Sun, Jan 14, 2018 at 2:39 PM, David Woodhouse > wrote:
> >
> > I'm not convinced we want to do this, but I'll defer to Linus.
>
> Well, I guess we have no choice, if gcc ends up using the stupid
&
eding those _ASM_AX etc. macros in *addition* to
the bare "ax" that goes in the symbol names.
I'm not convinced we want to do this, but I'll defer to Linus.
From 755f50731a99b0ce0890e478e6a2d6ebd647da15 Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Sun, 14 Jan 2018 22
On Sun, 2018-01-14 at 14:03 -0800, H.J. Lu wrote:
>
> > And *that* was the point at which I asked HJ to just use the proper
> > bloody register names :)
>
> Please let me know if I should make the change to ax,..., r8,..r15.
This is what I'm building my compiler with now, to make that change:
ht
On Sun, 2018-01-14 at 13:07 -0800, Linus Torvalds wrote:
> On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
> >
> > Review on the GCC patches has led to a request that the thunk symbols
> > be changed from e.g. __x86_indirect_thunk_rax to
> > __x86_indirect_thu
On Sun, 2018-01-14 at 13:07 -0800, Linus Torvalds wrote:
> On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
> > Review on the GCC patches has led to a request that the thunk symbols
> > be changed from e.g. __x86_indirect_thunk_rax to
> > __x86_indirect_thunk_ax withou
On Sun, 2018-01-14 at 21:52 +0100, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 9:34 PM, David Woodhouse wrote:
> > But sure, right now it isn't that might of a difference for me; my
> > implementation has changed since I made that reqeust. I have no
> > fundamental
On Sun, 2018-01-14 at 21:21 +0100, Uros Bizjak wrote:
> A quick look through latest x86/pti update [1] shows:
>
> +#ifdef CONFIG_X86_32
> +#define INDIRECT_THUNK(reg) extern asmlinkage void
> __x86_indirect_thunk_e ## reg(void);
> +#else
> +#define INDIRECT_THUNK(reg) extern asmlinkage void
> __x8
On Sun, 2018-01-14 at 12:06 +0100, Jan Hubicka wrote:
>
> Yes, according to my understanding we want both pause and lefence by default
> (it is expensive anyway) + command line option to control which one to use?
>
> Probably thus the first patch should default to both.
In the kernel we're going
On Sat, 2018-01-13 at 08:46 -0800, H.J. Lu wrote:
>
> >> +@item -mindirect-branch-register
> >> +@opindex -mindirect-branch-register
> >> +Force indirect call and jump via register.
> >
> > Again I think this option needs better documentation. It is not quite
> > clear to me why
> > it is needed
On Sat, 2018-01-13 at 03:11 +, Kumar, Venkataramanan wrote:
>
> > My original patch uses "lfence". I was asked to use "pause":
> >
> > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00969.html
>
> If everyone is ok, my suggestion is to use "lfence" as the default
> loop filler for retpoline
On Sat, 2018-01-13 at 09:17 -0700, Jeff Law wrote:
> On 01/13/2018 02:03 AM, David Woodhouse wrote:
> > On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
> > As things stand with retpoline in the kernel, userspace processes
> > aren't protected from each other. The
On Sat, 2018-01-13 at 13:01 +0100, Florian Weimer wrote:
> * David Woodhouse:
>
> >
> > >
> > > Do you assume that you will eventually apply run-time patching to
> > > thunks (in case they aren't needed)?
> > "eventually"? We
On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
>
> WRT text relocs, yea that sucks, but if we're going to have user space
> mitigations, then we're likely going to need those relocs so that the
> thunks can be patched out. I'm actually hoping we're not going to need
> user space mitigations f
On Sat, 2018-01-13 at 03:11 +, Kumar, Venkataramanan wrote:
>
> > My original patch uses "lfence". I was asked to use "pause":
> >
> > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00969.html
>
> If everyone is ok, my suggestion is to use "lfence" as the default
> loop filler for retpoline
On Thu, 2018-01-11 at 22:17 +0100, Florian Weimer wrote:
> * David Woodhouse:
>
> >
> > On Sun, 2018-01-07 at 16:36 -0700, Jeff Law wrote:
> > >
> > >
> > > My fundamental problem with this patchkit is that it is 100% x86/x86_64
> > > sp
On Mon, 2018-01-08 at 14:27 -0800, Andi Kleen wrote:
> On Mon, Jan 08, 2018 at 09:35:26PM +0000, David Woodhouse wrote:
> > On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote:
> > > On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> > > &
On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> >
> > "H.J. Lu" writes:
> > >
> > > >
> > > >
> > > > Talking about PIC thunks, those have I believe . character in their
> > > > symbols,
> > > > so that they can't be confused with user
On Mon, 2018-01-08 at 03:59 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 1:56 AM, Martin Liška wrote:
> >
> > On 01/07/2018 11:59 PM, H.J. Lu wrote:
> > >
> > > Function return thunk is the same as memory thunk for -mindirect-branch=
> > > where the return address is at the top of the stack:
>
On Mon, 2018-01-08 at 09:20 +0100, Florian Weimer wrote:
> * H. J. Lu:
>
> > Add -mindirect-branch-loop= option to control loop filler in call and
> > return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
> > as loop filler. 'pause' uses "pause" as loop filler. 'nop' uses "nop"
On Sun, 2018-01-07 at 16:36 -0700, Jeff Law wrote:
>
> My fundamental problem with this patchkit is that it is 100% x86/x86_64
> specific.
>
> ISTM we want a target independent mechanism (ie, new standard patterns,
> options, etc) then an x86/x86_64 implementation using that target
> independent
On Mon, 2018-01-08 at 09:27 +0100, Florian Weimer wrote:
> * H. J. Lu:
>
> >
> > This set of patches for GCC 8 mitigates variant #2 of the
> > speculative execution vulnerabilities on x86 processors identified
> > by CVE-2017-5715, aka Spectre. They convert indirect branches to
> > call and retu
23 matches
Mail list logo
