On Thu, 2018-01-18 at 08:52 +0100, Uros Bizjak wrote:
> This puts an extra burden on the developer, which has to use correct
> thunk name in their code. Sure, this can be solved trivially with
> #ifdef __x86_64__, so the issue is minor, but I thought it has to be
> mentioned before the name is set
On Wed, Jan 17, 2018 at 7:29 PM, Woodhouse, David wrote:
> I'm not sure I understand the concern. When compiling a large project for
> -m32 vs. -m64, there must be a million times the compiler has to decide
> whether to emit "r" or "e" before a register name. HJ's patch already does
> this for the
I'm not sure I understand the concern. When compiling a large project for -m32
vs. -m64, there must be a million times the compiler has to decide whether to
emit "r" or "e" before a register name. HJ's patch already does this for the
thunk symbol. What is the future requirement that I am not und
On Sun, Jan 14, 2018 at 5:43 PM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
> Hi Uros,
>
>>
Hi Richard,
> I'm quite sure Solaris supports comdats, after all it invented ELF ;)
true: gcc/configure.ac has
# Sun ld has COMDAT group support since Solaris 9, but it doesn't
# interoperate with GNU as until Solaris 11 build 130, i.e. ld
# version 1.688.
#
# If us
Hi Jan,
>> It makes the option using thunks unusable though, right? Can you simply make
>> them hidden on systems without comdat support? That duplicates them per TU
>> but at least the feature works. Or those systems should provide the
>> thunks via
>> libgcc.
>>
>> I agree we can followup wi
Hi Richard,
>>> Backport is blocked by
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83838
>>>
>>> There are many test failures due to lack of comdat support in linker on
>>> Solaris.
actually this is lack of hidden .gnu.linkonce support right now.
Currently that's disabled for all but gld
On Tue, Jan 16, 2018 at 12:34 AM, Jan Hubicka wrote:
>> On Mon, Jan 15, 2018 at 5:53 PM, H.J. Lu wrote:
>> > On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
>> >> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
>> >> wrote:
>> >>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
>> Now my
> On Tue, Jan 16, 2018 at 9:34 AM, Jan Hubicka wrote:
> >> On Mon, Jan 15, 2018 at 5:53 PM, H.J. Lu wrote:
> >> > On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
> >> >> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
> >> >> wrote:
> >> >>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
> >
On Tue, Jan 16, 2018 at 9:34 AM, Jan Hubicka wrote:
>> On Mon, Jan 15, 2018 at 5:53 PM, H.J. Lu wrote:
>> > On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
>> >> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
>> >> wrote:
>> >>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
>> Now my
> On Mon, Jan 15, 2018 at 5:53 PM, H.J. Lu wrote:
> > On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
> >> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
> >> wrote:
> >>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
> Now my patch set has been checked into trunk. Here is a patch set
On Mon, Jan 15, 2018 at 5:53 PM, H.J. Lu wrote:
> On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
>> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
>> wrote:
>>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
Now my patch set has been checked into trunk. Here is a patch set
to mov
> On Mon, Jan 15, 2018 at 8:53 AM, H.J. Lu wrote:
> > On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
> >> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
> >> wrote:
> >>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
> Now my patch set has been checked into trunk. Here is a patch set
On Mon, Jan 15, 2018 at 8:53 AM, H.J. Lu wrote:
> On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
>> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
>> wrote:
>>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
Now my patch set has been checked into trunk. Here is a patch set
to mov
On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
> wrote:
>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
>>> Now my patch set has been checked into trunk. Here is a patch set
>>> to move struct ix86_frame to machine_function on GCC 7, which
On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
wrote:
> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
>> Now my patch set has been checked into trunk. Here is a patch set
>> to move struct ix86_frame to machine_function on GCC 7, which is
>> needed to backport the patch set to GCC 7:
>>
>> h
On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
> Now my patch set has been checked into trunk. Here is a patch set
> to move struct ix86_frame to machine_function on GCC 7, which is
> needed to backport the patch set to GCC 7:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01239.html
> https:
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
izjak (ubiz...@gmail.com)
>
> Subject: Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>
> On Sun, Jan 14, 2018 at 6:20 AM, Jan Hubicka wrote:
> >> > Hi HJ,
> >> >
> >> > > -Original Message-
> >> > > From: gcc-patches-ow...@gcc.g
On Sun, Jan 14, 2018 at 3:09 PM, David Woodhouse wrote:
>
> I think we should stick with what we have now, with the names of the
> thunks actually being the *full* name of the register (rax, eax, etc.)
> that they use.
It that works for the gcc people, then yes, I agree. The mixed
"sometimes full
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
> names.
At this point, they'll do what
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 names.
And yes, apparently this just made our macros worse instead of
cleaning anything up. Oh well.
I do h
On Sun, 2018-01-14 at 14:12 -0800, H.J. Lu wrote:
> Please use this GCC patch instead.
Building now; thanks.
This is the kernel patch I'll test as soon as the compiler is done.
It's slightly less horrid than the "clever" one I sent out earlier, but
does still end up needing those _ASM_AX etc. mac
On Sun, Jan 14, 2018 at 2:09 PM, David Woodhouse wrote:
> 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 i
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, Jan 14, 2018 at 1:58 PM, David Woodhouse wrote:
> 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_th
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 without the 'r'.
> Ok.
On Sun, Jan 14, 2018 at 1:07 PM, 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 without the 'r'.
>
> Ok. I think
On Sun, 14 Jan 2018, David Woodhouse wrote:
> 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 t
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 without the 'r'.
>
> Ok. I
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 without the 'r'.
Ok. I think that just makes it easier for us, since then the names are
inde
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 technical objection to the bare
On Sun, Jan 14, 2018 at 9:34 PM, David Woodhouse wrote:
> Likewise, the CONFIG_TRIM_UNUSED_SYMBOLS mechanism in the kernel passes
> .S files through the preprocessor and looks for EXPORT_SYMBOL, so it
> wasn't working well with my .irp-based implementation like the one in
> Xen. So I've swapped i
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, Jan 14, 2018 at 7:22 PM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 6:44 PM, Woodhouse, David wrote:
>> This won't make the list; I'll send a more coherent and less HTML-afflicted
>> version later.
>>
>> The bare 'ax' naming made it painful to instantiate the external thunks for
>> 32-b
On Sun, Jan 14, 2018 at 6:44 PM, Woodhouse, David wrote:
> This won't make the list; I'll send a more coherent and less HTML-afflicted
> version later.
>
> The bare 'ax' naming made it painful to instantiate the external thunks for
> 32-bit and 64-bot code because we had to put the e/r back again
This won't make the list; I'll send a more coherent and less HTML-afflicted
version later.
The bare 'ax' naming made it painful to instantiate the external thunks for
32-bit and 64-bot code because we had to put the e/r back again inside the .irp
reg ax bx... code.
We could probably have lived
On Sun, Jan 14, 2018 at 8:45 AM, Jakub Jelinek wrote:
> On Sun, Jan 14, 2018 at 08:41:54AM -0800, H.J. Lu wrote:
>> They are used in asm statements in kernel:
>>
>> extern void (*func_p) (void);
>>
>> void
>> foo (void)
>> {
>> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
>
> Well, us
On Sun, Jan 14, 2018 at 8:48 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:41 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 8:39 AM, Uros Bizjak wrote:
>>> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
> On Fri, Jan 12, 2018 a
On Sun, Jan 14, 2018 at 5:41 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 8:39 AM, Uros Bizjak wrote:
>> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
> On Thu, Jan 11, 2018 a
On Sun, Jan 14, 2018 at 08:41:54AM -0800, H.J. Lu wrote:
> They are used in asm statements in kernel:
>
> extern void (*func_p) (void);
>
> void
> foo (void)
> {
> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
Well, using it just with a single register classes wouldn't make much sens
On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
>>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>>>
Hi Uros,
Can you take a look at my x86 backend changes so that they
On Sun, Jan 14, 2018 at 8:39 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
> Hi Uros,
>
>>
On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
>>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>>>
Hi Uros,
Can you take a look at my x86 backend changes so that they
On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>>
>>> Hi Uros,
>>>
>>> Can you take a look at my x86 backend changes so that they are ready
>>> to check in once we have consensus.
>>
>>
On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>
>> Hi Uros,
>>
>> Can you take a look at my x86 backend changes so that they are ready
>> to check in once we have consensus.
>
> Please finish the talks about the correct approach first. Once
Now my patch set has been checked into trunk. Here is a patch set
to move struct ix86_frame to machine_function on GCC 7, which is
needed to backport the patch set to GCC 7:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01239.html
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01240.html
https://g
unday, January 14, 2018 9:07 AM
>> > > To: gcc-patches@gcc.gnu.org
>> > > Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>> > >
>> > > This set of patches for GCC 8 mitigates variant #2 of the speculative
>> > > execution vulnerabi
> > Hi HJ,
> >
> > > -Original Message-
> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> > > Sent: Sunday, January 14, 2018 9:07 AM
> > > To: gcc-patches@gcc.gnu.org
&
>> > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>> >> > Sent: Sunday, January 14, 2018 9:07 AM
>> >> > To: gcc-patches@gcc.gnu.org
>> >> > Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>> >> >
>> >> > This set
: Sunday, January 14, 2018 9:07 AM
> >> > To: gcc-patches@gcc.gnu.org
> >> > Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
> >> >
> >> > This set of patches for GCC 8 mitigates variant #2 of the speculative
> >> > execution vulner
AM
>> > To: gcc-patches@gcc.gnu.org
>> > Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>> >
>> > This set of patches for GCC 8 mitigates variant #2 of the speculative
>> > execution vulnerabilities on x86 processors identified by CVE-2017-5
> Hi HJ,
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> > Sent: Sunday, January 14, 2018 9:07 AM
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH 0/5] x86: CV
Hi HJ,
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Sunday, January 14, 2018 9:07 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>
> Thi
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 and function returns to
call and return thunks to avoid speculative execution via indirect
call, jmp and ret.
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've been doing it for weeks. We are desperate to
> > release the kernel
* David Woodhouse:
>> Do you assume that you will eventually apply run-time patching to
>> thunks (in case they aren't needed)?
>
> "eventually"? We've been doing it for weeks. We are desperate to
> release the kernel when can we have agreement on at *least* the
> command line option and the n
On Fri, Jan 12, 2018 at 6:50 AM, Jan Hubicka wrote:
>> On Fri, Jan 12, 2018 at 12:01 AM, Uros Bizjak wrote:
>> > On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>> >
>> >> Hi Uros,
>> >>
>> >> Can you take a look at my x86 backend changes so that they are ready
>> >> to check in once we have con
> On Fri, Jan 12, 2018 at 12:01 AM, Uros Bizjak wrote:
> > On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
> >
> >> Hi Uros,
> >>
> >> Can you take a look at my x86 backend changes so that they are ready
> >> to check in once we have consensus.
> >
> > Please finish the talks about the correct ap
On Fri, Jan 12, 2018 at 12:01 AM, Uros Bizjak wrote:
> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>
>> Hi Uros,
>>
>> Can you take a look at my x86 backend changes so that they are ready
>> to check in once we have consensus.
>
> Please finish the talks about the correct approach first. Once
On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
> Hi Uros,
>
> Can you take a look at my x86 backend changes so that they are ready
> to check in once we have consensus.
Please finish the talks about the correct approach first. Once the
consensus is reached, please post the final version of the
On 01/11/2018 04:40 PM, Joseph Myers wrote:
> On Thu, 11 Jan 2018, Jeff Law wrote:
>
>>> Well, given retpolines are largely kernel relevant right now we don't
>>> need to care here.
>> That's still TBD as far as I can tell. I certainly hope we don't have
>> to go retpolines in user space, at leas
On Thu, 11 Jan 2018, Jeff Law wrote:
> > Well, given retpolines are largely kernel relevant right now we don't
> > need to care here.
> That's still TBD as far as I can tell. I certainly hope we don't have
> to go retpolines in user space, at least not in the general case. I'm
> holding out hope
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
> > > specific.
> > >
> > > ISTM we want a target independent mec
* 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
>> specific.
>>
>> ISTM we want a target independent mechanism (ie, new standard patterns,
>> options, etc) then an x86/x86_64 implementation usin
On 01/11/2018 03:16 AM, Richard Biener wrote:
> On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law wrote:
>> On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
>>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
wrote:
>> It's really
On 01/11/2018 03:04 AM, Alan Modra wrote:
> On Wed, Jan 10, 2018 at 05:13:36PM -0700, Jeff Law wrote:
>> On 01/08/2018 07:23 AM, Alan Modra wrote:
>>> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
On 01/07/2018 03:58 PM, H.J. Lu wrote:
> This set of patches for GCC 8 mitigates
On Thu, Jan 11, 2018 at 2:16 AM, Richard Biener
wrote:
> On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law wrote:
>> On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
>>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
wrote:
>> I
On Mon, Jan 8, 2018 at 3:37 AM, H.J. Lu wrote:
> On Sun, Jan 7, 2018 at 8:07 PM, Sandra Loosemore
> wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>>
>>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>>> execution
>>> vulnerabilities on x86 processors identified by CVE-
On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law wrote:
> On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
>>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
>>> wrote:
> It's really just a couple of new primitives to emit a jump as a
On Wed, Jan 10, 2018 at 2:52 PM, H.J. Lu wrote:
> On Wed, Jan 10, 2018 at 5:14 AM, Jakub Jelinek wrote:
>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
>>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
>>> wrote:
>>> >> It's really just a couple of new primitives to emit a
On Wed, Jan 10, 2018 at 05:13:36PM -0700, Jeff Law wrote:
> On 01/08/2018 07:23 AM, Alan Modra wrote:
> > On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
> >> On 01/07/2018 03:58 PM, H.J. Lu wrote:
> >>> This set of patches for GCC 8 mitigates variant #2 of the speculative
> >>> executio
On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
>> wrote:
It's really just a couple of new primitives to emit a jump as a call and
one to slam in a new return address. Give
On 01/08/2018 07:23 AM, Alan Modra wrote:
> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>>> execution
>>> vulnerabilities on x86 processors identified by CVE-2017-5715,
On Wed, Jan 10, 2018 at 5:14 AM, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
>> wrote:
>> >> It's really just a couple of new primitives to emit a jump as a call and
>> >> one to slam in a new return ad
On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou wrote:
> >> It's really just a couple of new primitives to emit a jump as a call and
> >> one to slam in a new return address. Given those I think you can do the
> >> entire implement
On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou wrote:
>> It's really just a couple of new primitives to emit a jump as a call and
>> one to slam in a new return address. Given those I think you can do the
>> entire implementation as RTL at expansion time and you've got a damn
>> good shot at pro
On Wed, Jan 10, 2018 at 2:18 AM, Eric Botcazou wrote:
>> It's really just a couple of new primitives to emit a jump as a call and
>> one to slam in a new return address. Given those I think you can do the
>> entire implementation as RTL at expansion time and you've got a damn
>> good shot at prot
> It's really just a couple of new primitives to emit a jump as a call and
> one to slam in a new return address. Given those I think you can do the
> entire implementation as RTL at expansion time and you've got a damn
> good shot at protecting most architectures from these kinds of attacks.
I t
On Tue, Jan 9, 2018 at 10:52 AM, Jeff Law wrote:
> On 01/07/2018 05:29 PM, H.J. Lu wrote:
>> On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law wrote:
>>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
This set of patches for GCC 8 mitigates variant #2 of the speculative
execution
vulnerabilities o
On 01/08/2018 03:01 AM, Martin Liška wrote:
> On 01/08/2018 01:29 AM, H.J. Lu wrote:
>> 1. They need to be backportable to GCC 7/6/5/4.x.
>
> I must admit this is very important constrain. To be honest, we're planning
> to backport the patchset to GCC 4.3.
Red Hat would likely be backporting a way
On 01/07/2018 05:29 PM, H.J. Lu wrote:
> On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>> 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
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
* Sandra Loosemore:
> I have a general documentation issue with all the new command-line
> options and attributes added by this patch set: the documentation is
> very implementor-speaky and doesn't explain what user-level problem
> they're trying to solve.
Agreed. Ideally, the documentation
* 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 return thunks to avoid speculative execution via indirect
> call and jmp.
Wou
Hi,
On Mon, 8 Jan 2018, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> > See:
> >
> > https://sourceware.org/ml/binutils/2017-11/msg00369.html
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0
On Mon, Jan 08, 2018 at 08:17:27AM -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 7:06 AM, Jakub Jelinek wrote:
> > On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> >> See:
> >>
> >> https://sourceware.org/ml/binutils/2017-11/msg00369.html
> >
> > Program Headers:
> > Type Of
On Mon, Jan 8, 2018 at 7:06 AM, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
>> See:
>>
>> https://sourceware.org/ml/binutils/2017-11/msg00369.html
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD
On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> See:
>
> https://sourceware.org/ml/binutils/2017-11/msg00369.html
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x00 0x 0x 0x00200 0x00200 R 0x20
LO
On Mon, Jan 8, 2018 at 6:23 AM, Alan Modra wrote:
> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>> > This set of patches for GCC 8 mitigates variant #2 of the speculative
>> > execution
>> > vulnerabilities on x86 processors identified by CV
On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
> On 01/07/2018 03:58 PM, H.J. Lu wrote:
> > 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.
[snip]
> My fundamental problem
On Sun, Jan 7, 2018 at 10:55 PM, Markus Trippelsdorf
wrote:
> On 2018.01.07 at 21:07 -0700, Sandra Loosemore wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>> > This set of patches for GCC 8 mitigates variant #2 of the speculative
>> > execution
>> > vulnerabilities on x86 processors identified
On Sun, Jan 7, 2018 at 8:07 PM, Sandra Loosemore
wrote:
> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>
>> 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 bran
On 01/08/2018 01:29 AM, H.J. Lu wrote:
> 1. They need to be backportable to GCC 7/6/5/4.x.
I must admit this is very important constrain. To be honest, we're planning
to backport the patchset to GCC 4.3.
Martin
On 2018.01.07 at 21:07 -0700, Sandra Loosemore wrote:
> On 01/07/2018 03:58 PM, H.J. Lu wrote:
> > 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 bra
On 01/07/2018 03:58 PM, H.J. Lu wrote:
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 return thunks to avoid speculative
execution
via indirec
On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law wrote:
> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>> 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 c
On 01/07/2018 03:58 PM, H.J. Lu wrote:
> 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 return thunks to avoid speculative
> execution
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 return thunks to avoid speculative
execution
via indirect call and jmp.
H.J. Lu (5):
x86: Add
100 matches
Mail list logo
