On 08/02/18 12:26, Marc Zyngier wrote:
On 08/02/18 12:19, Suzuki K Poulose wrote:
On 07/02/18 10:39, Dave Martin wrote:
On Wed, Jan 31, 2018 at 06:28:04PM +0000, Suzuki K Poulose wrote:
We defend against branch predictor training based exploits by
taking specific actions (based on the CPU model) to invalidate
the Branch predictor buffer (BPB). This is implemented by per-CPU
ptr, which installs the specific actions for the CPU model.

The core code can handle the following cases where:
   1) some CPUs doesn't need any work around
   2) a CPU can install the work around, when it is brought up,
      irrespective of how late that happens.

With the recent patches from Marc to expose this information to KVM
guests, it looks like allowing a late CPU to turn this on is not going
to be a good idea. We unconditionally set the capability even
when we don't need the mitigation. So I am not really sure if
we should go ahead with this patch. I am open to suggestions


What do you think ?

By the time we bring in that CPU that requires some level of mitigation,
we may be running a guest already, and we've told that guest that no
mitigation was required. If we bring in that CPU, we break that promise,
and the guest becomes vulnerable without knowing about it.

The same thing is valid for userspace once we expose the status of the
mitigation in /sys, just like x86 does. If we transition from not
vulnerable to vulnerable (or even mitigated), we have lied to userspace.

In either case, I don't think breaking this contract is acceptable.

Thanks Marc, I have dropped this patch from the series.


Reply via email to