| 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
| ||
|
Date: Mon, 20 Feb 2017 20:45:29 +0100
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....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,
Rik van Riel <riel@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Toshimitsu Kani <toshi.kani@....com>,
Arnd Bergmann <arnd@...db.de>,
Jonathan Corbet <corbet@....net>,
Matt Fleming <matt@...eblueprint.co.uk>,
"Michael S. Tsirkin" <mst@...hat.com>,
Joerg Roedel <joro@...tes.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Brijesh Singh <brijesh.singh@....com>,
Ingo Molnar <mingo@...hat.com>,
Alexander Potapenko <glider@...gle.com>,
Andy Lutomirski <luto@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Thomas Gleixner <tglx@...utronix.de>,
Larry Woodman <lwoodman@...hat.com>,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [RFC PATCH v4 10/28] x86: Insure that boot memory areas are
mapped properly
On Thu, Feb 16, 2017 at 09:44:11AM -0600, 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 decrypted mappings so the data is accessed properly when copied.
>
> For the initrd, encrypt this data in place. Since the future mapping of the
> initrd area will be mapped as encrypted the data will be accessed properly.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
> ---
...
> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> index 182a4c7..03f8e74 100644
> --- a/arch/x86/kernel/head64.c
> +++ b/arch/x86/kernel/head64.c
> @@ -46,13 +46,18 @@ static void __init reset_early_page_tables(void)
> write_cr3(__sme_pa_nodebug(early_level4_pgt));
> }
>
> +void __init __early_pgtable_flush(void)
> +{
> + write_cr3(__sme_pa_nodebug(early_level4_pgt));
> +}
Move that to mem_encrypt.c where it is used and make it static. The diff
below, ontop of this patch, seems to build fine here.
Also, aren't those mappings global so that you need to toggle CR4.PGE
for that?
PAGE_KERNEL at least has _PAGE_GLOBAL set.
> +
> /* Create a new PMD entry */
> -int __init early_make_pgtable(unsigned long address)
> +int __init __early_make_pgtable(unsigned long address, pmdval_t pmd)
__early_make_pmd() then, since it creates a PMD entry.
> unsigned long physaddr = address - __PAGE_OFFSET;
> pgdval_t pgd, *pgd_p;
> pudval_t pud, *pud_p;
> - pmdval_t pmd, *pmd_p;
> + pmdval_t *pmd_p;
>
> /* Invalid address or early pgt is done ? */
> if (physaddr >= MAXMEM || read_cr3() != __sme_pa_nodebug(early_level4_pgt))
...
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index ac3565c..ec548e9 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -16,8 +16,12 @@
>
> #include <asm/tlbflush.h>
> #include <asm/fixmap.h>
> +#include <asm/setup.h>
> +#include <asm/bootparam.h>
>
> extern pmdval_t early_pmd_flags;
> +int __init __early_make_pgtable(unsigned long, pmdval_t);
> +void __init __early_pgtable_flush(void);
What's with the forward declarations?
Those should be in some header AFAICT.
> * Since SME related variables are set early in the boot process they must
> @@ -103,6 +107,76 @@ void __init sme_early_decrypt(resource_size_t paddr, unsigned long size)
> __sme_early_enc_dec(paddr, size, false);
> }
...
---
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 03f8e74c7223..c47500d72330 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -46,11 +46,6 @@ static void __init reset_early_page_tables(void)
write_cr3(__sme_pa_nodebug(early_level4_pgt));
}
-void __init __early_pgtable_flush(void)
-{
- write_cr3(__sme_pa_nodebug(early_level4_pgt));
-}
-
/* Create a new PMD entry */
int __init __early_make_pgtable(unsigned long address, pmdval_t pmd)
{
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index ec548e9a76f1..0af020b36232 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -21,7 +21,7 @@
extern pmdval_t early_pmd_flags;
int __init __early_make_pgtable(unsigned long, pmdval_t);
-void __init __early_pgtable_flush(void);
+extern pgd_t early_level4_pgt[PTRS_PER_PGD];
/*
* Since SME related variables are set early in the boot process they must
@@ -34,6 +34,11 @@ EXPORT_SYMBOL_GPL(sme_me_mask);
/* Buffer used for early in-place encryption by BSP, no locking needed */
static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
+static void __init early_pgtable_flush(void)
+{
+ write_cr3(__sme_pa_nodebug(early_level4_pgt));
+}
+
/*
* This routine does not change the underlying encryption setting of the
* page(s) that map this memory. It assumes that eventually the memory is
@@ -158,7 +163,7 @@ void __init sme_unmap_bootdata(char *real_mode_data)
*/
__sme_map_unmap_bootdata(real_mode_data, false);
- __early_pgtable_flush();
+ early_pgtable_flush();
}
void __init sme_map_bootdata(char *real_mode_data)
@@ -174,7 +179,7 @@ void __init sme_map_bootdata(char *real_mode_data)
*/
__sme_map_unmap_bootdata(real_mode_data, true);
- __early_pgtable_flush();
+ early_pgtable_flush();
}
void __init sme_early_init(void)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists