[MODERATED] Re: [PATCH v2 3/8] MDSv2 5

[Andi Kleen <ak@linux.intel.com>]

On Mon, Dec 10, 2018 at 04:43:56PM -0800, speck for Linus Torvalds wrote:

Ok I will inline it.

FWIW the overhead is currently ~7 cycles on SKL, see [1]



>      It's encryption keys etc. too. But yes.
> 
>    I think the encryption key case could easily have a "let's scrub cpu
>    state" thing.
>    It already does other strange things, like memset_safe() or whatever it is
>    that forces a memset even if the compiler decides it's dead.

But the problem is how do we find all cases where someone else's data
is touched? 

Even if I write a patch for the known to me cases I could
never guarantee I found all.

FWIW I suspect crypto is actually not that big an issue because
most uses should be in own threads, which would be handled 
by the context switch flush. But at least softirqs/timers copying
some user data is a real danger.

> 
>      FWIW from our tests so far the performance loss from the kernel exit
>      overhead
>      doesn't seem to be that bad.
> 
>    I haven't seen any numbers, and whilei can believe it's true for the verw
>    case if there is hw acceleration, I doubt the SW case isn't noticeable.
>    Plus we've already seen that people have been way too eager to apply
>    patches just because there is alleged security implications, without doing
>    any kind of risk vs cost analysis.

My understanding is that while this is much harder to exploit than L1TF or
Meltdown, there are working exploits.

-Andi


[1]


        ffffffff818f5946                        callq  0xffffffff81091960               # PRED 1 cycles [507]
        clear_cpu_buffers_idle:
        ffffffff81091960                        nopl  %eax, (%rax,%rax,1) 
        ffffffff81091965                        movl  0x12a3ab9(%rip), %eax 
        ffffffff8109196b                        test %eax, %eax 
        ffffffff8109196d                        jz 0xffffffff81091970                           # PRED 1 cycles [508] 3.00 IPC
        ffffffff81091970                        pushq  %rbp 
        ffffffff81091971                        mov %rsp, %rbp 
        ffffffff81091974                        callq  0xffffffff81091940               # PRED 1 cycles [509] 2.00 IPC

(it would help if we didn't disable tail calls with debug info I guess ...) 

        clear_cpu_buffers:
        ffffffff81091940                        nopl  %eax, (%rax,%rax,1) 
        ffffffff81091945                        pushq  %rbp 
        ffffffff81091946                        mov %rsp, %rbp 
        ffffffff81091949                        nopl  %eax, (%rax,%rax,1) 
        ffffffff81091951                        data16 nop  
        ffffffff81091953                        popq  %rbp 
        ffffffff81091954                        retq                            # PRED 4 cycles [513] 1.50 IPC
        clear_cpu_buffers_idle+25:
        ffffffff81091979                        popq  %rbp 
        ffffffff8109197a                        retq                            # PRED 1 cycles [514] 1.00 IPC