[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190916090058.mteofmkkl37ob47k@box.shutemov.name>
Date: Mon, 16 Sep 2019 12:00:58 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Steve Wahl <steve.wahl@....com>,
Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Juergen Gross <jgross@...e.com>,
Brijesh Singh <brijesh.singh@....com>,
Jordan Borgner <mail@...dan-borgner.de>,
Feng Tang <feng.tang@...el.com>, linux-kernel@...r.kernel.org,
Baoquan He <bhe@...hat.com>, russ.anderson@....com,
dimitri.sivanich@....com, mike.travis@....com
Subject: Re: [PATCH] x86/boot/64: Make level2_kernel_pgt pages invalid
outside kernel area.
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.
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.
> 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.
--
Kirill A. Shutemov
Powered by blists - more mailing lists