Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/09/2018 08:29 AM, Richard Earnshaw (lists) wrote: > I'm in two minds about that. There are certainly cases where you might > want to use the generic expansion as part of handling a case where you > have a more standard speculation barrier; in those cases you might want > to emit your

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/09/2018 03:47 AM, Richard Earnshaw (lists) wrote: > On 05/01/18 13:08, Alexander Monakov wrote: >> On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote: >>> This is quite tricky. For ARM we have to have a speculated load. >> >> Sorry, I don't follow. On ARM, it is surprising that

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/09/18 18:50, Richard Earnshaw (lists) wrote: > On 09/01/18 17:36, Bernd Edlinger wrote: >> Richard Earnshaw wrote: >>  > Let me give an example, we use the generic code expansion if we >>  > encounter the builtin when generating code for Thumb on pre-ARMv7 >>  > devices.  We don't have

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/09/18 19:08, Richard Earnshaw (lists) wrote: > > But we probably don't need to. > > int x __attribute__((mode(TI))) = 0; > > $ arm-none-elf-gcc timode.c > > /tmp/ti.c:1:1: error: unable to emulate ‘TI’ > int x __attribute__((mode(TI))) = 0; > ^~~ > Yes, good, then you should

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 18:00, Richard Earnshaw (lists) wrote: > On 09/01/18 17:57, Bernd Edlinger wrote: >> On 01/09/18 18:50, Richard Earnshaw (lists) wrote: >>> On 09/01/18 17:36, Bernd Edlinger wrote: Richard Earnshaw wrote:    > Let me give an example, we use the generic code expansion if we

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 17:57, Bernd Edlinger wrote: > On 01/09/18 18:50, Richard Earnshaw (lists) wrote: >> On 09/01/18 17:36, Bernd Edlinger wrote: >>> Richard Earnshaw wrote: >>>   > Let me give an example, we use the generic code expansion if we >>>   > encounter the builtin when generating code for Thumb

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/09/18 18:50, Richard Earnshaw (lists) wrote: > On 09/01/18 17:36, Bernd Edlinger wrote: >> Richard Earnshaw wrote: >>  > Let me give an example, we use the generic code expansion if we >>  > encounter the builtin when generating code for Thumb on pre-ARMv7 >>  > devices.  We don't have

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 17:36, Bernd Edlinger wrote: > Richard Earnshaw wrote: >  > Let me give an example, we use the generic code expansion if we >  > encounter the builtin when generating code for Thumb on pre-ARMv7 >  > devices.  We don't have instructions in 'thumb1' to guard against >  > speculation and

Re: [PATCH 0/3] Add __builtin_load_no_speculate

Richard Earnshaw wrote: > Let me give an example, we use the generic code expansion if we > encounter the builtin when generating code for Thumb on pre-ARMv7 > devices. We don't have instructions in 'thumb1' to guard against > speculation and we really want to warn users that they've done

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 17:26, Jeff Law wrote: > On 01/04/2018 11:20 AM, Joseph Myers wrote: >> On Thu, 4 Jan 2018, Richard Earnshaw wrote: >> >>> 1 - generic modifications to GCC providing the builtin function for all >>> architectures and expanding to an implementation that gives the >>> logical

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote: > Read condition 1 i) again. > > > i) the conditional select instruction has a register data dependency on > a load R1, that has been executed speculatively, for one of its input > registers, and Sorry - I don't know how I missed that. I

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 13:27, Alexander Monakov wrote: > On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote: >> > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence >> > wouldn't work (applying CSEL to the address rather than loaded value), and >> > if it wouldn't, then ARM-specific

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote: > > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence > > wouldn't work (applying CSEL to the address rather than loaded value), and > > if it wouldn't, then ARM-specific lowering of the builtin can handle that > >

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 17:24, Jeff Law wrote: > On 01/04/2018 06:58 AM, Richard Earnshaw wrote: >> >> Recently, Google Project Zero disclosed several classes of attack >> against speculative execution. One of these, known as variant-1 >> (CVE-2017-5753), allows explicit bounds checks to be bypassed under >>

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 13:08, Alexander Monakov wrote: > On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote: >> This is quite tricky. For ARM we have to have a speculated load. > > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence > wouldn't work (applying CSEL to the address

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 08/01/18 16:10, Bernd Edlinger wrote: > I thought about your new builtin again, and I wonder if > something like that might work as well? > > > cat despec.s > .arch armv7-a > .eabi_attribute 28, 1 > .eabi_attribute 20, 1 > .eabi_attribute 21, 1 > .eabi_attribute

Re: [PATCH 0/3] Add __builtin_load_no_speculate

I thought about your new builtin again, and I wonder if something like that might work as well? cat despec.s .arch armv7-a .eabi_attribute 28, 1 .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1

Re: [PATCH 0/3] Add __builtin_load_no_speculate

Hi Guys, It seems to me that it might be worth taking a step back here, and consider adding a security framework to gcc. Mitigations for CVEs in the past have resulted in individual patches being added to gcc, oftern in a target specific manner, and with no real framework to support

Re: [PATCH 0/3] Add __builtin_load_no_speculate

Hi Richard, I wonder how to use this builtin correctly. Frankly it sounds like way too complicated. Do you expect we need to use this stuff on every array access now, or is that just a theoretical thing that can only happen with jave byte code interpreters? If I assume there is an array of int,

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/04/2018 11:20 AM, Joseph Myers wrote: > On Thu, 4 Jan 2018, Richard Earnshaw wrote: > >> 1 - generic modifications to GCC providing the builtin function for all >> architectures and expanding to an implementation that gives the >> logical behaviour of the builtin only. A warning is

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/04/2018 06:58 AM, Richard Earnshaw wrote: > > Recently, Google Project Zero disclosed several classes of attack > against speculative execution. One of these, known as variant-1 > (CVE-2017-5753), allows explicit bounds checks to be bypassed under > speculation, providing an arbitrary read

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/05/2018 03:47 AM, Richard Biener wrote: > On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists) > wrote: >> On 05/01/18 09:44, Richard Biener wrote: >>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw >>> wrote: Recently,

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/05/2018 04:57 AM, Richard Earnshaw (lists) wrote: > On 05/01/18 11:35, Jakub Jelinek wrote: >> On Fri, Jan 05, 2018 at 10:59:21AM +, Richard Earnshaw (lists) wrote: But the condition could be just 'true' in the instruction encoding? That is, why do you do both the

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/05/2018 03:40 AM, Richard Earnshaw (lists) wrote: > On 05/01/18 09:44, Richard Biener wrote: >> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw >> wrote: >>> >>> Recently, Google Project Zero disclosed several classes of attack >>> against speculative execution.

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 01/05/2018 02:44 AM, Richard Biener wrote: > On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw > wrote: >> >> Recently, Google Project Zero disclosed several classes of attack >> against speculative execution. One of these, known as variant-1 >> (CVE-2017-5753), allows

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote: > This is quite tricky. For ARM we have to have a speculated load. Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence wouldn't work (applying CSEL to the address rather than loaded value), and if it wouldn't, then

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 11:35, Jakub Jelinek wrote: > On Fri, Jan 05, 2018 at 10:59:21AM +, Richard Earnshaw (lists) wrote: >>> But the condition could be just 'true' in the instruction encoding? That >>> is, >>> why do you do both the jump-around and the csel? Maybe I misunderstood >>> the RTL you

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 11:37, Alexander Monakov wrote: > I believe the proposed behavior of the new builtin is over-specialized. > In principle the following snippet may be open to exploitation too: > >   if (predicate) >     foo = arr[(secret >> untrusted) & 64]; > > assuming the attacker has a means to

Re: [PATCH 0/3] Add __builtin_load_no_speculate

I believe the proposed behavior of the new builtin is over-specialized. In principle the following snippet may be open to exploitation too: if (predicate) foo = arr[(secret >> untrusted) & 64]; assuming the attacker has a means to observe which part of 'arr' is brought into cache, but

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Fri, Jan 05, 2018 at 10:59:21AM +, Richard Earnshaw (lists) wrote: > > But the condition could be just 'true' in the instruction encoding? That > > is, > > why do you do both the jump-around and the csel? Maybe I misunderstood > > the RTL you appear to generate. I'd have expected an

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 10:47, Richard Biener wrote: > On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists) > wrote: >> On 05/01/18 09:44, Richard Biener wrote: >>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw >>> wrote: Recently, Google

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists) wrote: > On 05/01/18 09:44, Richard Biener wrote: >> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw >> wrote: >>> >>> Recently, Google Project Zero disclosed several classes of attack

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 09:44, Richard Biener wrote: > On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw > wrote: >> >> Recently, Google Project Zero disclosed several classes of attack >> against speculative execution. One of these, known as variant-1 >> (CVE-2017-5753), allows

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw wrote: > > Recently, Google Project Zero disclosed several classes of attack > against speculative execution. One of these, known as variant-1 > (CVE-2017-5753), allows explicit bounds checks to be bypassed under >

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On Thu, 4 Jan 2018, Richard Earnshaw wrote: > 1 - generic modifications to GCC providing the builtin function for all > architectures and expanding to an implementation that gives the > logical behaviour of the builtin only. A warning is generated if > this expansion path is used