[RFC PATCH] arm64: use non-global mappings for UEFI runtime regions

Ard Biesheuvel ard.biesheuvel at linaro.org
Tue Nov 17 09:01:38 PST 2015


On 17 November 2015 at 17:34, Will Deacon <will.deacon at arm.com> wrote:
> On Tue, Nov 17, 2015 at 03:25:58PM +0000, Mark Rutland wrote:
>> On Tue, Nov 17, 2015 at 09:53:31AM +0100, Ard Biesheuvel wrote:
>> > As pointed out by Russell King in response to the proposed ARM version
>> > of this code, the sequence to switch between the UEFI runtime mapping
>> > and current's actual userland mapping (and vice versa) is potentially
>> > unsafe, since it leaves a time window between the switch to the new
>> > page tables and the TLB flush where speculative accesses may hit on
>> > stale global TLB entries.
>>
>> Wow, annoying that we missed that.
>>
>> > So instead, use non-global mappings, and perform the switch via the
>> > ordinary ASID-aware context switch routines.
>> >
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>
>> From digging into the way the ASID allocator works, I believe this is
>> correct. FWIW:
>>
>> Reviewed-by: Mark Rutland <mark.rutland at arm.com>
>>
>> For backporting, I'm not sure that this is necessarily safe prior to
>> Will's rework of the ASID allocator. I think we can IPI in this context,
>> and it looks like the cpu_set_reserved_ttbr0() in flush_context() would
>> save us from the problem described above, but I may have missed
>> something.
>>
>> Will, are you aware of anything that could bite us here?
>
> Can we guarantee that efi_virtmap_{load,unload} are called with interrupts
> enabled? Also, the old rollover code seems to rely on current->active_mm
> being the thing to switch to, so an incoming rollover might break things
> if we're running with the efi_mm.
>

OK, but not the current rollover code, right? I.e., if we go with this
approach (after fixing the interupts issue), it will carry over to ARM
as well?



More information about the linux-arm-kernel mailing list