From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764040AbcIOJ5R (ORCPT ); Thu, 15 Sep 2016 05:57:17 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:35305 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754740AbcIOJ5N (ORCPT ); Thu, 15 Sep 2016 05:57:13 -0400 Date: Thu, 15 Sep 2016 10:57:09 +0100 From: Matt Fleming To: Tom Lendacky Cc: Andy Lutomirski , kasan-dev , "linux-efi@vger.kernel.org" , linux-arch , Thomas Gleixner , Paolo Bonzini , Ingo Molnar , Borislav Petkov , iommu@lists.linux-foundation.org, "linux-doc@vger.kernel.org" , Jonathan Corbet , Radim =?utf-8?B?S3LEjW3DocWZ?= , Konrad Rzeszutek Wilk , "linux-mm@kvack.org" , Alexander Potapenko , "linux-kernel@vger.kernel.org" , Dmitry Vyukov , Arnd Bergmann , Joerg Roedel , Andrey Ryabinin , "H. Peter Anvin" , X86 ML , kvm list , Dave Young Subject: Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear Message-ID: <20160915095709.GB16797@codeblueprint.co.uk> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223738.29880.6909.stgit@tlendack-t1.amdoffice.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote: > On 09/12/2016 11:55 AM, Andy Lutomirski wrote: > > On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote: > >> > >> BOOT data (such as EFI related data) is not encyrpted when the system is > >> booted and needs to be accessed as non-encrypted. Add support to the > >> early_memremap API to identify the type of data being accessed so that > >> the proper encryption attribute can be applied. Currently, two types > >> of data are defined, KERNEL_DATA and BOOT_DATA. > > > > What happens when you memremap boot services data outside of early > > boot? Matt just added code that does this. > > > > IMO this API is not so great. It scatters a specialized consideration > > all over the place. Could early_memremap not look up the PA to figure > > out what to do? > > Yes, I could see if the PA falls outside of the kernel usable area and, > if so, remove the memory encryption attribute from the mapping (for both > early_memremap and memremap). > > Let me look into that, I would prefer something along that line over > this change. So, the last time we talked about using the address to figure out whether to encrypt/decrypt you said, "I looked into this and this would be a large change also to parse tables and build lists." Has something changed that makes this approach easier? And again, you need to be careful with the EFI kexec code paths, since you've got a mixture of boot and kernel data being passed. In particular the EFI memory map is allocated by the firmware on first boot (BOOT_DATA) but by the kernel on kexec (KERNEL_DATA). That's one of the reasons I suggested requiring the caller to decide on BOOT_DATA vs KERNEL_DATA - when you start looking at kexec the distinction isn't easily made.