linux-kernel - Re: [RFC PATCH 4/8] x86/power: Restore Key Locker internal key from the ACPI S3/4 sleep states

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:   Fri, 18 Dec 2020 01:00:37 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Eric Biggers <ebiggers@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        Andy Lutomirski <luto@...nel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "Sun, Ning" <ning.sun@...el.com>,
        "Dwarakanath, Kumar N" <kumar.n.dwarakanath@...el.com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [RFC PATCH 4/8] x86/power: Restore Key Locker internal key from
 the ACPI S3/4 sleep states


> On Dec 18, 2020, at 04:10, Eric Biggers <ebiggers@...nel.org> wrote:
> 
> On Wed, Dec 16, 2020 at 09:41:42AM -0800, Chang S. Bae wrote:
>> When the system state switches to these sleep states, the internal key gets
>> reset. Since this system transition is transparent to userspace, the
>> internal key needs to be restored properly.
>> 
>> Key Locker provides a mechanism to back up the internal key in non-volatile
>> memory. The kernel requests a backup right after the key loaded at
>> boot-time and copies it later when the system wakes up.
>> 
>> The backup during the S5 sleep state is not trusted. It is overwritten by a
>> new key at the next boot.
>> 
>> On a system with the S3/4 states, enable the feature only when the backup
>> mechanism is supported.
>> 
>> Disable the feature when the copy fails (or the backup corrupts). The
>> shutdown is considered too noisy. A new key is considerable only when
>> threads can be synchronously suspended.
> 
> Can this backup key be used to decrypt the encoded AES keys without executing
> the keylocker instructions on the same CPU?

No. The backup key itself is inaccessible to the software.

Thanks,
Chang