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 06:54:52 -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 3:20 AM, Borislav Petkov wrote:
> On Mon, Oct 16, 2017 at 08:43:15PM -0500, Brijesh Singh wrote:
>> Actually, I worked to enable the kvmclock support before the
>> kvm-stealtime, eoi and apf_reason. The kvmclock uses memblock_alloc() to
>> allocate the shared memory and since the memblock_alloc() returns the
>> physical address hence I used the same input type as a argument to the
>> early_set_memory_decrypted(). If you want me to change the input to
>> accept the virtual address then I have no issue doing so. But the
>> changes need to propagated to kvmclock (i.e PATCH 17/17) to use __va().
> And? You already convert addresses you've gotten from memblock with
> __va there.
>
>> Please let me know if you want me to pass the virtual address.
> Yes please. The kernel generally handles virtual addresses and the
> physical addresses you get from memblock, you simply convert once and
> hand in for decryption.


Will do. Do you want me to send v7 with that addressed. Because this
require changes in 3 patches (PATCH 14, 16, 17)

>
>> IIRC, we tried clearing C bit in kvm_guest_init() but since the
>> kvm_guest_init() is called before setup_per_cpu_areas() hence
>> per_cpu_ptr(var, cpu_id) was not able to get another processors copy of
>> the variable.
> But you are still calling it in kvm_guest_init(). So that second call
> can be removed and you can call it only in kvm_smp_prepare_boot_cpu() ?
>

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 ?



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ