Re: [PATCH] x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area.

[Steve Wahl <steve.wahl@hpe.com>]

On Mon, Sep 16, 2019 at 12:00:58PM +0300, Kirill A. Shutemov wrote:
> On Fri, Sep 13, 2019 at 10:14:15AM -0500, Steve Wahl wrote:
> > On Thu, Sep 12, 2019 at 01:19:17PM +0300, Kirill A. Shutemov wrote:
> > > On Wed, Sep 11, 2019 at 03:08:35PM -0500, Steve Wahl wrote:
> > > > Thank you for your time looking into this with me!
> > > 
> > > With all this explanation the original patch looks sane to me.
> > > 
> > > But I would like to see more information from this thread in the commit
> > > message and some comments in the code on why it's crucial not to map more
> > > than needed.
> > 
> > I am working on this.
> > 
> > > I think we also need to make it clear that this is workaround for a broken
> > > hardware: speculative execution must not trigger a halt.
> > 
> > I think the word broken is a bit loaded here.  According to the UEFI
> > spec (version 2.8, page 167), "Regions that are backed by the physical
> > hardware, but are not supposed to be accessed by the OS, must be
> > returned as EfiReservedMemoryType."  Our interpretation is that
> > includes speculative accesses.
> 
> +Dave.
> 
> I don't think it is. Speculative access is done by hardware, not OS.

But the OS controls speculative access to physical addresses by their
presence or absence in the page tables.  Speculation is done with
calculations based on virtual addresses, without a valid translation
to physical addresses it doesn't progress to an externally visible
action.

> BTW, isn't it a BIOS issue?
> 
> I believe it should have a way to hide a range of physical address space
> from OS or force a caching mode on to exclude it from speculative
> execution. Like setup MTRRs or something.

This is their intent in marking it as reserved in the memory tables.
They have explored many other avenues (I've even suggested a couple
since pinning down this problem) and for each one there is a reason it
doesn't work.

> > I'd lean more toward "tightening of adherence to the spec required by
> > some particular hardware."  Does that work for you?
> 
> Not really, no. I still believe it's issue of the platform, not OS.

My current wording for a comment to go above the code is:

/*
 * Only the region occupied by the kernel has so far been checked against
 * the table of usable memory regions provided by the firmware, so
 * invalidate pages outside that region.  A page table entry that maps to
 * a reserved area of memory would allow processor speculation into that
 * area, and on some hardware (particularly the UV platform) speculation
 * into reserved areas can cause a system halt.
 */

How close does that come to working for you?  (I'm going to dive
specifically into the phrase "region occupied by the kernel" in a
reply to Dave in another message; I understand that phrase may need
work.  I'm more asking about the remainder of it here.)

--> Steve

> -- 
>  Kirill A. Shutemov

-- 
Steve Wahl, Hewlett Packard Enterprise