Re: [RFC PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active

On Thu, Mar 02, 2017 at 10:13:21AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as > EFI related data, setup data) is encrypted and needs to be accessed as > such when mapped. Update the

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order for memory pages to be properly mapped when SEV is active, we > need to use the PAGE_KERNEL protection attribute as the base protection. > This will insure that memory

Re: [RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address

On Tue, Feb 28, 2017 at 04:34:39PM -0600, Tom Lendacky wrote: > Or if we want to guard against ACPI adding a type 0 in the future, I > could make the function return an int and then return -EINVAL if an e820 > entry isn't found. This might be the better option. Yap, think so too. I don't trust

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote: > Yes, it looks better. I can repost with this change. Thanks. No it doesn't: #define EFI_VA_START ( -4 * (_AC(1, UL) << 30)) #define EFI_VA_END (-68 * (_AC(1, UL) << 30)) That's -4G (the shift by 30) and -68G, respectively.

Re: [RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data

On Thu, Mar 02, 2017 at 10:13:53AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order to map BOOT data with the proper encryption bit, the Btw, what does that all-caps spelling "BOOT" denote? Something I'm missing? > early_ioremap() function calls are

Re: [PATCH v5 01/32] x86: Documentation for AMD Secure Memory Encryption (SME)

bit can be specified > +in the cr3 register, allowing the PGD table to be encrypted. Each successive I missed that the last time: do you mean here, "The encryption bit can be specified in the %cr3 register allowing for the page table hierarchy itself to be encrypted."? > +lev

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote: > I guess it's not really needed. It just may be useful considering there can > be numerous error info structures, numerous context info structures, and a > variable length vendor information section. I can move this print to only in >

Re: [RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active

On Mon, Jul 24, 2017 at 02:07:48PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky

Re: [RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

On Mon, Jul 24, 2017 at 02:07:51PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order for memory pages to be properly mapped when SEV is active, we > need to use the PAGE_KERNEL protection attribute as the base protection. > This will insure that memory

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote: > > If I make the scattered feature support conditional on CONFIG_X86_64 > > (based on comment below) then cpu_has() will always be false unless > > CONFIG_X86_64 is enabled. So this won't need to be wrapped by the > > #ifdef. > > If

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 09:58:54AM -0500, Tom Lendacky wrote: > True, but it is more about being accurate and making sure the value is > correct where ever it may be used. So early_identify_cpu() initializes phys_bits to 32 on 32-bit. Subtracting it there would actually make actively it wrong,

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 10:29:40AM -0500, Tom Lendacky wrote: > But early_identify_cpu() calls get_cpu_cap() which will check for cpuid > leaf 0x8008 support and set x86_phys_bits. Right, but it can't be less than 32, can it? And if it is more than 32 bits, then it probably doesn't really

Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

On Mon, Jul 24, 2017 at 02:07:41PM -0500, Brijesh Singh wrote: Subject: Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption ^^

Re: [RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

On Mon, Jul 24, 2017 at 02:07:46PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When Secure Encrypted Virtualization (SEV) is active, boot data (such as > EFI related data, setup data) is encrypted and needs to be accessed as > such when mapped. Update the

Re: [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

On Wed, Jul 26, 2017 at 11:47:32AM -0500, Tom Lendacky wrote: > If it's made static then the sme_active()/sev_active() inline functions > would need to be turned into functions within the mem_encrypt.c file. So > there's a trade-off to do that, which is the better one? Simple: why do we have

Re: [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The current code checks only for sme_active() when determining whether > to perform the encryption attribute change. Include sev_active() in this > check so that memory attribute

Re: [RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area under SEV

Subject: x86/realmode: ... On Mon, Jul 24, 2017 at 02:07:45PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When SEV is active the trampoline area will need to be in encrypted > memory so only mark the area decrypted if SME is active. > > Signed-off-by: Tom

Re: [RFC Part1 PATCH v3 04/17] x86/mm: Don't attempt to encrypt initrd under SEV

On Mon, Jul 24, 2017 at 02:07:44PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When SEV is active the initrd/initramfs will already have already been > placed in memory encyrpted so do not try to encrypt it. > > Signed-off-by: Tom Lendacky

Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

On Fri, Apr 21, 2017 at 11:22:31PM +0200, Rafael J. Wysocki wrote: > > #ifdef CONFIG_ACPI_APEI_PCIEAER > > - else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type, > > - CPER_SEC_PCIE)) { > > + else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {

Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

On Thu, Apr 27, 2017 at 04:09:56PM +0300, Andy Shevchenko wrote: > Lukas pointed to this: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68725 Yap, the same thing. Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG

Re: [PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

On Tue, Apr 18, 2017 at 04:17:27PM -0500, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On Tue, Apr 18, 2017 at 04:17:54PM -0500, Tom Lendacky wrote: > Changes to the existing page table macros will allow the SME support to > be enabled in a simple fashion with minimal changes to files that use these > macros. Since the memory encryption mask will now be part of the regular >

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On Tue, Apr 25, 2017 at 11:41:39AM -0600, Baicar, Tyler wrote: > I originally had this as a notifier, but Will requested to remove the > notifier. That conversation is here: https://lkml.org/lkml/2017/1/18/1018 Yeah, he mentioned on IRC. I just think notifiers would be the cleaner thing but

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote: > That seems like something that should be done outside of these patches (if > added to the kernel at all). The decoding for this information would all be > vendor specific, so I'm not sure if we want to pollute the EFI code with >

Re: [PATCH V15 07/11] acpi: apei: panic OS with fatal error status block

On Tue, Apr 18, 2017 at 05:05:19PM -0600, Tyler Baicar wrote: > From: "Jonathan (Zhixiong) Zhang" > > Even if an error status block's severity is fatal, the kernel does not > honor the severity level and panic. > > With the firmware first model, the platform could inform

Re: [RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() > functions each have much of the same code. Create a new function that > consolidates the common code

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

On Wed, Jul 26, 2017 at 03:07:14PM -0500, Brijesh Singh wrote: > Are you commenting on amount of code duplication ? If so, I can certainly > improve > and use the similar macro used into header file to generate the functions > body. So the argument about having CONFIG_AMD_MEM_ENCRYPT disabled

Re: [PATCH] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec and efi=old_map

; be used only for debug purposes. > > Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Ricardo Neri <ricardo.n...@intel.com> > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Ard Biesheuv

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted because UEFI/BIOS does not run with SME active. In order to access > this data properly it needs to be mapped decrypted. > > The early_memremap()

Re: [PATCH v5 14/32] efi: Add an EFI table address match function

On Tue, Apr 18, 2017 at 04:18:48PM -0500, Tom Lendacky wrote: > Add a function that will determine if a supplied physical address matches > the address of an EFI table. > > Signed-off-by: Tom Lendacky > --- > drivers/firmware/efi/efi.c | 33

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On Tue, Apr 18, 2017 at 04:21:21PM -0500, Tom Lendacky wrote: > Provide support so that kexec can be used to boot a kernel when SME is > enabled. > > Support is needed to allocate pages for kexec without encryption. This > is needed in order to be able to reboot in the kernel in the same manner

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote: > I was worried what the compiler might do when CONFIG_EFI is not set, > but it appears to take care of it. I'll double check though. There's a efi_enabled() !CONFIG_EFI version too, so should be fine. > I may introduce a length

Re: [PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

On Wed, May 17, 2017 at 03:26:58PM -0500, Tom Lendacky wrote: > > Also, simplify that test: > > > > if (mpf->feature1) > > ... > > Ok, I can do that but I hope no one says anything about it being > unrelated to the patch. :) Bah, that's minor. -- Regards/Gruss, Boris.

Re: [PATCH V16 09/11] ras: acpi / apei: generate trace event for unrecognized CPER section

On Mon, May 15, 2017 at 03:27:58PM -0600, Tyler Baicar wrote: > The UEFI spec includes non-standard section type support in the > Common Platform Error Record. This is defined in section N.2.3 of > UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match any > section type

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match with > one of the section types that

Re: [PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

On Tue, May 16, 2017 at 02:28:42PM -0500, Tom Lendacky wrote: > It's most problematic when CONFIG_AMD_MEM_ENCRYPT is not defined since > we never include an asm/ version from the linux/ path. I could create > a mem_encrypt.h in include/asm-generic/ that contains the info that > is in the

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On Tue, May 16, 2017 at 10:44:43AM -0600, Baicar, Tyler wrote: > I meant to respond to this comment after I sent the v16 patch series, but > you beat me to it :) > > These prefixes are common to all the GHES/CPER printing to the kernel logs. I don't mean that - I meant to remove them from this

Re: [PATCH v5 26/32] x86, drm, fbdev: Do not specify encrypted memory for video mappings

On Tue, Apr 18, 2017 at 04:20:56PM -0500, Tom Lendacky wrote: > Since video memory needs to be accessed decrypted, be sure that the > memory encryption mask is not set for the video ranges. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/vga.h | 13

Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote: > Persistent memory is expected to persist across reboots. The encryption > key used by SME will change across reboots which will result in corrupted > persistent memory. Persistent memory is handed out by block devices > through

Re: [PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

On Tue, Apr 18, 2017 at 04:20:19PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

On Tue, Apr 18, 2017 at 04:19:30PM -0500, Tom Lendacky wrote: > The SMP MP-table is built by UEFI and placed in memory in a decrypted > state. These tables are accessed using a mix of early_memremap(), > early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses > to use

Re: [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

sfs.c |5 +++-- > drivers/firmware/pcdp.c |4 ++-- > drivers/sfi/sfi_core.c | 22 +++--- > 9 files changed, 55 insertions(+), 66 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoi

Re: [PATCH v7 20/36] x86, mpparse: Use memremap to map the mpf and mpc data

t; arch/x86/kernel/mpparse.c | 98 > - > 1 file changed, 70 insertions(+), 28 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> Please put the conversion to pr_fmt() on the TODO list for later. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-po

Re: [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

On Wed, Jun 21, 2017 at 09:18:59AM +0200, Thomas Gleixner wrote: > That looks wrong. It's not decrypted it's rather unencrypted, right? Yeah, it previous versions of the patchset, "decrypted" and "unencrypted" were both present so we settled on "decrypted" for the nomenclature. --

Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

++- > arch/x86/include/asm/processor.h |5 + > 2 files changed, 7 insertions(+), 1 deletion(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

__init sme_encrypt_kernel(void) > +{ > +} Just the minor: void __init sme_encrypt_kernel(void) { } in case you have to respin. Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubsc

Re: [PATCH v7 23/36] x86, realmode: Decrypt trampoline area if memory encryption is active

addresses > with the memory encryption mask. > > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/realmode/init.c |8 > 1 file changed, 8 insertions(+) Subject: x86/realmode: ... other than that: Reviewed-by: Borislav Petkov <b...@suse.de> --

Re: [PATCH v7 24/36] x86, swiotlb: Add memory encryption support

++ > lib/swiotlb.c | 54 > +++- > 9 files changed, 108 insertions(+), 17 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- T

Re: [PATCH v7 25/36] swiotlb: Add warnings for use of bounce buffers with SME

On Fri, Jun 16, 2017 at 01:54:36PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [PATCH v7 36/36] x86/mm: Add support to make use of Secure Memory Encryption

On Fri, Jun 16, 2017 at 01:56:39PM -0500, Tom Lendacky wrote: > Add support to check if SME has been enabled and if memory encryption > should be activated (checking of command line option based on the > configuration of the default state). If memory encryption is to be > activated, then the

Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote: > Normally the __p4d() macro would be used and that would be ok whether > CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the > paravirt ops path I have to use native_make_p4d(). So __p4d is in !CONFIG_PARAVIRT path.

Re: [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly

On Fri, Jun 16, 2017 at 01:52:32PM -0500, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Thu, Jun 15, 2017 at 11:33:41AM -0500, Tom Lendacky wrote: > Changing the signature back reverts to the original way, so this can be > looked at separate from this patchset then. Right, the patch which added the volatile thing was this one: 4bf5beef578e ("iommu/amd: Don't put

Re: [PATCH v7 32/36] xen/x86: Remove SME feature in PV guests

static void __init xen_init_capabilities(void) > setup_clear_cpu_cap(X86_FEATURE_MTRR); > setup_clear_cpu_cap(X86_FEATURE_ACC); > setup_clear_cpu_cap(X86_FEATURE_X2APIC); > + setup_clear_cpu_cap(X86_FEATURE_SME); > > if (!xen_initial_domain()) >

Re: [PATCH v7 33/36] x86/mm: Use proper encryption attributes with /dev/mem

> arch/x86/include/asm/io.h |3 +++ > arch/x86/mm/ioremap.c | 18 +- > arch/x86/mm/pat.c |3 +++ > 3 files changed, 15 insertions(+), 9 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practic

Re: [PATCH v7 31/36] x86/mm, kexec: Allow kexec to be used with SME

int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp) { return 0; } static inline void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages) { } Other than that: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices fo

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote: > Add support to check if SME has been enabled and if memory encryption > should be activated (checking of command line option based on the > configuration of the default state). If memory encryption is to be > activated, then the

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote: > On 4/18/2017 4:22 PM, Tom Lendacky wrote: > > Add support to check if SME has been enabled and if memory encryption > > should be activated (checking of command line option based on the > > configuration of the default state). If

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote: > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > determine if SME is active. But why do user-space tools need to know that? I mean, when we load the kdump kernel, we do it with the first kernel, with the

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Tue, Apr 18, 2017 at 04:21:49PM -0500, Tom Lendacky wrote: > Add the support to encrypt the kernel in-place. This is done by creating > new page mappings for the kernel - a decrypted write-protected mapping > and an encrypted mapping. The kernel is encrypted by copying it through > a temporary

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote: > I guess I could do that, but this will probably only end up clearing a > single PGD entry anyway since it's highly doubtful the address range > would cross a 512GB boundary. Or you can compute how many 512G-covering, i.e., PGD

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote: > In addition to the same issue as efi.memmap.phys_map, efi_phys has > the __initdata attribute so it will be released/freed which will cause > problems in checks performed afterwards. Sounds to me like we should drop the __initdata

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote: > The "worker" function would be doing the loop through the setup data, > but since the setup data is mapped inside the loop I can't do the __init > calling the non-init function and still hope to consolidate the code. > Maybe I'm

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On Fri, May 19, 2017 at 03:45:28PM -0500, Tom Lendacky wrote: > Actually there is. The above will result in data in the cache because > halt() turns into a function call if CONFIG_PARAVIRT is defined (refer > to the comment above where do_wbinvd_halt is set to true). I could make > this a

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On Fri, May 19, 2017 at 04:07:24PM -0500, Tom Lendacky wrote: > As long as those never change from static inline everything will be > fine. I can change it, but I really like how it explicitly indicates I know what you want to do. But you're practically defining a helper which contains two

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Fri, May 19, 2017 at 03:16:51PM -0500, Josh Poimboeuf wrote: > I'm the stack validation guy, not the stack protection guy :-) LOL. I thought you were *the* stacks guy. :-))) But once you've validated it, you could protect it then too. :-) -- Regards/Gruss, Boris. Good mailing practices

Re: [PATCH V17 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

the error. ... > V17:Rebase on tip > Change trace event helper function names > Remove unneeded prefixes from commit text The whole series: Reviewed-by: Borislav Petkov <b...@suse.de> Thanks! -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -

Re: [PATCH V16 10/11] trace, ras: add ARM processor error trace event

On Mon, May 15, 2017 at 03:27:59PM -0600, Tyler Baicar wrote: > Currently there are trace events for the various RAS > errors with the exception of ARM processor type errors. > Add a new trace event for such errors so that the user > will know when they occur. These trace events are > consistent

Re: [PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

On Tue, Apr 18, 2017 at 04:20:10PM -0500, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Tue, May 30, 2017 at 11:39:07AM -0500, Tom Lendacky wrote: > Yes, it's from objtool: > > arch/x86/mm/mem_encrypt_boot.o: warning: objtool: .text+0xd2: return > instruction outside of a callable function Oh, well, let's make it a global symbol then. Who knows, we might have to live-patch it

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On Tue, May 30, 2017 at 12:46:14PM -0500, Tom Lendacky wrote: > This is an area that I'm not familiar with, so I don't completely > understand the flow in regards to where/when/how the ELF headers are > copied and what needs to be done. So my suggestion is still to put kexec/kdump on the

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Tue, May 30, 2017 at 10:37:03AM -0500, Tom Lendacky wrote: > I can define the command line option and the "on" and "off" values as > character buffers in the function and initialize them on a per character > basis (using a static string causes the same issues as referencing a > string

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote: > In this case we're running identity mapped and the "on" constant ends up > as kernel address (0x81...) which results in a segfault. Would static const char *__on_str = "on"; ... if (!strncmp(buffer,

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Tue, May 30, 2017 at 11:46:52AM -0500, Tom Lendacky wrote: > Check if you have CONFIG_DEBUG_SECTION_MISMATCH=y $ grep MISM .config CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_SECTION_MISMATCH_WARN_ONLY=y Still no joy. Can you give me your .config? -- Regards/Gruss, Boris. Good mailing

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Wed, Jun 14, 2017 at 03:40:28PM -0500, Tom Lendacky wrote: > I was trying to keep all the logic for it here in the SME related files > rather than put it in the iommu code itself. But it is easy enough to > move if you think it's worth it. Yes please - the less needlessly global symbols, the

Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

On Wed, Jun 14, 2017 at 02:49:02PM -0500, Tom Lendacky wrote: > I guess I don't need the sme_active() check since the second part of the > if statement can only ever be true if SME is active (since mask is > unsigned). ... and you can define sme_me_mask as an u64 directly (it is that already,

Re: [PATCH v6 29/34] kvm: x86: svm: Support Secure Memory Encryption within KVM

mu.h |2 +- > arch/x86/kvm/svm.c | 35 ++- > arch/x86/kvm/vmx.c |3 ++- > arch/x86/kvm/x86.c |3 ++- > 6 files changed, 32 insertions(+), 25 deletions(-) Patches 27-29: Reviewed-by: Borislav

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Thu, Jun 15, 2017 at 09:59:45AM -0500, Tom Lendacky wrote: > Actually the detection routine, amd_iommu_detect(), is part of the > IOMMU_INIT_FINISH macro support which is called early through mm_init() > from start_kernel() and that routine is called before init_amd(). Ah, we do that there

Re: [PATCH v6 13/34] x86/mm: Add support for early encrypt/decrypt of memory

> --- > arch/x86/include/asm/mem_encrypt.h | 15 +++ > arch/x86/mm/mem_encrypt.c | 76 > > 2 files changed, 91 insertions(+) Patches 11-13: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good ma

Re: [PATCH v6 14/34] x86/mm: Insure that boot memory areas are mapped properly

On Wed, Jun 07, 2017 at 02:15:39PM -0500, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add

Re: [PATCH v6 09/34] x86/mm: Simplify p[gum]d_page() macros

s.lenda...@amd.com> > --- > arch/x86/include/asm/pgtable.h | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) For patches 7-9: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and tr

Re: [PATCH v6 04/34] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

c | 13 + > arch/x86/kernel/cpu/scattered.c|1 + > 4 files changed, 17 insertions(+) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe f

Re: [PATCH v6 05/34] x86/CPU/AMD: Handle SME reduction in physical address size

; --- > arch/x86/kernel/cpu/amd.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list:

Re: [PATCH v6 06/34] x86/mm: Add Secure Memory Encryption (SME) support

nclude/asm/mem_encrypt.h > create mode 100644 arch/x86/mm/mem_encrypt.c > create mode 100644 include/asm-generic/mem_encrypt.h > create mode 100644 include/linux/mem_encrypt.h Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for

Re: [PATCH v6 20/34] x86, mpparse: Use memremap to map the mpf and mpc data

On Wed, Jun 07, 2017 at 02:16:43PM -0500, Tom Lendacky wrote: > The SMP MP-table is built by UEFI and placed in memory in a decrypted > state. These tables are accessed using a mix of early_memremap(), > early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses > to use

Re: [PATCH v6 23/34] x86, realmode: Decrypt trampoline area if memory encryption is active

On Wed, Jun 07, 2017 at 02:17:09PM -0500, Tom Lendacky wrote: > When Secure Memory Encryption is enabled, the trampoline area must not > be encrypted. A CPU running in real mode will not be able to decrypt > memory that has been encrypted because it will not be able to use addresses > with the

Re: [PATCH v6 22/34] x86/mm: Add support for changing the memory encryption attribute

> 2 files changed, 65 insertions(+) Patches 21-22: Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsu

Re: [PATCH v6 23/34] x86, realmode: Decrypt trampoline area if memory encryption is active

On Wed, Jun 14, 2017 at 06:24:16PM +0200, Borislav Petkov wrote: > On Wed, Jun 07, 2017 at 02:17:09PM -0500, Tom Lendacky wrote: > > When Secure Memory Encryption is enabled, the trampoline area must not > > be encrypted. A CPU running in real mode will not be able to decrypt >

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Wed, Jun 07, 2017 at 02:17:45PM -0500, Tom Lendacky wrote: > The IOMMU is programmed with physical addresses for the various tables > and buffers that are used to communicate between the device and the > driver. When the driver allocates this memory it is encrypted. In order > for the IOMMU to

Re: [PATCH v6 24/34] x86, swiotlb: Add memory encryption support

On Wed, Jun 07, 2017 at 02:17:21PM -0500, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

On Wed, Jun 07, 2017 at 02:17:32PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [PATCH v6 20/34] x86, mpparse: Use memremap to map the mpf and mpc data

On Wed, Jun 14, 2017 at 12:06:54PM -0500, Tom Lendacky wrote: > This isn't new... there are a number of messages issued in this file > with that prefix, so I was just following convention. The "convention" that some of the messages are prefixed and some aren't? :-) > Changing the prefix could

Re: [PATCH v5 15/32] efi: Update efi_mem_type() to return an error rather than 0

On Tue, Apr 18, 2017 at 04:19:00PM -0500, Tom Lendacky wrote: > The efi_mem_type() function currently returns a 0, which maps to > EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for > the supplied physical address. Returning EFI_RESERVED_TYPE implies that > a memmap entry

Re: [PATCH V15 08/11] efi: print unrecognized CPER section

On Tue, Apr 18, 2017 at 05:05:20PM -0600, Tyler Baicar wrote: > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match with > one of the section types that

Re: [PATCH v5 13/32] x86/boot/e820: Add support to determine the E820 type of an address

On Tue, Apr 18, 2017 at 04:18:31PM -0500, Tom Lendacky wrote: > Add a function that will return the E820 type associated with an address > range. ... > @@ -110,9 +111,28 @@ bool __init e820__mapped_all(u64 start, u64 end, enum > e820_type type) >* coverage of the desired range

Re: [PATCH V15 09/11] ras: acpi / apei: generate trace event for unrecognized CPER section

On Tue, Apr 18, 2017 at 05:05:21PM -0600, Tyler Baicar wrote: > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. If the spec calls it non-standard why are we calling it "unknown section"? > Currently if the CPER

Re: [PATCH V15 11/11] arm/arm64: KVM: add guest SEA support

On Tue, Apr 18, 2017 at 05:05:23PM -0600, Tyler Baicar wrote: > Currently external aborts are unsupported by the guest abort > handling. Add handling for SEAs so that the host kernel reports > SEAs which occur in the guest kernel. > > When an SEA occurs in the guest kernel, the guest exits and is

Re: [PATCH V15 10/11] trace, ras: add ARM processor error trace event

On Tue, Apr 18, 2017 at 05:05:22PM -0600, Tyler Baicar wrote: > Currently there are trace events for the various RAS > errors with the exception of ARM processor type errors. > Add a new trace event for such errors so that the user > will know when they occur. These trace events are > consistent

<    1   2   3   4   5   >