All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Roy Hopkins <roy.hopkins@suse.com>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Marcelo Tosatti" <mtosatti@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Sergio Lopez" <slp@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Peter Xu" <peterx@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"Ani Sinha" <anisinha@redhat.com>,
	"Jörg Roedel" <jroedel@suse.com>
Subject: Re: [PATCH v4 06/17] sev: Fix error handling in sev_encrypt_flash()
Date: Wed, 24 Jul 2024 18:19:35 +0100	[thread overview]
Message-ID: <ZqE3p79BWyyyJm0j@redhat.com> (raw)
In-Reply-To: <9930eadc36539f6135a0332116a51d48847505fe.1720004383.git.roy.hopkins@suse.com>

On Wed, Jul 03, 2024 at 12:05:44PM +0100, Roy Hopkins wrote:
> The function sev_encrypt_flash() checks to see if the return value of
> launch_update_data() < 0, but the function returns a non-zero (and not
> necessarily negative) result on error. This means that some errors in
> updating launch data will result in the function returning success.

I'm not sure that positive return values are intended as an error ?
The sev_launch_update_data method does:

    if (!addr || !len) {
        return 1;
    }

which seems to suggest that passing a NULL addr / zero-length,
was intended to be treated as a no-op, rather than an error.

If that interpretation is wrong, then, I'd suggest that
sev_launch_update_data be changed to return '-1' in this
case, since QEMU standard is to consider negative values
as errors.

> 
> In addition, the function takes an Error parameter which is not used
> when an error is actually returned.
> 
> The return value is now checked for non-zero to indicate an error and
> a suitable error message is logged.
> 
> Signed-off-by: Roy Hopkins <roy.hopkins@suse.com>
> ---
>  target/i386/sev.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 3ab8b3c28b..491ca5369e 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -1542,12 +1542,9 @@ sev_encrypt_flash(hwaddr gpa, uint8_t *ptr, uint64_t len, Error **errp)
>  
>      /* if SEV is in update state then encrypt the data else do nothing */
>      if (sev_check_state(sev_common, SEV_STATE_LAUNCH_UPDATE)) {
> -        int ret;
> -
> -        ret = klass->launch_update_data(sev_common, gpa, ptr, len);
> -        if (ret < 0) {
> -            error_setg(errp, "SEV: Failed to encrypt pflash rom");
> -            return ret;
> +        if (klass->launch_update_data(sev_common, gpa, ptr, len)) {
> +            error_setg(errp, "SEV: Failed to encrypt flash");
> +            return -1;

sev_launch_update_data() calls error_report with the real error
details, and here we file a information-less error message.

Can we add "Error **errp" to the 'launch_update_data' API contract,
and change the error_report() calls to error_setg(), so we have
the useful information propagated in the Error object.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2024-07-24 17:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03 11:05 [PATCH v4 00/17] Introduce support for IGVM files Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 01/17] meson: Add optional dependency on IGVM library Roy Hopkins
2024-07-24 16:26   ` Daniel P. Berrangé
2024-07-03 11:05 ` [PATCH v4 02/17] backends/confidential-guest-support: Add functions to support IGVM Roy Hopkins
2024-07-24 16:47   ` Daniel P. Berrangé
2024-07-03 11:05 ` [PATCH v4 03/17] backends/igvm: Add IGVM loader and configuration Roy Hopkins
2024-07-24 16:59   ` Daniel P. Berrangé
2024-07-29 13:35   ` Stefano Garzarella
2024-07-03 11:05 ` [PATCH v4 04/17] hw/i386: Add igvm-cfg object and processing for IGVM files Roy Hopkins
2024-07-24 17:08   ` Daniel P. Berrangé
2024-07-03 11:05 ` [PATCH v4 05/17] i386/pc_sysfw: Ensure sysfw flash configuration does not conflict with IGVM Roy Hopkins
2024-07-24 17:13   ` Daniel P. Berrangé
2024-08-13 10:42     ` Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 06/17] sev: Fix error handling in sev_encrypt_flash() Roy Hopkins
2024-07-24 17:19   ` Daniel P. Berrangé [this message]
2024-07-03 11:05 ` [PATCH v4 07/17] sev: Update launch_update_data functions to use Error handling Roy Hopkins
2024-07-24 17:21   ` Daniel P. Berrangé
2024-07-03 11:05 ` [PATCH v4 08/17] target/i386: Allow setting of R_LDTR and R_TR with cpu_x86_load_seg_cache() Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 09/17] i386/sev: Refactor setting of reset vector and initial CPU state Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 10/17] i386/sev: Implement ConfidentialGuestSupport functions for SEV Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 11/17] docs/system: Add documentation on support for IGVM Roy Hopkins
2024-07-24 17:25   ` Daniel P. Berrangé
2024-07-29 13:41   ` Stefano Garzarella
2024-07-03 11:05 ` [PATCH v4 12/17] docs/interop/firmware.json: Add igvm to FirmwareDevice Roy Hopkins
2024-07-24 17:27   ` Daniel P. Berrangé
2024-07-03 11:05 ` [PATCH v4 13/17] backends/confidential-guest-support: Add set_guest_policy() function Roy Hopkins
2024-07-24 17:30   ` Daniel P. Berrangé
2024-07-03 11:05 ` [PATCH v4 14/17] backends/igvm: Process initialization sections in IGVM file Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 15/17] backends/igvm: Handle policy for SEV guests Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 16/17] i386/sev: Add implementation of CGS set_guest_policy() Roy Hopkins
2024-07-03 11:05 ` [PATCH v4 17/17] sev: Provide sev_features flags from IGVM VMSA to KVM_SEV_INIT2 Roy Hopkins
2024-07-20 18:26 ` [PATCH v4 00/17] Introduce support for IGVM files Michael S. Tsirkin
2024-08-13  9:53   ` Roy Hopkins
2024-08-13 10:21     ` Michael S. Tsirkin
2024-07-24 16:29 ` Daniel P. Berrangé
2024-08-02 15:57   ` Roy Hopkins
2024-08-02 16:03     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZqE3p79BWyyyJm0j@redhat.com \
    --to=berrange@redhat.com \
    --cc=alistair@alistair23.me \
    --cc=anisinha@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=jroedel@suse.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=roy.hopkins@suse.com \
    --cc=sgarzare@redhat.com \
    --cc=slp@redhat.com \
    --cc=thomas.lendacky@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.