linux-kernel - Re: [PATCH v7 10/13] kexec: Secure Launch kexec SEXIT support

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]

Date:   Wed, 15 Nov 2023 16:50:28 -0800
From:   ross.philipson@...cle.com
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-crypto@...r.kernel.org, iommu@...ts.linux-foundation.org,
        kexec@...ts.infradead.org, linux-efi@...r.kernel.org,
        dpsmith@...rtussolutions.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, ardb@...nel.org, mjg59@...f.ucam.org,
        James.Bottomley@...senpartnership.com, luto@...capital.net,
        nivedita@...m.mit.edu, kanth.ghatraju@...cle.com,
        trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v7 10/13] kexec: Secure Launch kexec SEXIT support

On 11/10/23 3:41 PM, Sean Christopherson wrote:
> On Fri, Nov 10, 2023, Ross Philipson wrote:
>> Prior to running the next kernel via kexec, the Secure Launch code
>> closes down private SMX resources and does an SEXIT. This allows the
>> next kernel to start normally without any issues starting the APs etc.
>>
>> Signed-off-by: Ross Philipson <ross.philipson@...cle.com>
>> ---
>>   arch/x86/kernel/slaunch.c | 73 +++++++++++++++++++++++++++++++++++++++
>>   kernel/kexec_core.c       |  4 +++
>>   2 files changed, 77 insertions(+)
>>
>> diff --git a/arch/x86/kernel/slaunch.c b/arch/x86/kernel/slaunch.c
>> index cd5aa34e395c..32b0c24a6484 100644
>> --- a/arch/x86/kernel/slaunch.c
>> +++ b/arch/x86/kernel/slaunch.c
>> @@ -523,3 +523,76 @@ void __init slaunch_setup_txt(void)
>>   
>>   	pr_info("Intel TXT setup complete\n");
>>   }
>> +
>> +static inline void smx_getsec_sexit(void)
>> +{
>> +	asm volatile (".byte 0x0f,0x37\n"
>> +		      : : "a" (SMX_X86_GETSEC_SEXIT));
> 
> SMX has been around for what, two decades?  Is open coding getsec actually necessary?

There were some older gcc compilers that still did not like the getsec 
mnemonic. Perhaps they are old enough now where they don't matter any 
longer. I will check on that...

> 
>> +	/* Disable SMX mode */
> 
> Heh, the code and the comment don't really agree.  I'm guessing the intent of the
> comment is referring to leaving the measured environment, but it looks odd.   If
> manually setting SMXE is necessary, I'd just delete this comment, or maybe move
> it to above SEXIT.

I will look it over and see what makes sense.

> 
>> +	cr4_set_bits(X86_CR4_SMXE);
> 
> Is it actually legal to clear CR4.SMXE while post-SENTER?  I don't see anything
> in the SDM that says it's illegal, but allowing software to clear SMXE in that
> case seems all kinds of odd.

I am pretty sure I coded this up using the pseudo code in the TXT dev 
guide and some guidance from Intel/former Intel folks. I will revisit it 
to make sure it is correct.

Thanks
Ross

> 
>> +
>> +	/* Do the SEXIT SMX operation */
>> +	smx_getsec_sexit();
>> +
>> +	pr_info("TXT SEXIT complete.\n");
>> +}