linux-kernel - Re: [PATCH -v2 11/11] x86/sev: Change snp_guest_issue_request()'s fw

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]

Date:   Mon, 27 Feb 2023 15:03:12 -0800
From:   Dionna Amalie Glaze <dionnaglaze@...gle.com>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Borislav Petkov <bp@...en8.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Joerg Roedel <jroedel@...e.de>,
        Michael Roth <michael.roth@....com>,
        Nikunj A Dadhania <nikunj@....com>,
        Peter Gonda <pgonda@...gle.com>, linux-coco@...ts.linux.dev,
        x86@...nel.org
Subject: Re: [PATCH -v2 11/11] x86/sev: Change snp_guest_issue_request()'s
 fw_err argument

>
> Should this be?
>
>         input.exitinfo2 = SEV_RET_NO_FW_CALL;
>
> or make it part of patch #1?
>

This is something I'm not fully 100% on. You said that there's not
that many bits for firmware errors, so -1 or 0xff are fine by me so
long as neither are possible results from the firmware. I don't recall
the details on that, so if we go back to 0xff for SEV_RET_NO_FW_CALL,
I'd want a clearer explanation for why 0xff is sufficient.

Apart from the other comments from Tom which are a matter of style and
not semantics,

Tested-by: Dionna Glaze <dionnaglaze@...gle.com>

-- 
-Dionna Glaze, PhD (she/her)