thr3ads.net - llvm dev - [llvm-dev] Spectre V1 Mitigation

If this information is useful, please help other people find it:
Share via:

Praveen Velliengiri via llvm-dev

2019-Sep-17 19:53 UTC

[llvm-dev] Spectre V1 Mitigation - Internals?

Hi,
Yeah, now I understand the problem here. Thanks.
But I too have another doubt in "Bounds check bypass store"

In this example in the Speculative load hardening :

unsigned char local_buffer[4];unsigned char
*untrusted_data_from_caller = ...;unsigned long
untrusted_size_from_caller = ...;if (untrusted_size_from_caller <
sizeof(local_buffer)) {
  // Speculative execution enters here with a too-large size.
  memcpy(local_buffer, untrusted_data_from_caller,
         untrusted_size_from_caller);
  // The stack has now been smashed, writing an attacker-controlled
  // address over the return address.
  minor_processing(local_buffer);
  return;
  // Control will speculate to the attacker-written address.}


During speculative execution, it stores an arbitrary data in the stack
memory (architectural state, I guess).
Doesn't that change the architectural state of the processor? I
learned that all stores are written to  register files first and then
if the speculative
execution is correct then it written back into memory, if not those
register files are reverted back. But in the above case the return
address
is loaded from the (stack) memory, for which the contents have to be
written to the memory first during the speculative execution. It
contradicts
my assumptions about the store operation in speculative execution.

Am I wrong here?


On Tue, 17 Sep 2019 at 21:30, Craig Topper <craig.topper at gmail.com>
wrote:
> The reverting of state doesn’t occur when the condition is available. The
> processor has to “execute” the branch uop and see that it was mispredicted.
> This occurs at least one cycle after the condition is available. The
> conditional move on the predicate state can execute at the same time as the
> branch. Or it can execute before it if the branch unit is busy. The load
> can do the same.
>
> On Tue, Sep 17, 2019 at 7:57 AM Praveen Velliengiri via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>> Thanks for your email, I understand that the execution stalls until the
>> predicated state is computed, then we mask pointers with all_zeros_mask
if
>> there is a mis-prediction. But I understand that as soon as the
condition
>> value is available, the processor can check about it's assumptions
and
>> revert back.
>>
>> That is,
>> If the branch prediction is correct during speculation, we mask with
>> all_ones, the processor can follow the predicted branch to retire.
>> But if the processor mispredicted the branch, it will revert back as
soon
>> as condition become available if this is the case then we don't
execute
>> speculatively the operations : pointer1 &= predicate_state - (if
branch)
>> and *pointer2 & predicted_state - (else branch) right? Or
>> out-of-processor's allow such access?
>>
>> Plus, why we are masking with all_zeros_mask during mis-prediction. Is
>> there any reason for choosing all_zeros_mask?
>>
>> Cheers,
>> Praveen
>>
>>
>>
>> On Tue, 17 Sep 2019 at 17:08, Jeremy Lakeman <Jeremy.Lakeman at
gmail.com>
>> wrote:
>>
>>> There's a difference between control flow speculation and data
flow.
>>> By entangling the control flow & data, the cpu should stall the
memory
>>> load until the condition is known, since the pointer value also
isn't known.
>>>
>>> I assume that actual experts (not me) tested this, and / or asked
intel
>>> if this was sufficient to prevent the speculative memory load,
given how
>>> speculation is actually implemented.
>>>
>>> On Tue, 17 Sep 2019 at 02:04, Praveen Velliengiri via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I understand how the speculative information flow attack works.
I'm
>>>> trying get my head around the spectre v1 mitigation of LLVM.
>>>> In the design document here :
>>>>
https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening.
>>>>
<https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening>
>>>>
>>>> Example:
>>>>
>>>> void leak(int data);void example(int* pointer1, int* pointer2)
{
>>>>   if (condition)
>>>>     leak(*pointer1);
>>>>   else
>>>>     leak(*pointer2);}
>>>>
>>>> After the applying the mitigation the code resembles like:
>>>>
>>>> void leak(int data);
>>>> void example(int* pointer1, int* pointer2) {
>>>>   uintptr_t predicate_state = all_ones_mask;
>>>>   if (condition) {
>>>>     predicate_state = !condition ? all_zeros_mask :
predicate_state;
>>>>     pointer1 &= predicate_state;
>>>>     leak(*pointer1);
>>>>   } else {
>>>>     int value2 = *pointer2 & predicate_state;
>>>>     leak(value2);
>>>>   }
>>>> }
>>>>
>>>> Let's assume that the branch is mispredicted and if body is
taken. The value predicate_state mask is depend on the "result of the
condition" but which is not yet available hence
>>>>
>>>> speculative execution. My question whether the value of
predicate_state is also guessed by the processor? If it is correct, then the
value of predicate_state will be
>>>> predicate_state, if the processor mis-predicts the condition as
true. Is my assumption is correct? i.e predicate_state = ! 1 ? all_zeros_mask :
predicate_state, where processor predicts
>>>> condition as true.
>>>>
>>>> Or Whether the execution stalls at "predicate_state =
!condition ? all_zeros_mask : predicate_state until the result of condition
became available? If this is true, why we have to
>>>>
>>>> harden the pointers in the first place, because after the
condition is actually computed, the processors will revert back right the
execution trace of mis-prediction.
>>>>
>>>> I know that I'm missing something fundamental here, I would
highly appreciate your help on this? Please let me know if you more info!
>>>>
>>>> Cheeers,
>>>>
>>>> Praveen
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> --
> ~Craig
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190918/501b0033/attachment.html>

Craig Topper via llvm-dev

2019-Sep-17 20:31 UTC

head link

[llvm-dev] Spectre V1 Mitigation - Internals?

The store goes to the store buffer first and is only committed to memory at
retirement. Loads can get data forwarded from the store buffer so that the
load doesn't have to wait for the store to retire.

~Craig


On Tue, Sep 17, 2019 at 12:53 PM Praveen Velliengiri <
praveenvelliengiri at gmail.com> wrote:
> Hi,
> Yeah, now I understand the problem here. Thanks.
> But I too have another doubt in "Bounds check bypass store"
>
> In this example in the Speculative load hardening :
>
> unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller =
...;unsigned long untrusted_size_from_caller = ...;if
(untrusted_size_from_caller < sizeof(local_buffer)) {
>   // Speculative execution enters here with a too-large size.
>   memcpy(local_buffer, untrusted_data_from_caller,
>          untrusted_size_from_caller);
>   // The stack has now been smashed, writing an attacker-controlled
>   // address over the return address.
>   minor_processing(local_buffer);
>   return;
>   // Control will speculate to the attacker-written address.}
>
>
> During speculative execution, it stores an arbitrary data in the stack
memory (architectural state, I guess).
> Doesn't that change the architectural state of the processor? I learned
that all stores are written to  register files first and then if the speculative
> execution is correct then it written back into memory, if not those
register files are reverted back. But in the above case the return address
> is loaded from the (stack) memory, for which the contents have to be
written to the memory first during the speculative execution. It contradicts
> my assumptions about the store operation in speculative execution.
>
> Am I wrong here?
>
>
> On Tue, 17 Sep 2019 at 21:30, Craig Topper <craig.topper at
gmail.com> wrote:
>
>> The reverting of state doesn’t occur when the condition is available.
The
>> processor has to “execute” the branch uop and see that it was
mispredicted.
>> This occurs at least one cycle after the condition is available. The
>> conditional move on the predicate state can execute at the same time as
the
>> branch. Or it can execute before it if the branch unit is busy. The
load
>> can do the same.
>>
>> On Tue, Sep 17, 2019 at 7:57 AM Praveen Velliengiri via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>> Thanks for your email, I understand that the execution stalls until
the
>>> predicated state is computed, then we mask pointers with
all_zeros_mask if
>>> there is a mis-prediction. But I understand that as soon as the
condition
>>> value is available, the processor can check about it's
assumptions and
>>> revert back.
>>>
>>> That is,
>>> If the branch prediction is correct during speculation, we mask
with
>>> all_ones, the processor can follow the predicted branch to retire.
>>> But if the processor mispredicted the branch, it will revert back
as
>>> soon as condition become available if this is the case then we
don't
>>> execute speculatively the operations : pointer1 &=
predicate_state - (if
>>> branch) and *pointer2 & predicted_state - (else branch) right?
Or
>>> out-of-processor's allow such access?
>>>
>>> Plus, why we are masking with all_zeros_mask during mis-prediction.
Is
>>> there any reason for choosing all_zeros_mask?
>>>
>>> Cheers,
>>> Praveen
>>>
>>>
>>>
>>> On Tue, 17 Sep 2019 at 17:08, Jeremy Lakeman <Jeremy.Lakeman at
gmail.com>
>>> wrote:
>>>
>>>> There's a difference between control flow speculation and
data flow.
>>>> By entangling the control flow & data, the cpu should stall
the memory
>>>> load until the condition is known, since the pointer value also
isn't known.
>>>>
>>>> I assume that actual experts (not me) tested this, and / or
asked intel
>>>> if this was sufficient to prevent the speculative memory load,
given how
>>>> speculation is actually implemented.
>>>>
>>>> On Tue, 17 Sep 2019 at 02:04, Praveen Velliengiri via llvm-dev
<
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I understand how the speculative information flow attack
works. I'm
>>>>> trying get my head around the spectre v1 mitigation of
LLVM.
>>>>> In the design document here :
>>>>>
https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening.
>>>>>
<https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening>
>>>>>
>>>>> Example:
>>>>>
>>>>> void leak(int data);void example(int* pointer1, int*
pointer2) {
>>>>>   if (condition)
>>>>>     leak(*pointer1);
>>>>>   else
>>>>>     leak(*pointer2);}
>>>>>
>>>>> After the applying the mitigation the code resembles like:
>>>>>
>>>>> void leak(int data);
>>>>> void example(int* pointer1, int* pointer2) {
>>>>>   uintptr_t predicate_state = all_ones_mask;
>>>>>   if (condition) {
>>>>>     predicate_state = !condition ? all_zeros_mask :
predicate_state;
>>>>>     pointer1 &= predicate_state;
>>>>>     leak(*pointer1);
>>>>>   } else {
>>>>>     int value2 = *pointer2 & predicate_state;
>>>>>     leak(value2);
>>>>>   }
>>>>> }
>>>>>
>>>>> Let's assume that the branch is mispredicted and if
body is taken. The value predicate_state mask is depend on the "result of
the condition" but which is not yet available hence
>>>>>
>>>>> speculative execution. My question whether the value of
predicate_state is also guessed by the processor? If it is correct, then the
value of predicate_state will be
>>>>> predicate_state, if the processor mis-predicts the
condition as true. Is my assumption is correct? i.e predicate_state = ! 1 ?
all_zeros_mask : predicate_state, where processor predicts
>>>>> condition as true.
>>>>>
>>>>> Or Whether the execution stalls at "predicate_state =
!condition ? all_zeros_mask : predicate_state until the result of condition
became available? If this is true, why we have to
>>>>>
>>>>> harden the pointers in the first place, because after the
condition is actually computed, the processors will revert back right the
execution trace of mis-prediction.
>>>>>
>>>>> I know that I'm missing something fundamental here, I
would highly appreciate your help on this? Please let me know if you more info!
>>>>>
>>>>> Cheeers,
>>>>>
>>>>> Praveen
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> --
>> ~Craig
>>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190917/df313c30/attachment.html>

Praveen Velliengiri via llvm-dev

2019-Sep-18 20:29 UTC

head link

[llvm-dev] Spectre V1 Mitigation - Internals?

Hi Craig,
Thanks a lot for your help.

On Wed, 18 Sep 2019 at 02:01, Craig Topper <craig.topper at gmail.com>
wrote:
> The store goes to the store buffer first and is only committed to memory
> at retirement. Loads can get data forwarded from the store buffer so that
> the load doesn't have to wait for the store to retire.
>
> ~Craig
>
>
> On Tue, Sep 17, 2019 at 12:53 PM Praveen Velliengiri <
> praveenvelliengiri at gmail.com> wrote:
>
>> Hi,
>> Yeah, now I understand the problem here. Thanks.
>> But I too have another doubt in "Bounds check bypass store"
>>
>> In this example in the Speculative load hardening :
>>
>> unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller
= ...;unsigned long untrusted_size_from_caller = ...;if
(untrusted_size_from_caller < sizeof(local_buffer)) {
>>   // Speculative execution enters here with a too-large size.
>>   memcpy(local_buffer, untrusted_data_from_caller,
>>          untrusted_size_from_caller);
>>   // The stack has now been smashed, writing an attacker-controlled
>>   // address over the return address.
>>   minor_processing(local_buffer);
>>   return;
>>   // Control will speculate to the attacker-written address.}
>>
>>
>> During speculative execution, it stores an arbitrary data in the stack
memory (architectural state, I guess).
>> Doesn't that change the architectural state of the processor? I
learned that all stores are written to  register files first and then if the
speculative
>> execution is correct then it written back into memory, if not those
register files are reverted back. But in the above case the return address
>> is loaded from the (stack) memory, for which the contents have to be
written to the memory first during the speculative execution. It contradicts
>> my assumptions about the store operation in speculative execution.
>>
>> Am I wrong here?
>>
>>
>> On Tue, 17 Sep 2019 at 21:30, Craig Topper <craig.topper at
gmail.com>
>> wrote:
>>
>>> The reverting of state doesn’t occur when the condition is
available.
>>> The processor has to “execute” the branch uop and see that it was
>>> mispredicted. This occurs at least one cycle after the condition is
>>> available. The conditional move on the predicate state can execute
at the
>>> same time as the branch. Or it can execute before it if the branch
unit is
>>> busy. The load can do the same.
>>>
>>> On Tue, Sep 17, 2019 at 7:57 AM Praveen Velliengiri via llvm-dev
<
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>> Thanks for your email, I understand that the execution stalls
until the
>>>> predicated state is computed, then we mask pointers with
all_zeros_mask if
>>>> there is a mis-prediction. But I understand that as soon as the
condition
>>>> value is available, the processor can check about it's
assumptions and
>>>> revert back.
>>>>
>>>> That is,
>>>> If the branch prediction is correct during speculation, we mask
with
>>>> all_ones, the processor can follow the predicted branch to
retire.
>>>> But if the processor mispredicted the branch, it will revert
back as
>>>> soon as condition become available if this is the case then we
don't
>>>> execute speculatively the operations : pointer1 &=
predicate_state - (if
>>>> branch) and *pointer2 & predicted_state - (else branch)
right? Or
>>>> out-of-processor's allow such access?
>>>>
>>>> Plus, why we are masking with all_zeros_mask during
mis-prediction. Is
>>>> there any reason for choosing all_zeros_mask?
>>>>
>>>> Cheers,
>>>> Praveen
>>>>
>>>>
>>>>
>>>> On Tue, 17 Sep 2019 at 17:08, Jeremy Lakeman <Jeremy.Lakeman
at gmail.com>
>>>> wrote:
>>>>
>>>>> There's a difference between control flow speculation
and data flow.
>>>>> By entangling the control flow & data, the cpu should
stall the memory
>>>>> load until the condition is known, since the pointer value
also isn't known.
>>>>>
>>>>> I assume that actual experts (not me) tested this, and / or
asked
>>>>> intel if this was sufficient to prevent the speculative
memory load, given
>>>>> how speculation is actually implemented.
>>>>>
>>>>> On Tue, 17 Sep 2019 at 02:04, Praveen Velliengiri via
llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I understand how the speculative information flow
attack works. I'm
>>>>>> trying get my head around the spectre v1 mitigation of
LLVM.
>>>>>> In the design document here :
>>>>>>
https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening.
>>>>>>
<https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening>
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> void leak(int data);void example(int* pointer1, int*
pointer2) {
>>>>>>   if (condition)
>>>>>>     leak(*pointer1);
>>>>>>   else
>>>>>>     leak(*pointer2);}
>>>>>>
>>>>>> After the applying the mitigation the code resembles
like:
>>>>>>
>>>>>> void leak(int data);
>>>>>> void example(int* pointer1, int* pointer2) {
>>>>>>   uintptr_t predicate_state = all_ones_mask;
>>>>>>   if (condition) {
>>>>>>     predicate_state = !condition ? all_zeros_mask :
predicate_state;
>>>>>>     pointer1 &= predicate_state;
>>>>>>     leak(*pointer1);
>>>>>>   } else {
>>>>>>     int value2 = *pointer2 & predicate_state;
>>>>>>     leak(value2);
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> Let's assume that the branch is mispredicted and if
body is taken. The value predicate_state mask is depend on the "result of
the condition" but which is not yet available hence
>>>>>>
>>>>>> speculative execution. My question whether the value of
predicate_state is also guessed by the processor? If it is correct, then the
value of predicate_state will be
>>>>>> predicate_state, if the processor mis-predicts the
condition as true. Is my assumption is correct? i.e predicate_state = ! 1 ?
all_zeros_mask : predicate_state, where processor predicts
>>>>>> condition as true.
>>>>>>
>>>>>> Or Whether the execution stalls at
"predicate_state = !condition ? all_zeros_mask : predicate_state until the
result of condition became available? If this is true, why we have to
>>>>>>
>>>>>> harden the pointers in the first place, because after
the condition is actually computed, the processors will revert back right the
execution trace of mis-prediction.
>>>>>>
>>>>>> I know that I'm missing something fundamental here,
I would highly appreciate your help on this? Please let me know if you more
info!
>>>>>>
>>>>>> Cheeers,
>>>>>>
>>>>>> Praveen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> --
>>> ~Craig
>>>
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190919/cdd4945b/attachment.html>

llvm dev - Sep 2019 - Spectre V1 Mitigation - Internals?

[llvm-dev] Spectre V1 Mitigation - Internals?

[llvm-dev] Spectre V1 Mitigation - Internals?

[llvm-dev] Spectre V1 Mitigation - Internals?