linux-kernel - Re: [PATCH v13 016/113] KVM: TDX: x86: Add ioctl to get TDX systemwide parameters

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: <20230331153107.0000029d@gmail.com>
Date:   Fri, 31 Mar 2023 15:31:07 +0300
From:   Zhi Wang <zhi.wang.linux@...il.com>
To:     Xiaoyao Li <xiaoyao.li@...el.com>
Cc:     isaku.yamahata@...el.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, isaku.yamahata@...il.com,
        Paolo Bonzini <pbonzini@...hat.com>, erdemaktas@...gle.com,
        Sean Christopherson <seanjc@...gle.com>,
        Sagi Shahar <sagis@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Kai Huang <kai.huang@...el.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH v13 016/113] KVM: TDX: x86: Add ioctl to get TDX
 systemwide parameters

On Fri, 31 Mar 2023 14:59:18 +0800
Xiaoyao Li <xiaoyao.li@...el.com> wrote:

> On 3/25/2023 4:43 PM, Zhi Wang wrote:
> > On Sun, 12 Mar 2023 10:55:40 -0700
> > isaku.yamahata@...el.com  wrote:
> > 
> > Does this have to be a new generic ioctl with a dedicated new x86_ops? SNP
> > does not use it at all and all the system-scoped ioctl of SNP going through
> > the CCP driver. So getting system-scope information of TDX/SNP will end up
> > differently.
> > 
> > Any thought, Sean? Moving getting SNP system-wide information to
> > KVM dev ioctl seems not ideal and TDX does not have a dedicated driver like
> > CCP. Maybe make this ioctl TDX-specific? KVM_TDX_DEV_OP?
> 
> What's the real different of it? For me, it's just renaming 
> KVM_MEMORY_ENCRYPT_OP to KVM_TDX_DEV_OP and maybe add some error message 
> if the IOCTL is issued for AMD plaform.
> 

Hi:

The ioctl is the API for the userspace. The purpose is to be orthogonal,
avoid confusion and reflect its nature. A "generic" name with only one
implementation is fine in the early design. But if the other implementation
at the same level is pretty sure not going to use it, then the abstraction,
which is only abstracted for one implementation, is just confusing.

The possible strategies are:

1) Re-factor the other implementation to fit the current abstraction.
2) Give up the abstraction. Go "specific".

For 1), it seems not realistic due to the efforts of re-factoring the SEV
driver.

For 2), there can be several ways: a. renaming it, let the name reflect
its nature. IMO, KVM_TDX_DEV_OP is not ideal as well, but I don't have a
better one. b. moving it to a proper layer of the implementation. But
it is also not realistic to have a "TDX" driver because of it. That's why
I am torn here.