[MODERATED] Re: LVI

On 19/11/2019 17:40, speck for Josh Poimboeuf wrote:
> Hi,
>
> What kernel changes (if any) are needed for LVI?  I haven't seen any
> discussion here.
>
> The last I heard, the official CRD was Dec 10, but was likely to move to
> March.
>
> For the uninitiated, LVI is a reverse MDS/L1TF:
>
> 1) Victim puts secret data in CPU buffer or L1.  Alternatively,
>    attacker puts address of secret data in CPU buffer or L1.
>
> 2) Attacker gets victim to fault or assist on a load.  (Note that an
>    assist gives a much bigger speculation window - it can be triggered
>    if a page Accessed bit needs updating)
>
> 3) While waiting for the fault/assist to complete, victim speculatively
>    reads CPU buffer or L1 to get data (or address) from step 1.
>
> 4) Victim gadgets expose the data via the usual L1 side channel.

I'd phrase this slightly differently, e.g. "Attacker puts something
deliberate in a CPU buffer or L1".

It doesn't have to be a secret, or an address of a secret.  In the case
of ret hijacking, it is just the address of a disclosure gadget to
speculate to.

The important point of LVI is that a victim load ends up speculatively
using an attacker-chosen value.

> To protect the kernel, we'd presumably need to look for places where
> users can trigger a faulting/assisting load.  For example,
> copy_from_user().
>
> copy_from_user() has an LFENCE between the access_ok() check and the
> actual copy to protect against Spectre v1.  What if we move that LFENCE
> to *after* the copy?  I think that would protect against both Spectre v1
> and LVI.
>
> Thoughts?

The lfence before protects from speculating into copy_from_user() with a
bad pointer.  This protection is still necessary.

An lfence afterwards would be necessary to prevent (speculatively)
returning to calling context with bad data.

On current Intel parts, stac/clac have lfence semantics, but I don't
recall if this is intended to be relied upon in future parts.

~Andrew