[PATCH v6 00/26] KVM/arm64: Randomise EL2 mappings (variant 3a mitigation)

[Marc Zyngier]

On 15/03/18 15:57, Andrew Jones wrote:
> On Wed, Mar 14, 2018 at 04:50:23PM +0000, Marc Zyngier wrote:
>> Whilst KVM benefits from the kernel randomisation via KASLR, there is
>> no additional randomisation when the kernel is running at EL1, as we
>> directly use a fixed offset from the linear mapping. This is not
>> necessarily a problem, but we could do a bit better by independently
>> randomizing the HYP placement.
>>
>> This series proposes to randomise the offset by inserting a few random
>> bits between the MSB of the RAM linear mapping and the top of the HYP
>> VA (VA_BITS - 2). That's not a lot of random bits (on my Mustang, I
>> get 13 bits), but that's better than nothing.
>>
>> In order to achieve this, we need to be able to patch dynamic values
>> in the kernel text. This results in a bunch of changes to the
>> alternative framework, the insn library, and a few more hacks in KVM
>> itself (we get a new way to map the GIC at EL2).
>>
>> Another (and more recent) goal of this series is to work around what
>> has been described as "variant 3a", which covers speculative reads of
>> privileged system registers. Randomizing the location of the
>> hypervisor would be pointless if one could simply obtain VBAR_EL2. In
>> order to work around this, we place the vectors at a fairly static
>> location (next to the idmap), independently of the hypervisor's own
>> mappings. This ensures that we can leak VBAR_EL2 without disclosing
>> much about HYP itself (and is similar to what the rest of the kernel
>> does with KPTI). This is only enabled at runtime for Cortex-A57 and
>> Cortex-A72.
>>
>> This has been tested on the FVP model, Seattle (both 39 and 48bit VA),
>> Mustang and Thunder-X. I've also done a sanity check on 32bit (which
>> is only impacted by the HYP IO VA stuff).
>>
> 
> I've smoke tested this series on a seattle with several busy VMs running
> simultaneously. My host kernel configures 64K pages. I didn't see any
> problems.

Excellent, thanks for testing. Out of curiosity: do you have a firmware
that implements the SMCCC_ARCH_WORKAROUND_1 call or not?

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