[PATCH] x86/kexec: Only write through identity mapping of control page

[Dave Hansen]

On 12/12/24 13:32, David Woodhouse wrote:
> On 12 December 2024 21:18:10 GMT, Dave Hansen <dave.hansen at intel.com> wrote:
>> On 12/12/24 12:11, David Woodhouse wrote:
>>> From: David Woodhouse <dwmw at amazon.co.uk>
>>>
>>> The virtual mapping of the control page may have been _PAGE_GLOBAL and
>>> thus its PTE might not have been flushed on the %cr3 switch and
>>> it might effectively still be read-only. Move the writes to it
>>> down into the identity_mapped() function where the same
>>> %rip-relative addressing will get the new mapping.
>>> 
>>> The stack is fine, as that's using the identity mapped address
>>> anyway.
>> 
>> Shouldn't we also ensure that Global entries don't bite anyone
>> else? Something like the completely untested attached patch?
> Doesn't hurt, but this is an identity mapping so absolutely
> everything other than this one page is going to be in the low
> (positive) part of the canonical address space, so won't have had
> global pages in the first place will they?

Right, it's generally _not_ a problem. But it _can_ be a surprising
problem which is why we're all looking at it today. ;)

> Probably a kind thing to do for whatever we're passing control to
> though :)
> 
> I'll round it up into the tree and send it out with the next batch of
> debug support. Care to give me a SoB for it? You can
> s/CR0_PGE/CR4_PGE/ too if you like but I can do that myself as well.
Here's a fixed one with a changelog and a SoB. Still 100% gloriously
untested though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-mm-Ensure-Global-mappings-are-zapped-during-kexe.patch
Type: text/x-patch
Size: 1472 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20241212/e1b40581/attachment-0001.bin>