linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Dov Murik <dovmurik@linux.ibm.com>, linux-efi@vger.kernel.org
Cc: Borislav Petkov <bp@suse.de>, Ashish Kalra <ashish.kalra@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andi Kleen <ak@linux.intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andrew Scull <ascull@google.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
	Jim Cadden <jcadden@ibm.com>,
	Daniele Buono <dbuono@linux.vnet.ibm.com>,
	linux-coco@lists.linux.dev,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/4] virt: Add sev_secret module to expose confidential computing secrets
Date: Thu, 7 Oct 2021 06:48:54 -0700	[thread overview]
Message-ID: <290c21a8-a68f-0826-2754-1480f79a081d@intel.com> (raw)
In-Reply-To: <20211007061838.1381129-5-dovmurik@linux.ibm.com>

On 10/6/21 11:18 PM, Dov Murik wrote:
> +static void wipe_memory(void *addr, size_t size)
> +{
> +	memzero_explicit(addr, size);
> +	clean_cache_range(addr, size);
> +}

What's the purpose of the clean_cache_range()?  It's backed in a CLWB
instruction on x86 which seems like an odd choice.  I guess the point is
that the memzero_explicit() will overwrite the contents, but might have
dirty lines in the cache.  The CLWB will ensure that the lines are
actually written back to memory, clearing the secret out of memory.
Without the CLWB, the secret might live in memory until the dirtied
cachelines are written back.

Could you document this, please?  It would also be nice to include some
of this motivation in the patch that exports clean_cache_range() in the
first place.

I also think clean_cache_range() an odd choice.  If it were me, I
probably would have just used the already-exported
clflush_cache_range().  The practical difference between writing back
and flushing the cachelines is basically zero.  The lines will never be
reused.

*If* we export anything from x86 code, I think it should be something
which is specific to the task at hand, like arch_invalidate_pmem() is.

Also, when you are modifying x86 code, including exports, it would be
nice to include (all of) the x86 maintainers.  The relevant ones for
this series would probably be:

X86 ARCHITECTURE (32-BIT AND 64-BIT)
M:      Thomas Gleixner <tglx@linutronix.de>
M:      Ingo Molnar <mingo@redhat.com>
M:      Borislav Petkov <bp@alien8.de>
M:      x86@kernel.org

X86 MM
M:      Dave Hansen <dave.hansen@linux.intel.com>
M:      Andy Lutomirski <luto@kernel.org>
M:      Peter Zijlstra <peterz@infradead.org>

There's also the handy dandy scripts/get_maintainer.pl to help.

  parent reply	other threads:[~2021-10-07 13:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07  6:18 [PATCH v2 0/4] Allow access to confidential computing secret area in SEV guests Dov Murik
2021-10-07  6:18 ` [PATCH v2 1/4] x86: Export clean_cache_range() Dov Murik
2021-10-07  6:18 ` [PATCH v2 2/4] efi/libstub: Copy confidential computing secret area Dov Murik
2021-10-07  6:18 ` [PATCH v2 3/4] efi: Reserve " Dov Murik
2021-10-07  6:18 ` [PATCH v2 4/4] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
2021-10-07 13:32   ` Dave Hansen
2021-10-07 16:17     ` Dr. David Alan Gilbert
2021-10-08  5:40       ` Dov Murik
2021-10-07 13:48   ` Dave Hansen [this message]
2021-10-08  5:51     ` Dov Murik

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=290c21a8-a68f-0826-2754-1480f79a081d@intel.com \
    --to=dave.hansen@intel.com \
    --cc=ak@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=ascull@google.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=dbuono@linux.vnet.ibm.com \
    --cc=dgilbert@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jcadden@ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@linux.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).