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