Re: [PATCH 0/3] Add __builtin_load_no_speculate

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

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 23, 3
> 	.eabi_attribute 24, 1
> 	.eabi_attribute 25, 1
> 	.eabi_attribute 26, 2
> 	.eabi_attribute 30, 4
> 	.eabi_attribute 34, 1
> 	.eabi_attribute 18, 4
> 	.section	.text.startup,"ax",%progbits
> 	.align	2
> 	.global	despec_i
> 	.syntax unified
> 	.arm
> 	.fpu vfpv3-d16
> 
> despec_i:
> 	cmp r0,#0
> 	beq L0
> 	ldr r0,[r1]
> 	moveq r0,r2
> 	nop {0x14} @ CSDB
> 	str r0,[r1]
> 	mov r0,#1
> 	bx lr
> L0:	mov r0,#0
> 	bx lr
> 
> cat test.c
> extern int despec_i(int predicate, int *untrusted, int fallback);
> #define N 8
> int a[N] = {1,2,3,4,5,7,8,9};
> int a2[0x200];
> int test(int untrust)
> {
>    int x = 0;
>    if (despec_i(untrust >= 0 && untrust < N, &untrust, 0))
>    {
>       int v = a[untrust] & 0x1 ? 0x100 : 0x0;
>       x = a2[v];
>    }
>    return x;
> }
> 
> 
> So this should feed the predicate through the builtin, and
> clear the untrusted value when the condition has been been
> mis-predicted.
> 
> Wouldn't that be more flexible to use?
> Or am I missing something?

Yes, if you modified your test case to be something like:


int test(int untrust)
{
   int x = 0;

   if (untrust < 0)
     return x;

   if (despec_i(untrust >= 0 && untrust < N, &untrust, 0))
   {
      int v = a[untrust] & 0x1 ? 0x100 : 0x0;
      x = a2[v];
   }
   return x;
}

then the compiler can (and will) optimize the condition to

  if (despec (true && untrust < N, &untrust, 0))

and suddenly you don't have the protection against speculative execution
that you thought you had.  That makes the API exceedingly dangerous as
we can't easily detect and inhibit all the sources of information that
the compiler might use to make such deductions.  What happens, for
example if your original case is inlined into a wider function that has
additional tests?

R.


> 
> 
> As a side note: I noticed that "nop {0x14}" seems to produce the correct
> assembler opcode without the need for using a .insn code.
> 
> 
> Bernd.
>