linux-kernel - Re: [PATCH kernel v2] x86/compressed/64: reduce #VC nesting for intercepted CPUID for SEV-SNP guest

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] [day] [month] [year] [list]

Message-ID: <6917dfcb-651b-45a0-9dc7-c42f765dea02@amd.com>
Date:   Tue, 3 Oct 2023 12:45:48 +1100
From:   Alexey Kardashevskiy <aik@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH kernel v2] x86/compressed/64: reduce #VC nesting for
 intercepted CPUID for SEV-SNP guest


On 1/10/23 20:53, Borislav Petkov wrote:
> On Sun, Oct 01, 2023 at 08:40:30PM +1100, Alexey Kardashevskiy wrote:
>> Ingo says different, who wins? :)
> 
> I do: a function gives you type checking - a macro doesn't.

The macro is a wrapper for the sev_es_ghcb_hv_call() function with type 
checking.

>>> Then, it should be defined only in sev-shared.c for now.
>>
>> sev-shared.c makes me sad. Including .c is not ... nice,
> 
> There's a point in doing things this way.
> 
>> I would avoid adding stuff to it at any cost.
> 
> Care to give a technical argument why or is it just general sadness?
> Because I don't care about non-technical sentiments.

No it is not technical, it is my ignorance :)

For example why inat.c/insn.c are included and not linked? Cannot linux 
compile arch/x86/lib/ files twice into two different .o, for compressed 
and running kernels? Is not more logical place for sev-shared.c in 
arch/x86/lib/sev.c?

>>> Furthermore, it should not be called "rdmsr" or so but something like
>>>
>>> ghcb_prot_read_msr()
>>>
>>> or so to denote that it is using the GHCB protocol to read the MSR. I'm
>>> sure it'll gain more users with time.
>>
>> What is "prot" going to signify?
> 
> "... or so to denote that it is using the GHCB protocol..."
> 					       ^^^^^^^^
> 
> it is right there.

Ah right. I am used (after some grepping - not just me) to "prot" == 
"protected", "protocol" would be "proto". imho not needed here but alright.


>> And what about Tom's "x86/sev: Fix SNP CPUID requests to the hypervisor",
>> are you taking that one or I have to repost this one and the Tom's patch?
> 
> Yes, use this branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=tip-x86-urgent


Oh cool, thanks!


> Thx.
> 

-- 
Alexey