linux-kernel - Re: [PATCH] Fix left over EFI cache mapping problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080214140816.68b47407@laptopd505.fenrus.org>
Date:	Thu, 14 Feb 2008 14:08:16 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	torvalds@...l.org, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, ying.huang@...el.com
Subject: Re: [PATCH] Fix left over EFI cache mapping problems

On Thu, 14 Feb 2008 22:42:41 +0100
Andi Kleen <andi@...stfloor.org> wrote:

> On Thu, Feb 14, 2008 at 07:38:19PM +0100, Ingo Molnar wrote:
> > 
> > * Andi Kleen <andi@...stfloor.org> wrote:
> > 
> > > > this is indeed a bug (we change the attributes for a larger
> > > > area than needed), but your fix is unclean. Find below a
> > > > cleaner solution.
> > > 
> > > You're still ignoring the other problem of set_memory_uc() not 
> > > handling fixmap and ioremap correctly. [...]
> > 
> > No, we did not ignore it, and yes, you are wrong.
> > 
> > One thing that you miss is that the 64-bit EFI runtime has to be
> > marked uncacheable only if it the EFI image attribute signals an
> > uncacheable area:
> > 
> >                 if (!(md->attribute & EFI_MEMORY_WB))
> >                         set_memory_uc(md->virt_addr, md->num_pages);
> > 
> > and Linux EFI does not support device EFI runtimes. So your
> > observation, 
> 
> Sorry I didn't get that (you were a bit terse). 
> 
> You're saying the EFI BIOSes will never set that flag ?
> 
> I'm reading page 123+ of UEFI 2.1 which describes GetMemoryMap() 
> and these flags and I see nothing to that effect. I admit I didn't
> read the full EFI bible so far so there are certainly EFI
> aspects I don't understand.
> 
> Can you please clarify why EFI would not set that flag on Linux?

because it will only normally get set on EFI code that lives in device memory.
There's no reason to ever use non-cache for ram this way. Ever. Non-cached execution
is a TOTAL pain for anything, and will be avoided if at all possible.

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/