| 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: Tue, 26 Apr 2022 10:25:45 -0300
From: Daniel Gutson <daniel.gutson@...ypsium.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Martin Fernandez <martin.fernandez@...ypsium.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
linux-mm@...ck.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, ardb@...nel.org,
dvhart@...radead.org, andy@...radead.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
rafael@...nel.org, akpm@...ux-foundation.org,
Richard Hughes <hughsient@...il.com>,
Alex Bazhaniuk <alex.bazhaniuk@...ypsium.com>,
Alison Schofield <alison.schofield@...el.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v7 1/8] mm/memblock: Tag memblocks with crypto capabilities
On Tue, Apr 26, 2022 at 10:21 AM Mike Rapoport <rppt@...nel.org> wrote:
>
> On Tue, Apr 26, 2022 at 09:59:04AM -0300, Martin Fernandez wrote:
> > On 4/26/22, Mike Rapoport <rppt@...nel.org> wrote:
> > > On Mon, Apr 25, 2022 at 02:15:19PM -0300, Martin Fernandez wrote:
> > >> Add the capability to mark regions of the memory memory_type able of
> > >> hardware memory encryption.
> > >>
> > >> Also add the capability to query if all regions of a memory node are
> > >> able to do hardware memory encryption to call it when initializing the
> > >> nodes. Warn the user if a node has both encryptable and
> > >> non-encryptable regions.
> > >>
> > >> Signed-off-by: Martin Fernandez <martin.fernandez@...ypsium.com>
> > >> ---
> > >> include/linux/memblock.h | 5 ++++
> > >> mm/memblock.c | 62 ++++++++++++++++++++++++++++++++++++++++
> > >> 2 files changed, 67 insertions(+)
> > >>
> > >> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > >> index 50ad19662a32..00c4f1a20335 100644
> > >> --- a/include/linux/memblock.h
> > >> +++ b/include/linux/memblock.h
> > >> @@ -40,6 +40,7 @@ extern unsigned long long max_possible_pfn;
> > >> * via a driver, and never indicated in the firmware-provided memory map
> > >> as
> > >> * system RAM. This corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED in
> > >> the
> > >> * kernel resource tree.
> > >> + * @MEMBLOCK_CRYPTO_CAPABLE: capable of hardware encryption
> > >> */
> > >> enum memblock_flags {
> > >> MEMBLOCK_NONE = 0x0, /* No special request */
> > >> @@ -47,6 +48,7 @@ enum memblock_flags {
> > >> MEMBLOCK_MIRROR = 0x2, /* mirrored region */
> > >> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */
> > >> MEMBLOCK_DRIVER_MANAGED = 0x8, /* always detected via a driver */
> > >> + MEMBLOCK_CRYPTO_CAPABLE = 0x10, /* capable of hardware encryption */
> > >> };
> > >>
> > >> /**
> > >> @@ -120,6 +122,9 @@ int memblock_physmem_add(phys_addr_t base, phys_addr_t
> > >> size);
> > >> void memblock_trim_memory(phys_addr_t align);
> > >> bool memblock_overlaps_region(struct memblock_type *type,
> > >> phys_addr_t base, phys_addr_t size);
> > >> +bool memblock_node_is_crypto_capable(int nid);
> > >> +int memblock_mark_crypto_capable(phys_addr_t base, phys_addr_t size);
> > >> +int memblock_clear_crypto_capable(phys_addr_t base, phys_addr_t size);
> > >> int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
> > >> int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
> > >> int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> > >> diff --git a/mm/memblock.c b/mm/memblock.c
> > >> index e4f03a6e8e56..fe62f81572e6 100644
> > >> --- a/mm/memblock.c
> > >> +++ b/mm/memblock.c
> > >> @@ -191,6 +191,40 @@ bool __init_memblock memblock_overlaps_region(struct
> > >> memblock_type *type,
> > >> return i < type->cnt;
> > >> }
> > >>
> > >> +/**
> > >> + * memblock_node_is_crypto_capable - get if whole node is capable
> > >> + * of encryption
> > >> + * @nid: number of node
> > >> + *
> > >> + * Iterate over all memory memblock_type and find if all regions under
> > >> + * node @nid are capable of hardware encryption.
> > >> + *
> > >> + * Return:
> > >> + * true if every region in memory memblock_type is capable of
> > >
> > > I'd s/in memory memblock_type/in @nid
> > >
> >
> > Good, thanks.
> >
> > >> + * encryption, false otherwise.
> > >> + */
> > >> +bool __init_memblock memblock_node_is_crypto_capable(int nid)
> > >> +{
> > >> + struct memblock_region *region;
> > >> + int crypto_capables = 0;
> > >> + int not_crypto_capables = 0;
> > >> +
> > >> + for_each_mem_region(region) {
> > >> + if (memblock_get_region_node(region) == nid) {
> > >> + if (region->flags & MEMBLOCK_CRYPTO_CAPABLE)
> > >> + crypto_capables++;
> > >> + else
> > >> + not_crypto_capables++;
> > >> + }
> > >> + }
> > >> +
> > >> + if (crypto_capables > 0 && not_crypto_capables > 0)
> > >> + pr_warn("Node %d has %d regions that are encryptable and %d regions
> > >> that aren't",
> > >> + nid, not_crypto_capables, crypto_capables);
> > >> +
> > >> + return not_crypto_capables == 0;
> > >
> > > This will return true for memoryless nodes as well. Do you mean to consider
> > > them as capable of encryption?
> > >
> >
> > Not really, I didn't think about that to be honest. I don't think it's
> > a good idea to consider them as capable, right?
>
> I think capable of encryption would mean
>
> crypto_capables && !not_crypto_capables
Since these operands were evaluated above with comparison ops, I would say
crypto_capables > 0 && not_crypto_capables == 0
to improve readability and be explicit that they are numbers rather
than booleans.
>
> --
> Sincerely yours,
> Mike.
Powered by blists - more mailing lists