All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Martin Fernandez <martin.fernandez@eclypsium.com>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, linux-mm@kvack.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	ardb@kernel.org, dvhart@infradead.org, andy@infradead.org,
	gregkh@linuxfoundation.org, rafael@kernel.org,
	akpm@linux-foundation.org, daniel.gutson@eclypsium.com,
	hughsient@gmail.com, alex.bazhaniuk@eclypsium.com,
	alison.schofield@intel.com, keescook@chromium.org
Subject: Re: [PATCH v6 1/6] mm/memblock: Tag memblocks with crypto capabilities
Date: Thu, 3 Feb 2022 20:07:38 +0200	[thread overview]
Message-ID: <YfwZ6ne9ND1JaReS@kernel.org> (raw)
In-Reply-To: <20220203164328.203629-2-martin.fernandez@eclypsium.com>

On Thu, Feb 03, 2022 at 01:43:23PM -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@eclypsium.com>
> ---
>  include/linux/memblock.h | 15 ++++++----
>  mm/memblock.c            | 64 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 9dc7cb239d21..73edcce165a5 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -41,13 +41,15 @@ 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 */
> -	MEMBLOCK_HOTPLUG	= 0x1,	/* hotpluggable region */
> -	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_NONE		= 0x0,		/* No special request */
> +	MEMBLOCK_HOTPLUG	= 0x1,		/* hotpluggable region */
> +	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 */

Please keep the comment indentation.

>  };
>  
>  /**
> @@ -121,6 +123,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 1018e50566f3..fcf79befeab3 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -191,6 +191,42 @@ 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
> + * encryption, false otherwise.
> + */
> +bool __init_memblock memblock_node_is_crypto_capable(int nid)
> +{
> +	struct memblock_region *region;
> +	bool crypto_capable = false;
> +	bool not_crypto_capable = false;
> +
> +	for_each_mem_region(region) {
> +		if (memblock_get_region_node(region) == nid) {
> +			crypto_capable =
> +				crypto_capable ||
> +				(region->flags & MEMBLOCK_CRYPTO_CAPABLE);
> +			not_crypto_capable =
> +				not_crypto_capable ||
> +				!(region->flags & MEMBLOCK_CRYPTO_CAPABLE);

Isn't

 			if (region->flags & MEMBLOCK_CRYPTO_CAPABLE)
				crypto_capable++;
			else
				not_crypto_capable++;

simpler and clearer?

(of course s/bool/int in the declaration)

> +		}
> +	}
> +
> +	if (crypto_capable && not_crypto_capable)
> +		pr_warn_once("Node %d has regions that are encryptable and regions that aren't",
> +			     nid);

This will print only the first node with mixed regions. With a single
caller of memblock_node_is_crypto_capable() I think pr_warn() is ok.

> +
> +	return !not_crypto_capable;
> +}
> +
>  /**
>   * __memblock_find_range_bottom_up - find free area utility in bottom-up
>   * @start: start of candidate range
> @@ -885,6 +921,34 @@ static int __init_memblock memblock_setclr_flag(phys_addr_t base,
>  	return 0;
>  }
>  
> +/**
> + * memblock_mark_crypto_capable - Mark memory regions capable of hardware
> + * encryption with flag MEMBLOCK_CRYPTO_CAPABLE.
> + * @base: the base phys addr of the region
> + * @size: the size of the region
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +int __init_memblock memblock_mark_crypto_capable(phys_addr_t base,
> +						 phys_addr_t size)
> +{
> +	return memblock_setclr_flag(base, size, 1, MEMBLOCK_CRYPTO_CAPABLE);
> +}
> +
> +/**
> + * memblock_clear_crypto_capable - Clear flag MEMBLOCK_CRYPTO for a
> + * specified region.
> + * @base: the base phys addr of the region
> + * @size: the size of the region
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +int __init_memblock memblock_clear_crypto_capable(phys_addr_t base,
> +						  phys_addr_t size)
> +{
> +	return memblock_setclr_flag(base, size, 0, MEMBLOCK_CRYPTO_CAPABLE);
> +}
> +
>  /**
>   * memblock_mark_hotplug - Mark hotpluggable memory with flag MEMBLOCK_HOTPLUG.
>   * @base: the base phys addr of the region
> -- 
> 2.30.2
> 

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2022-02-03 18:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 16:43 [PATCH v6 0/6] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 1/6] mm/memblock: Tag memblocks with crypto capabilities Martin Fernandez
2022-02-03 18:07   ` Mike Rapoport [this message]
2022-02-03 18:24     ` Martin Fernandez
2022-02-07 21:18   ` Kees Cook
2022-02-08 14:39     ` Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 2/6] mm/mmzone: Tag pg_data_t " Martin Fernandez
2022-02-07 21:19   ` Kees Cook
2022-02-03 16:43 ` [PATCH v6 3/6] x86/e820: Refactor range_update and range_remove Martin Fernandez
2022-02-07 21:45   ` Kees Cook
2022-02-08  8:40     ` Mike Rapoport
2022-02-08 21:01       ` Martin Fernandez
2022-02-15  7:10         ` Mike Rapoport
2022-02-15 14:14           ` Martin Fernandez
2022-02-08 21:09     ` Martin Fernandez
2022-03-04 20:32     ` Martin Fernandez
2022-02-08 21:04   ` Daniel Gutson
2022-02-03 16:43 ` [PATCH v6 4/6] x86/e820: Tag e820_entry with crypto capabilities Martin Fernandez
2022-02-07 21:56   ` Kees Cook
2022-02-08 14:46     ` Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 5/6] x86/efi: Tag e820_entries as crypto capable from EFI memmap Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto capabilities Martin Fernandez
2022-02-04  3:47   ` Limonciello, Mario
2022-02-04 13:21     ` Martin Fernandez
2022-02-04 15:59       ` Tom Lendacky
2022-02-04 16:23         ` Limonciello, Mario
2022-02-04 16:28           ` Borislav Petkov
2022-02-04 17:12             ` Tom Lendacky
2022-02-04 17:49               ` Limonciello, Mario
2022-02-04 18:00               ` Borislav Petkov
2022-02-04 18:49                 ` Tom Lendacky
2022-02-04 21:49                   ` Borislav Petkov
2022-02-07  3:39             ` Kees Cook
2022-02-07 10:02               ` Borislav Petkov
2022-02-04  4:56   ` Mike Rapoport
2022-02-04 12:27     ` Martin Fernandez
2022-02-04 13:37       ` Mike Rapoport

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=YfwZ6ne9ND1JaReS@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.bazhaniuk@eclypsium.com \
    --cc=alison.schofield@intel.com \
    --cc=andy@infradead.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=daniel.gutson@eclypsium.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=hughsient@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin.fernandez@eclypsium.com \
    --cc=mingo@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.