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:   Tue, 12 Jul 2022 09:59:52 -0300
From:   Martin Fernandez <martin.fernandez@...ypsium.com>
To:     Kai Huang <kai.huang@...el.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, mingo@...hat.com,
        tglx@...utronix.de, kirill.shutemov@...ux.intel.com,
        daniel.gutson@...ypsium.com, hughsient@...il.com,
        alex.bazhaniuk@...ypsium.com
Subject: Re: [PATCH v2] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is
 disabled by BIOS

On 7/11/22, Kai Huang <kai.huang@...el.com> wrote:
>
>>
>> > This patch basically tries to fix the issue that TME flag isn't cleared
>> > when TME
>> > is disabled by BIOS.  And fir this purpose, the code change in this
>> > patch looks
>> > reasonable to me.  Unless I am mistaken, detect_tme() will be called for
>> > all
>> > cpus if TME is supported in CPUID but isn't enabled by BIOS (either
>> > LOCKED or
>> > ENABLED bit isn't set).
>>
>> But this patch doesn't handle the bypass bit, which _does_ effectively
>> disable
>> TME when set.  E.g. the MKTME spec says:
>>
>>  Software must inspect the Hardware Encryption Enable (bit 1) and TME
>> Encryption
>>  Bypass Enable (bit 31) to determine if TME encryption is enabled.
>
> Yeah so my original reply said:
>
> "But perhaps it's arguable whether we can also clear TME flag in this
> case."
>
> And I only gave my Acked-by.
>
> It completely depends on the purpose of this patch, or what does this patch
> claim to do.  If it only claims to clear TME bit if BIOS doesn't enable it,
> then
> looks fine to me.  If it wants to achieve "clear TME feature flag if
> encryption
> isn't active", then yes you are right.
>
> But as I said perhaps "whether we should clear TME flag when bypass is
> enabled"
> is arguable.  After all, what does TME flag in /proc/cpuinfo imply?
>

What we want with this patch is to check whether some kind of memory
encryption is active. Right now we are doing it by checking the "tme
active in BIOS" log, so we are not checking the bypass.

Can you change this bypass bit at runtime? ie, does it make sense to
check it only once at boot time?

If no, then maybe it's ok to check that bit in detect_tme and consider
it for cpuinfo,

If it can change, then probably it's ok to leave this patch as is, and
for our use case maybe we can add a sysfs file that reads that msr.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ