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: <17981a2e-03e3-81df-0654-5ccb29f43546@intel.com>
Date:   Wed, 6 Apr 2022 09:54:05 +0800
From:   Xiaoyao Li <xiaoyao.li@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, isaku.yamahata@...el.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     isaku.yamahata@...il.com, Jim Mattson <jmattson@...gle.com>,
        erdemaktas@...gle.com, Connor Kuehl <ckuehl@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: Re: [RFC PATCH v5 026/104] KVM: TDX: x86: Add vm ioctl to get TDX
 systemwide parameters

On 4/5/2022 8:52 PM, Paolo Bonzini wrote:
> On 3/4/22 20:48, isaku.yamahata@...el.com wrote:
>> Implement a VM-scoped subcomment to get system-wide parameters.  Although
>> this is system-wide parameters not per-VM, this subcomand is VM-scoped
>> because
>> - Device model needs TDX system-wide parameters after creating KVM VM.
>> - This subcommands requires to initialize TDX module.  For lazy
>>    initialization of the TDX module, vm-scope ioctl is better.
> 
> Since there was agreement to install the TDX module on load, please 
> place this ioctl on the /dev/kvm file descriptor.
> 
> At least for SEV, there were cases where the system-wide parameters are 
> needed outside KVM, so it's better to avoid requiring a VM file descriptor.

I don't have strong preference on KVM-scope ioctl or VM-scope.

Initially, we made it KVM-scope and change it to VM-scope in this 
version. Yes, it returns the info from TDX module, which doesn't vary 
per VM. However, what if we want to return different capabilities 
(software controlled capabilities) per VM? Part of the TDX capabilities 
serves like get_supported_cpuid, making it KVM wide lacks the 
flexibility to return differentiated capabilities for different TDs.


> Thanks,
> 
> Paolo
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ