On 20/11/2019 08:04, speck for Peter Zijlstra wrote:
> On Tue, Nov 19, 2019 at 11:40:08AM -0600, speck for Josh Poimboeuf wrote:
>> Hi,
>>
>> What kernel changes (if any) are needed for LVI?  I haven't seen any
>> discussion here.
> How about you start by explaining what LVI is, because some of us don't
> have a clue. I'm guessing it doesn't stand for Low Voltage Interface.

Load Value Injection.

(This is all from memory, because the DRM service appears to be offline,
and stopping me reading the appropriate PPDF on the matter.)

LVI is MDS, but with a different take who does what.

For MDS, you (the attacker) sample data by arranging for one of your own
loads to take a fault/assist, and leak the speculatively forwarded data.

For LVI, you (the attacker) arrange for a victim load to take a
fault/assist, and forward a piece of attacker chosen data from one of
the leaky microarchitectural buffers, into the otherwise correct
speculation within the victim context.

From the victims point of view, any load may end up speculating with a
maliciously chosen value.

SGX is, once again, the main target for the researchers on this one,
owing to the fact that the kernel (attacker) has complete control of the
pagetables and can arrange for an A/D bit to be set during a specific
victim load.

The current SGX recommendation for keeping your secrets secret is an
lfence between every instruction with a memory operand, including ones
which implicitly load from the stack (i.e. ret).  (Yes - you did read
this right.)


From a kernel perspective, things look rather better because the
attacker isn't in the position of having direct pagetable control. 
However, at the moment, it is still a very open ended question of "which
loads may end up taking a fault/assist to an attackers advantage".

~Andrew