From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) by mx.groups.io with SMTP id smtpd.web10.73511.1673568885226810546 for ; Thu, 12 Jan 2023 16:14:45 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=kWf47Svp; spf=pass (domain: flex--dionnaglaze.bounces.google.com, ip: 209.85.215.201, mailfrom: 3c6laywskbd4dionnaglazegoogle.comdeveledkc.groups.io@flex--dionnaglaze.bounces.google.com) Received: by mail-pg1-f201.google.com with SMTP id g31-20020a63111f000000b004bbc748ca63so1846483pgl.3 for ; Thu, 12 Jan 2023 16:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=lq7jk88mOpP1h1lm0ive48lH0K3AA63H3BIhXgp+5Vk=; b=kWf47SvpBiMDBBsWjifFwS7uYft5FtK1e/UUlXpMo/GSAnkGjdU5AQCystcyK6S+3S pUD/XIUdHZAA+PD1cCC2pYSIqQ0YLr7GH0Tj8vtWjK4fUFrJVOcsndaeeELXKmxt8WB7 3fI+419odIajd+upS7nRDSBUBF+MM/pOfekJMp2fy90X2tIhb0VjG69aM40NXekKnN+8 CsZExim7OwAy5Akda7RrFUPHrMOFdchLfMJL6HaDnBHq1RDy2raL7gKUWxKzol45KwKc eN4ItNisxe4yWBBZSXXbCfkKDVVhv5i7l21UbvATNb/uSwpsRzJdCu+hVbuD/AsncPff WwBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lq7jk88mOpP1h1lm0ive48lH0K3AA63H3BIhXgp+5Vk=; b=k5suqsX8YTCLF0oc9722NCrxAzUyjsY3QAh08WlhWr6NCMuWTmVou6WugZz+YmOt+g 8xpCuqW8GcFaPp5E2keI/s4sGSaHwMXhc7+mL+AAUWnOcxP5ldEegn93zdtzYOaC6eEN EOy1xEPpQ/AsfmoR4WmLvy9FwtXKKz+5SxxI1NcGkKtHy0bFxJbzW1saVlmY0b30de8v dXI1+R0KCKgB9pqyu+UvudbpdjmrzxM+5cCJgIVIGIcvDPAsMsoIlT2KmsnIGwJ1ilCl SvjC+rDD5Ev0OA/HPxPNqf3OGlNJMHeONelnY54m4ZOycSlnHrwSmb7Vn+Wz7eqRdhMm fPZQ== X-Gm-Message-State: AFqh2kqQBMWbPTRKa216eZrNosUAzX+dEefXe2s8MkbRJunyLhvh2sZQ octSY53ToFJW6+zbIKxK72tubtoHGjnUP1LAq057uyHE+laYps+mmsKx5KIdrlW7OUMrYXp5OvH kPH67rl84e7qBQ+SdK7vw+bOLxuqvLsCeFMPptNYYBZ30uFGxFkP6WVOepn8pCSlhKzcntILj X-Google-Smtp-Source: AMrXdXuu9B5Fr7J2WReZzFuzTinDzAoYJglQp3pu9MY1rBrLzZbiBgjBzQfgEkPsEkHSTVSdZLmBPCDkB6TCugfxEQ== X-Received: from dionnaglaze.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2ee6]) (user=dionnaglaze job=sendgmr) by 2002:a17:90a:206:b0:226:9980:67f3 with SMTP id c6-20020a17090a020600b00226998067f3mr131352pjc.1.1673568883365; Thu, 12 Jan 2023 16:14:43 -0800 (PST) Date: Fri, 13 Jan 2023 00:14:15 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230113001419.2519031-1-dionnaglaze@google.com> Subject: [PATCH v9 0/4] Add safe unaccepted memory behavior From: "Dionna Glaze" To: devel@edk2.groups.io Cc: Dionna Glaze , Ard Biescheuvel , "Min M. Xu" , Gerd Hoffmann , James Bottomley , Tom Lendacky , Jiewen Yao , Erdem Aktas , Andrew Fish , "Michael D. Kinney" Content-Type: text/plain; charset="UTF-8" We make eager memory acceptance the default behavior at ExitBootServices by using the standard-enforced behavior that if the call returns an error code, then the map key is incorrect and the caller must re-call GetMemoryMap to ensure the contents are correct. Eager memory acceptance is implemented by using the UEFI v2.9-added EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES to check a support condition before changing all unaccepted memory type regions to conventional memory after first using the MemoryAccept protocol to accept all memory in each region. This update to the memory map only happens once, since there are no extra unaccepted memory regions to change on the forced second call to ExitBootServices. The new acceptance logic is technology-agnostic and usable across TEE technologies, so this patch series introduces a Confidenial Compute DXE driver called CocoDxe. To allow the OS loader to prevent the eager acceptance, and thus pass the before-mentioned "support condition", we add a new protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. This protocol has one interface, Disable(). The OS loader can inform the UEFI that it supports the unaccepted memory type and accepts the responsibility to accept it. The MemoryAcceptance protocol is necessary for safe rollout of the unaccepted memory type, given the gradual update of guest OS kernels. OVMF cannot rely on the following implication (MemEncryptSevIsEnabled () || MemEncryptTdxIsEnabled ()) implies unaccepted memory is supported by the guest This implication does not hold for e.g., upstream Linux, and will not hold generally since both SEV-SNP and TDX define unaccepted memory support as optional rather than required. All images that support unaccepted memory must now locate and call this new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the Disable function. Changes since v8: - First 3 patches removed since they were submitted separately. - Later patches rebased on edk2/master and modified to work with the current locations and namings of the unaccepted memory constants. Changes since v7: - Rebased onto lazy accept v4 patch series, so memory accept protocol has the EDKII prefix, and the unaccepted memory type has the BZ3937 prefix. - Removed a bad #include to a header removed in v7. - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL as per the discussion on the buganizer issue. - Uncrustify formatting Changes since v6: - Added implementation of EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. - Changed callback protocol of v5 to instead use the standardized event group for before_exit_boot_services. Changes since v5: - Generic callback protocol moved to MdeModulePkg - Removed use of EFI_WARN_STALE_DATA and added comment that the callback should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. - Removed errant log statement and fixed formatting. Changes since v4: - Commit message wording - Replaced direct change to DxeMain with a more generic callback protocol. - Implemented the direct change as an instance of the callback protocol from a new CocoDxe driver. - Replaced "enable" protocol with a "disable" protocol, since the name was confusing. The AcceptAllUnacceptedMemory protocol directly names the behavior that is disabling. Changes since v3: - "DxeMain accepts all memory" patch split into 3 to make each patch affect only one package at a time. Changes since v2: - Removed the redundant memory accept interface and added the accept behavior to the DXE implementation of MemEncryptSevSnpPreValidateSystemRam. - Fixed missing #include in >=4GB patch. Changes since v1: - Added a patch to classify SEV-SNP memory above 4GB unaccepted. - Fixed style problems in EfiMemoryAcceptProtocol implementation. Cc: Ard Biescheuvel Cc: "Min M. Xu" Cc: Gerd Hoffmann Cc: James Bottomley Cc: Tom Lendacky Cc: Jiewen Yao Cc: Erdem Aktas Cc: Andrew Fish Cc: "Michael D. Kinney" Signed-off-by: Dionna Glaze Dionna Glaze (4): OvmfPkg: Introduce CocoDxe driver MdePkg: Introduce the MemoryAcceptance protocol OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted MdePkg/Include/Protocol/MemoryAcceptance.h | 40 +++++ MdePkg/MdePkg.dec | 3 + OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + OvmfPkg/CocoDxe/CocoDxe.c | 175 +++++++++++++++++++++ OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + OvmfPkg/PlatformPei/AmdSev.c | 5 + 13 files changed, 277 insertions(+) create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf -- 2.39.0.314.g84b9a713c41-goog