[Xen-devel] Design session report: Further defences for speculative sidechannels

[Xen-devel] Design session report: Further defences for speculative sidechannels

[Andrew Cooper]

Some numpty (me) forgot to organise a scribe for the session, so these
notes are from memory.  As a result, all aspects are up for argumen^W
debate.

We started by discussing Core-aware scheduling, and covering the point
that while in principle it makes an attackers life easier, it doesn't
make a difference in practice.  A determined attacker won't be put off
by the extra stats required to determine co-residency, and there are
plenty of research papers published with various techniques in this area.

We also discussed synchronised scheduling.  Part of this was an
explanation of why it is believed to be safe alternative to disabling
HT.  Part was a discussion of the performance aspects and why the perf
hit is substantially worse when virtualised than on native, due to a
lack of virtualised IPI support on affected hardware.

Some discussion went on MSR_ARCH_CAPS virtualisation support, and
support for eIBRS.  This work is already on a TODO list, and no concerns
were raised.

The area which took up a large part of the discussion was the current
state of "l1tf_barrier".  In current staging, we are compiling code
which takes all of the performance hit, and gains none of the safety.

This is because we fought the optimiser, and the optimiser won.

The use of inline assembly is causing the optimiser to out-of-line the
protected predicates, which causes the LFENCE to be emitted in the
instruction stream *before* the Jcc trying to be protected, which
renders the protections useless.

Annotating all predicates with always_inline is believed to resolve the
issue, but this is almost impossible to spot during review, as all it
takes is one intermediate non-always_inline predicate to break the
security all over again.

An alternative to the current approach was raised, which involves using
a compiler extension.  Linux has used compiler extensions for several
releases now, and forms the basis of several KSPP features/mitigations.

It is expected that we would be able to express the required protections
 using a compiler plugin rather than with inline assembly, which
provides a much cleaner argument concerning correctness, and makes it
less likely that errors will occur due to fighting with the optimiser.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel