linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: "Borislav Petkov" <bp@alien8.de>,
	"Leif Lindholm" <leif.lindholm@linaro.org>,
	"Mark Salter" <msalter@redhat.com>,
	"Daniel Kiper" <daniel.kiper@oracle.com>,
	linux-arch@vger.kernel.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>
Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear
Date: Wed, 25 May 2016 20:30:11 +0100	[thread overview]
Message-ID: <20160525193011.GC2984@codeblueprint.co.uk> (raw)
In-Reply-To: <57446B27.20406@amd.com>

On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote:
> 
> 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)?

I really don't want to begin mixing early_ioremap() calls and
early_memremap() calls for any of the EFI code if it can be avoided.

There is slow but steady progress to move more and more of the
architecture specific EFI code out into generic code. Swapping
early_memremap() for early_ioremap() would be a step backwards,
because FIXMAP_PAGE_NORMAL and FIXMAP_PAGE_IO are not identical on
ARM/arm64.

Could you point me at the patch that in this series that fixes up
early_ioremap() to work with mem encrypt/decrypt? I took another
(quick) look through but couldn't find it.

  parent reply	other threads:[~2016-05-25 19:30 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 22:55 [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) Tom Lendacky
2016-03-22 13:00 ` Pavel Machek
2016-04-27 14:05   ` Borislav Petkov
2016-04-27 14:30     ` Pavel Machek
2016-04-27 14:39       ` Borislav Petkov
2016-04-27 14:58         ` Pavel Machek
2016-04-27 15:47         ` Pavel Machek
2016-04-27 14:21   ` Tom Lendacky
2016-04-26 22:56 ` [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors Tom Lendacky
2016-04-27 14:33   ` Andy Lutomirski
2016-04-27 14:44     ` Tom Lendacky
2016-04-27 14:47       ` Andy Lutomirski
2016-04-27 15:05         ` Tom Lendacky
2016-04-27 15:12           ` Andy Lutomirski
2016-04-27 15:31             ` Borislav Petkov
2016-04-27 15:34               ` Andy Lutomirski
2016-04-26 22:56 ` [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement Tom Lendacky
2016-03-22 13:01   ` Pavel Machek
2016-04-27 15:17     ` Tom Lendacky
2016-04-27 15:30       ` Pavel Machek
2016-04-27 15:41         ` Borislav Petkov
2016-04-27 16:41           ` Pavel Machek
2016-04-27 17:07             ` Robin Murphy
2016-04-27 17:12             ` Borislav Petkov
2016-04-26 22:56 ` [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support Tom Lendacky
2016-03-22 13:03   ` Pavel Machek
2016-04-27 16:20     ` Tom Lendacky
2016-04-26 22:56 ` [RFC PATCH v1 04/18] x86: Add the Secure Memory Encryption cpu feature Tom Lendacky
2016-04-26 22:56 ` [RFC PATCH v1 05/18] x86: Handle reduction in physical address size with SME Tom Lendacky
2016-04-26 22:56 ` [RFC PATCH v1 06/18] x86: Provide general kernel support for memory encryption Tom Lendacky
2016-04-26 22:57 ` [RFC PATCH v1 07/18] x86: Extend the early_memmap support with additional attrs Tom Lendacky
2016-04-26 22:57 ` [RFC PATCH v1 08/18] x86: Add support for early encryption/decryption of memory Tom Lendacky
2016-04-26 22:57 ` [RFC PATCH v1 09/18] x86: Insure that memory areas are encrypted when possible Tom Lendacky
2016-04-26 22:57 ` [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear Tom Lendacky
2016-05-10 13:43   ` Matt Fleming
2016-05-10 13:57     ` Borislav Petkov
2016-05-12 18:20       ` Tom Lendacky
2016-05-24 14:54         ` Tom Lendacky
2016-05-25 16:09           ` Daniel Kiper
2016-05-25 19:30           ` Matt Fleming [this message]
2016-05-26 13:45             ` Tom Lendacky
2016-06-08 10:07               ` Matt Fleming
2016-06-09 16:16                 ` Tom Lendacky
2016-06-13 12:03                   ` Matt Fleming
2016-06-13 12:34                     ` Matt Fleming
2016-06-13 15:16                     ` Tom Lendacky
2016-06-08 11:18   ` Matt Fleming
2016-06-09 18:33     ` Tom Lendacky
2016-06-13 13:51       ` Matt Fleming
2016-06-15 13:17         ` Tom Lendacky
2016-06-16 14:38           ` Tom Lendacky
2016-06-17 15:51             ` Matt Fleming
2016-04-26 22:57 ` [RFC PATCH v1 11/18] x86: Decrypt trampoline area if memory encryption is active Tom Lendacky
2016-04-26 22:58 ` [RFC PATCH v1 12/18] x86: Access device tree in the clear Tom Lendacky
2016-04-26 22:58 ` [RFC PATCH v1 13/18] x86: DMA support for memory encryption Tom Lendacky
     [not found]   ` <20160429071743.GC11592@char.us.oracle.com>
2016-04-29 15:12     ` Tom Lendacky
     [not found]       ` <20160429162757.GA1191@char.us.oracle.com>
2016-04-29 23:49         ` Tom Lendacky
2016-04-26 22:58 ` [RFC PATCH v1 14/18] iommu/amd: AMD IOMMU " Tom Lendacky
2016-04-26 22:58 ` [RFC PATCH v1 15/18] x86: Enable memory encryption on the APs Tom Lendacky
2016-05-01 22:10   ` Huang, Kai
2016-05-03 15:59     ` Tom Lendacky
2016-04-26 22:58 ` [RFC PATCH v1 16/18] x86: Do not specify encrypted memory for VGA mapping Tom Lendacky
2016-04-26 22:58 ` [RFC PATCH v1 17/18] x86/kvm: Enable Secure Memory Encryption of nested page tables Tom Lendacky
2016-04-26 22:59 ` [RFC PATCH v1 18/18] x86: Add support to turn on Secure Memory Encryption Tom Lendacky
2016-03-22 13:13   ` Pavel Machek
2016-04-27 14:39 ` [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) Andy Lutomirski
2016-04-27 20:10   ` Tom Lendacky
2016-05-02 18:31     ` Andy Lutomirski
2016-05-09 15:13       ` Paolo Bonzini
2016-05-09 21:08         ` Tom Lendacky
2016-05-10 11:23           ` Paolo Bonzini
2016-05-10 12:04             ` Borislav Petkov
2016-04-30  6:13 ` Elliott, Robert (Persistent Memory)
2016-05-03 15:55   ` Tom Lendacky
  -- strict thread matches above, loose matches on Subject: below --
2016-04-26 22:45 Tom Lendacky
2016-04-26 22:47 ` [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear Tom Lendacky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160525193011.GC2984@codeblueprint.co.uk \
    --to=matt@codeblueprint.co.uk \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel.kiper@oracle.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=msalter@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).