linux-kernel - Re: [PATCH v2 17/20] arm64: bp hardening: Allow late CPUs to enable work around

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 8 Feb 2018 12:26:35 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Suzuki K Poulose <Suzuki.Poulose@....com>,
        Dave Martin <Dave.Martin@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, mark.rutland@....com,
        ckadabi@...eaurora.org, ard.biesheuvel@...aro.org,
        catalin.marinas@....com, will.deacon@....com,
        linux-kernel@...r.kernel.org, jnair@...iumnetworks.com
Subject: Re: [PATCH v2 17/20] arm64: bp hardening: Allow late CPUs to enable
 work around

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
> 
> Marc,
> 
> 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,

	M.
-- 
Jazz is not dead. It just smells funny...