public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kai Huang <kai.huang@intel.com>
To: Martin Fernandez <martin.fernandez@eclypsium.com>,
	linux-kernel@vger.kernel.org
Cc: bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
	mingo@redhat.com, tglx@linutronix.de,
	kirill.shutemov@linux.intel.com, daniel.gutson@eclypsium.com,
	hughsient@gmail.com, alex.bazhaniuk@eclypsium.com
Subject: Re: [PATCH v2] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS
Date: Tue, 05 Jul 2022 22:15:38 +1200	[thread overview]
Message-ID: <8d2a3175be8a3aff1d3fc535dd9ab6217cfe1e66.camel@intel.com> (raw)
In-Reply-To: <20220704142250.1512726-1-martin.fernandez@eclypsium.com>

On Mon, 2022-07-04 at 11:22 -0300, Martin Fernandez wrote:
> Right now the only way to check this is by greping the kernel logs,
> which is inconvenient. This is currently checked for fwupd for
> example.
> 
> I understand that cpuinfo is supposed to report every feature in the
> cpu but since AMD is doing the same (and it also broke backwards
> compatibility [1]) for sme/sev I think it's good to have this for
> Intel too.
> 
> Another option to prevent greping the logs would be a file in
> sysfs. I'm open to suggestions to where to place this infomartion. I
> saw a proposal about a firmware security filesystem [2]; that would
> fit perfectly.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=08f253ec3767bcfafc5d32617a92cee57c63968e
> 
> [2] https://lore.kernel.org/all/20220622215648.96723-3-nayna@linux.ibm.com/

Leave above to others, but... 
> 
> Changelog since v1
> 
> Clear the flag not only for BSP but for every cpu in the system.

... the changelog history shouldn't be in the commit message.

You can put one additional '---' after your 'Signed-off-by' and add your
changelog after it.  The content between two '---'s will be stripped away by
'git am' when maintainer takes the patch:

	Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
	---
	v1->v2:
		xxx
	---
	arch/x86/kernel/cpu/intel.c | 1 +
	1 file changed, 1 insertion(+)
> 
> Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
> ---
>  arch/x86/kernel/cpu/intel.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index fd5dead8371c..17f23e23f911 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -570,6 +570,7 @@ static void detect_tme(struct cpuinfo_x86 *c)
> 
>  	if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activate)) {
>  		pr_info_once("x86/tme: not enabled by BIOS\n");
> +		clear_cpu_cap(c, X86_FEATURE_TME);
>  		mktme_status = MKTME_DISABLED;
>  		return;

This code change itself looks good to me.

But, TME actually supports bypassing TME encryption/decryption by setting 1 to
bit 31 to IA32_TME_ACTIVATE MSR.  See 'Table 4-2 IA32_TME_ACTIVATE MSR' in MKTME
spec below:

https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/002/intel-multi-key-total-memory-encryption/

When bit 31 is set, the TME is bypassed (no encryption/decryption for KeyID 0).

So looks userspace also needs to check this if it wants to truly check whether
"TME memory encryption" is active.

But perhaps it's arguable whether we can also clear TME flag in this case.

So:

Acked-by: Kai Huang <kai.huang@intel.com>


-- 
Thanks,
-Kai



  reply	other threads:[~2022-07-05 10:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 14:22 [PATCH v2] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS Martin Fernandez
2022-07-05 10:15 ` Kai Huang [this message]
2022-07-05 13:21   ` Martin Fernandez
2022-07-11 17:08     ` Sean Christopherson
2022-07-12  0:12       ` Kai Huang
2022-07-12  0:51         ` Sean Christopherson
2022-07-12  1:39           ` Kai Huang
2022-07-12 12:59             ` Martin Fernandez
2022-07-12 19:14               ` Sean Christopherson

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=8d2a3175be8a3aff1d3fc535dd9ab6217cfe1e66.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=alex.bazhaniuk@eclypsium.com \
    --cc=bp@alien8.de \
    --cc=daniel.gutson@eclypsium.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hughsient@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.fernandez@eclypsium.com \
    --cc=mingo@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox