linux-kernel - Re: [PATCH] x86/CPU/AMD, mm: Extend with mem

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:   Mon, 2 Oct 2017 10:07:33 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...e.de>
Cc:     brijesh.singh@....com, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option



On 10/02/2017 07:41 AM, Borislav Petkov wrote:
> On Mon, Oct 02, 2017 at 06:32:18AM -0500, Brijesh Singh wrote:
>> Because sev_enabled will always be 'false' when we are booting on bare
>> metal. Whereas when we are running under hypervisor then this variable
>> will be true for the SEV guest, please see [1].
> 
> Ok, then. This needs absolutely to be documented. Please add a comment
> over sev_enabled's definition.
> 
>> Both sev_active() and sme_active() make use of this variable
>> hence we will not be able to set the sev_enabled variable on bare
>> metal. Basically none of the SEV cases will be executed on bare
>> metal -- only thing which we need to take care of is clearing the
>> X86_FEATURE_SEV flag so that hypervisor will never launch SEV guest
>> when mem_encrypt=sme option is provided.
> 
> In that case, you want to disable SEV at the guest loading point,
> i.e., sev_guest_init() AFAICT is the earliest time we start prepping
> a SEV guest. You can add a __setup() early param which parses
> "mem_encrypt=sme", to arch/x86/kernel/cpu/amd.c and which sets a
> sev_host_enabled bool or so. sev_guest_init() can then check that
> variable before going any further. No need for any of that early parsing
> changes.


Yep, that will work just fine. There are couple of ways we can limit
hypervisor from creating the SEV guest 1) clear the X86_FEATURE_SEV bit
when mem_encrypt=sme is passed or 2) parse the mem_encrypt=xxx in kvm-amd.ko
and fail the KVM_SEV_INIT when mem_encrpt=sme or mem_encrypt=off.

I was not sure which way to go. We can go with #2 and kvm folks have any
concern then we can go back to #1. I will update KVM_SEV_INIT patch and
send you v4.1.

-Brijesh