linux-kernel - Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUk2kRSzKfwhio6KV3iuYaSV2uxybd-e95kK3vY=yTSfg@mail.gmail.com>
Date:   Mon, 12 Sep 2016 09:55:09 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Tom Lendacky <thomas.lendacky@....com>,
        Matt Fleming <mfleming@...e.de>
Cc:     kasan-dev <kasan-dev@...glegroups.com>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        iommu@...ts.linux-foundation.org,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Alexander Potapenko <glider@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Arnd Bergmann <arnd@...db.de>, Joerg Roedel <joro@...tes.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        kvm list <kvm@...r.kernel.org>
Subject: Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

On Aug 22, 2016 6:53 PM, "Tom Lendacky" <thomas.lendacky@....com> 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?

--Andy

[leaving the rest here for Matt's benefit]

>                      unsigned long size,
> +                                                   enum memremap_owner owner,
> +                                                   pgprot_t prot)
> +{
> +       return prot;
> +}
> +
>  void __init early_ioremap_reset(void)
>  {
>         early_ioremap_shutdown();
> @@ -213,16 +221,23 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
>
>  /* Remap memory */
>  void __init *
> -early_memremap(resource_size_t phys_addr, unsigned long size)
> +early_memremap(resource_size_t phys_addr, unsigned long size,
> +              enum memremap_owner owner)
>  {
> -       return (__force void *)__early_ioremap(phys_addr, size,
> -                                              FIXMAP_PAGE_NORMAL);
> +       pgprot_t prot = early_memremap_pgprot_adjust(phys_addr, size, owner,
> +                                                    FIXMAP_PAGE_NORMAL);
> +
> +       return (__force void *)__early_ioremap(phys_addr, size, prot);
>  }
>  #ifdef FIXMAP_PAGE_RO
>  void __init *
> -early_memremap_ro(resource_size_t phys_addr, unsigned long size)
> +early_memremap_ro(resource_size_t phys_addr, unsigned long size,
> +                 enum memremap_owner owner)
>  {
> -       return (__force void *)__early_ioremap(phys_addr, size, FIXMAP_PAGE_RO);
> +       pgprot_t prot = early_memremap_pgprot_adjust(phys_addr, size, owner,
> +                                                    FIXMAP_PAGE_RO);
> +
> +       return (__force void *)__early_ioremap(phys_addr, size, prot);
>  }
>  #endif
>
> @@ -236,7 +251,8 @@ early_memremap_prot(resource_size_t phys_addr, unsigned long size,
>
>  #define MAX_MAP_CHUNK  (NR_FIX_BTMAPS << PAGE_SHIFT)
>
> -void __init copy_from_early_mem(void *dest, phys_addr_t src, unsigned long size)
> +void __init copy_from_early_mem(void *dest, phys_addr_t src, unsigned long size,
> +                               enum memremap_owner owner)
>  {
>         unsigned long slop, clen;
>         char *p;
> @@ -246,7 +262,7 @@ void __init copy_from_early_mem(void *dest, phys_addr_t src, unsigned long size)
>                 clen = size;
>                 if (clen > MAX_MAP_CHUNK - slop)
>                         clen = MAX_MAP_CHUNK - slop;
> -               p = early_memremap(src & PAGE_MASK, clen + slop);
> +               p = early_memremap(src & PAGE_MASK, clen + slop, owner);
>                 memcpy(dest, p + slop, clen);
>                 early_memunmap(p, clen + slop);
>                 dest += clen;
> @@ -265,12 +281,14 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
>
>  /* Remap memory */
>  void __init *
> -early_memremap(resource_size_t phys_addr, unsigned long size)
> +early_memremap(resource_size_t phys_addr, unsigned long size,
> +              enum memremap_owner owner)
>  {
>         return (void *)phys_addr;
>  }
>  void __init *
> -early_memremap_ro(resource_size_t phys_addr, unsigned long size)
> +early_memremap_ro(resource_size_t phys_addr, unsigned long size,
> +                 enum memremap_owner owner)
>  {
>         return (void *)phys_addr;
>  }
>