[MODERATED] Re: LVI

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Tue, Nov 19, 2019 at 06:22:09PM +0000, speck for Andrew Cooper wrote:
> 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.

Good point.

> > 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.

What's the harm of speculating the copy with a bad pointer if we can
confirm there are no gadgets between the copy and the LFENCE?

> 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.

Ah, that would be interesting to know..

-- 
Josh