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, 17 Oct 2017 10:42:45 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     brijesh.singh@....com, x86@...nel.org,
        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>,
        Tom Lendacky <thomas.lendacky@....com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [Part1 PATCH v6 16/17] X86/KVM: Decrypt shared per-cpu variables
 when SEV is active



On 10/17/17 8:35 AM, Borislav Petkov wrote:
...

>> The second call is for UP cases. The kvm_smp_prepapre_boot_cpu() is
>> called only when CONFIG_SMP is enabled. Am I missing something ?
> Yes, you are.
>
> kvm_guest_init() gets called unconditionally from setup_arch(). But then
> you said kvm_guest_init() is called before setup_per_cpu_areas() so why
> do you need that call there at all? percpu areas are not ready yet, what
> makes them ready in the UP case?


I believe in the case of UP,  the setup_per_cpu_areas() does not do
anything special for the static per-cpu variables hence its fine to
access them. If we look at kvm_guest_init() then it directly jumps to
kvm_guest_cpu_init() in UP case. But in the case of CONFIG_SMP the
kvm_guest_cpu_init() is called from the kvm_smp_prepare_boot_cpu().


> IOW, this sev_map_percpu_data() needs to happen only once, during boot.
> So call it only once by finding the right spot and not by adding a
> second call for the UP case.
>
> AFAICT, it looks the easiest if you put it in kvm_guest_cpu_init() and
> do something like:
>
> 	if (smp_processor_id() == boot_cpu_data.cpu_index)
> 		sev_map_percpu_data();
>
> ...
>

OK, this goes back to your initial feedback during RFC v3 where I tried
to do similar thing. But since sev_map_percpu_data() uses __init
functions hence we need to mark the kvm_guest_cpu_init() as __ref but
you didn't like the idea and asked me to call the sev_map_percpu_data
from kvm_smp_prepare_boot_cpu() which is already __init.


 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ