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]
Message-ID: <20171017082020.ctgjuo4xcvsaitdf@pd.tnic>
Date:   Tue, 17 Oct 2017 10:20:20 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Brijesh Singh <brijesh.singh@....com>
Cc:     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 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.

> 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() ?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ