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
| ||
|
Message-ID: <57446B27.20406@amd.com> Date: Tue, 24 May 2016 09:54:31 -0500 From: Tom Lendacky <thomas.lendacky@....com> To: Borislav Petkov <bp@...en8.de>, Matt Fleming <matt@...eblueprint.co.uk>, Leif Lindholm <leif.lindholm@...aro.org>, Mark Salter <msalter@...hat.com>, Daniel Kiper <daniel.kiper@...cle.com> CC: <linux-arch@...r.kernel.org>, <linux-efi@...r.kernel.org>, <kvm@...r.kernel.org>, <linux-doc@...r.kernel.org>, <x86@...nel.org>, <linux-kernel@...r.kernel.org>, <kasan-dev@...glegroups.com>, <linux-mm@...ck.org>, <iommu@...ts.linux-foundation.org>, Radim Krčmář <rkrcmar@...hat.com>, Arnd Bergmann <arnd@...db.de>, Jonathan Corbet <corbet@....net>, Joerg Roedel <joro@...tes.org>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Paolo Bonzini <pbonzini@...hat.com>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Andrey Ryabinin <aryabinin@...tuozzo.com>, Alexander Potapenko <glider@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, Dmitry Vyukov <dvyukov@...gle.com> Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear On 05/12/2016 01:20 PM, Tom Lendacky wrote: > On 05/10/2016 08:57 AM, Borislav Petkov wrote: >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >>> Is it not possible to maintain some kind of kernel virtual address >>> mapping so memremap*() and friends can figure out when to twiddle the >>> mapping attributes and map with/without encryption? >> >> I guess we can move the sme_* specific stuff one indirection layer >> below, i.e., in the *memremap() routines so that callers don't have to >> care... That should keep the churn down... >> > > We could do that, but we'll have to generate that list of addresses so > that it can be checked against the range being mapped. Since this is > part of early memmap support searching that list every time might not be > too bad. I'll have to look into that and see what that looks like. I looked into this and this would be a large change also to parse tables and build lists. It occurred to me that this could all be taken care of if the early_memremap calls were changed to early_ioremap calls. Looking in the git log I see that they were originally early_ioremap calls but were changed to early_memremap calls with this commit: commit abc93f8eb6e4 ("efi: Use early_mem*() instead of early_io*()") Looking at the early_memremap code and the early_ioremap code they both call __early_ioremap so I don't see how this change makes any difference (especially since FIXMAP_PAGE_NORMAL and FIXMAP_PAGE_IO are identical in this case). Is it safe to change these back to early_ioremap calls (at least on x86)? Thanks, Tom > > Thanks, > Tom >
Powered by blists - more mailing lists