From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mx.groups.io with SMTP id smtpd.web11.13649.1676395741525480204 for ; Tue, 14 Feb 2023 09:29:01 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=XaLwvRwR; spf=pass (domain: google.com, ip: 209.85.216.50, mailfrom: dionnaglaze@google.com) Received: by mail-pj1-f50.google.com with SMTP id bt4-20020a17090af00400b002341621377cso5256534pjb.2 for ; Tue, 14 Feb 2023 09:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y85NywFEezC7/80WUANZJDrM9NP6/s7axIzypm+E4XQ=; b=XaLwvRwRAG+ZvKyOlz+BLYRqD6RkPP9flvbIpEcI0+09R23nrfXv/6cssKLAXnQ97L 89fWvlKiNmQhBluq6So8nv3zCUnjy/Cl0B/uawE426xQiVKAqIgHbX5WuPo5kFB8iWgk 5uGu/ZC4PWtP0kvf6VJjuehxqzE/2h61tU/D5w8Or0kvLUYzyBEnuGnd5PPgJgKioN5U 54W7dX8+YQpd7uKJ2oLU0R8CqqeqlarHPxTcOZMzdoeapY/20sGgElHIvH+5gzzWsBy9 xXHbyYw+uppLupYyu1PLutVPp4UXCL00k9ScpYw8Sy70byGHxOa9Vk/L1h8gEAA3RFI+ BaYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y85NywFEezC7/80WUANZJDrM9NP6/s7axIzypm+E4XQ=; b=Po/k4oyaKSOOI6CVAzhhW7gIxQ5drE+nZ7EOwJaV5KZoDCKwjeTCfrXOwEmhYIjgze aq2yrAwS45wuxTRefLMec+qrNh2d6D5ojX+0BDq4waOc1Ia0ewl2QGYIw6MaRAjlbX2O Vob2z2avKHs0AhzzjaHXzdNqh+I1AsTQrFoiO1eufdgG1rjpjj05VqKGUXdqHmelqAIz +OA77CjTOo6fv3gVV/pMJ35S078afwd3xyKCsgaQZgu5G6yAO3GsRhu7VRzHGMPgYtan F8Gbom5hBJkX4D0fLV8pGsYdRsVtqIsWIJJ/4bFLmXjwgldhZsL+fo6F28vVJJVBDxUl nxGQ== X-Gm-Message-State: AO0yUKUXj8bmzfin9w4qn64Mo1qsqt5KGJxEuGYPZwoymyYvaMPh1U+e wkfJRDXsP4ncuW8spN+kp0g2wNlxgBSsm7MWMa6mLg== X-Google-Smtp-Source: AK7set9wAN++fDqo1XBs7vCwwCBrc1rURWyGQ6Py4n+ExWwKBrJJl4wFpsjM6Ggv6G8YOSJZ6adFD6Gbxtmf2aGDbps= X-Received: by 2002:a17:90a:bc95:b0:233:3c5a:b41b with SMTP id x21-20020a17090abc9500b002333c5ab41bmr29468pjr.133.1676395740757; Tue, 14 Feb 2023 09:29:00 -0800 (PST) MIME-Version: 1.0 References: <20230126005647.3019225-1-dionnaglaze@google.com> <20230126005647.3019225-2-dionnaglaze@google.com> <0d8f2b0b-1d62-3db6-34c9-e9ce39838bce@amd.com> <9ea61013-e2c1-30a4-3be7-feed537c035a@amd.com> <20230214091217.nrm5zmqyolawtn2b@sirius.home.kraxel.org> In-Reply-To: <20230214091217.nrm5zmqyolawtn2b@sirius.home.kraxel.org> From: "Dionna Glaze" Date: Tue, 14 Feb 2023 09:28:49 -0800 Message-ID: Subject: Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe To: Gerd Hoffmann Cc: "Gupta, Pankaj" , devel@edk2.groups.io, James Bottomley , Jiewen Yao , Tom Lendacky , Ard Biesheuvel , "Min M. Xu" , Andrew Fish , "Michael D. Kinney" , Oliver Steffen Content-Type: text/plain; charset="UTF-8" > > Do you have any pointers on the IVARS service? Documentation, guest > code, host code? > Agh, I thought for sure there was a public API for VM owners to view or change their UEFI variables, but I guess not. It's an instance-specific small data store for nonvolatile memory like vTPM and UEFI variables. It appears you can only set the variables through cloud API at instance creation time. But this is how instances can be shut down and brought back up on different machines and/or live migrate to other machines and still have access to UEFI variables' current values. Host code is all in Google's proprietary VMM, Vanadium, but the device backend is really rather simple. The data store service though, that's a matter of Cloud Scale Engineering. > Background: When moving to a SVSM-based setup where the svsm (with > vtpm emulation) runs in vmpl0 and the edk2 firmware in vmpl1 we might > likewise add a efi variable service to the svsm. > I thought EFI variables in Qemu were loaded and measured at launch (OVMF_VARS.fd). If you want the current values of all uefi variables in your SVSM attestation report, I think it's probably better to use the EFI_CC_MEASUREMENT_PROTOCOL, right? Or is it specifically going to be an SVSM service that attests itself with current stored variables, or at least variables that are considered important enough to measure? In any case, persistence in The Cloud (TM) remains a challenge in the CC space. Discussion about what we should do about that should remain on the coco mailing list. IVARS encrypts data with Google-managed keys, so it wouldn't be directly applicable to SVSM NVRAM. > If something usable already exists we don't need to reinvent the wheel. > Don't have to tell me twice. In the spirit of OSS collaboration and product integrity, I think any CC offering's firmware should be public and verifiably built. I'll keep pushing for that. > thanks & take care, > Gerd > -- -Dionna Glaze, PhD (she/her)