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 barrier
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 CSEL-CSDB-LDR
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 ins
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 proba
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
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
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 ins
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
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 this
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 beha
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 unders
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 l
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
> > anyhow
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
>> s
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 rathe
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 2
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
.eabi_at
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 the
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,
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
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 g
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, Google Project Zero disclosed several classes of attac
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 jump-ar
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. One of these, known as varia
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 explicit bounds checks to
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 ARM-sp
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 appe
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 ob
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 canno
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 UNSP
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 Project Zero disclosed several classes of attack
>>>
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
>>> against speculative execution. One of these, know
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 explicit bounds checks to be by
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
> speculation, providing an arbitrar
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 that
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 gadget. Further details can
be found on the GPZ blog [1] an
36 matches
Mail list logo
