From: Dov Murik <dovmurik@linux.ibm.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, linux-efi@vger.kernel.org
Cc: Laszlo Ersek <lersek@redhat.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Ard Biesheuvel <ardb@kernel.org>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Andi Kleen <ak@linux.intel.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>,
linux-coco@lists.linux.dev,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/3] efi: Reserve confidential computing secret area
Date: Tue, 29 Jun 2021 09:04:48 +0300 [thread overview]
Message-ID: <996db75c-5648-17b1-5bae-f3b10d72c110@linux.ibm.com> (raw)
In-Reply-To: <9b9b682f-297e-9ebd-4d67-43c3ed9ad8c5@amd.com>
Hi Tom,
On 28/06/2021 23:40, Tom Lendacky wrote:
> On 6/28/21 1:34 PM, Dov Murik wrote:
>> When efi-stub copies an EFI-provided confidential computing secret area,
>> reserve that memory block for future use within the kernel.
>>
>> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
>> ---
>> drivers/firmware/efi/Makefile | 2 +-
>> drivers/firmware/efi/confidential-computing.c | 41 +++++++++++++++++++
>> drivers/firmware/efi/efi.c | 5 +++
>> include/linux/efi.h | 4 ++
>> 4 files changed, 51 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/firmware/efi/confidential-computing.c
>>
>> diff --git a/include/linux/efi.h b/include/linux/efi.h
>> index 4f647f1ee298..e9740bd16db0 100644
>> --- a/include/linux/efi.h
>> +++ b/include/linux/efi.h
>> @@ -551,6 +551,8 @@ extern struct efi {
>> unsigned long tpm_log; /* TPM2 Event Log table */
>> unsigned long tpm_final_log; /* TPM2 Final Events Log table */
>> unsigned long mokvar_table; /* MOK variable config table */
>> + unsigned long confidential_computing_secret; /* Confidential computing */
>> + /* secret table */
>
> If there is any possibility that someone could reuse a form of this
> confidential computing secret table in a bare metal system, then this
> table needs to be added to the efi_tables[] array in
> arch/x86/platform/efi/efi.c. Otherwise, it will be mapped improperly on a
> system with SME active.
Good catch, thanks. I see that all existing table addresses from
struct efi are added to the efi_tables[] array, so for completeness it
makes sense to add efi.confidential_computing_secret as well (even
though currently bare metal firmware doesn't have this table).
Thanks,
-Dov
>
> Thanks,
> Tom
>
>>
>> efi_get_time_t *get_time;
>> efi_set_time_t *set_time;
>> @@ -1190,6 +1192,8 @@ extern int efi_tpm_final_log_size;
>>
>> extern unsigned long rci2_table_phys;
>>
>> +extern int efi_confidential_computing_secret_area_reserve(void);
>> +
>> /*
>> * efi_runtime_service() function identifiers.
>> * "NONE" is used by efi_recover_from_page_fault() to check if the page
>>
next prev parent reply other threads:[~2021-06-29 6:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 18:34 [RFC PATCH v2 0/3] Allow access to confidential computing secret area Dov Murik
2021-06-28 18:34 ` [RFC PATCH v2 1/3] efi/libstub: Copy " Dov Murik
2021-06-28 18:34 ` [RFC PATCH v2 2/3] efi: Reserve " Dov Murik
2021-06-28 20:40 ` Tom Lendacky
2021-06-29 6:04 ` Dov Murik [this message]
2021-06-28 18:34 ` [RFC PATCH v2 3/3] virt: Add sev_secret module to expose confidential computing secrets Dov Murik
2021-06-28 19:30 ` Borislav Petkov
2021-06-29 7:23 ` Dov Murik
2021-06-29 22:48 ` Borislav Petkov
2021-06-28 22:59 ` kernel test robot
2021-06-28 19:28 ` [RFC PATCH v2 0/3] Allow access to confidential computing secret area Borislav Petkov
2021-06-29 7:16 ` Dov Murik
2021-06-29 17:33 ` Borislav Petkov
2021-06-29 0:21 [RFC PATCH v2 2/3] efi: Reserve " kernel test robot
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=996db75c-5648-17b1-5bae-f3b10d72c110@linux.ibm.com \
--to=dovmurik@linux.ibm.com \
--cc=ak@linux.intel.com \
--cc=ardb@kernel.org \
--cc=ashish.kalra@amd.com \
--cc=brijesh.singh@amd.com \
--cc=dgilbert@redhat.com \
--cc=jcadden@ibm.com \
--cc=jejb@linux.ibm.com \
--cc=jmorris@namei.org \
--cc=lersek@redhat.com \
--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 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.