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: <20190415154155.GH29317@zn.tnic> Date: Mon, 15 Apr 2019 17:41:55 +0200 From: Borislav Petkov <bp@...en8.de> To: lijiang <lijiang@...hat.com>, Thomas.Lendacky@....com Cc: linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, tglx@...utronix.de, mingo@...hat.com, akpm@...ux-foundation.org, dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org, x86@...nel.org, hpa@...or.com, dyoung@...hat.com, bhe@...hat.com Subject: Re: [PATCH 1/2 RESEND v10] x86/mm, resource: add a new I/O resource descriptor 'IORES_DESC_RESERVED' On Mon, Apr 15, 2019 at 08:22:22PM +0800, lijiang wrote: > They are different problems. Aha, so we're getting closer. You should've lead with that! > The first problem is that passes the e820 reserved ranges to the second kernel, Passes or *doesn't* pass? Because from all the staring, it wants to pass the reserved ranges. > for this case, it is good enough to use the IORES_DESC_RESERVED, which > can ensure that exactly matches the reserved resource ranges when > walking through iomem resources. Ok. > The second problem is about the SEV case. Now, the IORES_DESC_RESERVED has been > created for the reserved areas, therefore the check needs to be expanded so that > these areas are not mapped encrypted when using ioremap(). > > +static int __ioremap_check_desc_none_and_reserved(struct resource *res) That name is crap. If you need to add another desc type, it becomes wrong again. And that whole code around flags->desc_other is just silly: Make that machinery around it something like this: struct ioremap_desc { u64 flags; }; instead of "struct ioremap_mem_flags" and that struct ioremap_desc is an ioremap descriptor which will carry all kinds of settings. system_ram can then be a simple flag too. __ioremap_caller() will hand it down to __ioremap_check_mem() etc and there it will set flags like IOREMAP_DESC_MAP_ENCRYPTED or IOREMAP_DESC_MAP_DECRYPTED and this way you'll have it explicit and clear in __ioremap_caller(): if ((sev_active() && (io_desc.flags & IOREMAP_DESC_MAP_ENCRYPTED)) || encrypted) prot = pgprot_encrypted(prot); But that would need a pre-patch which does that conversion. > Maybe i should split it into two patches. The change of > __ioremap_check_desc_none_and_reserved() should be a separate patch. > Any idea? See above and yes, definitely separate patches. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists