From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web12.5424.1583848103088263294 for ; Tue, 10 Mar 2020 06:48:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eKnKvDpI; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583848102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H1WJgF6Ou4kdaFJC3rNFTjRoAeDMxM0pi6KaNr6qZAw=; b=eKnKvDpIX8S5p7H1sBNE0+JrWlvA6CMbLH06kyN7Y0GVeMHUIlXXHYvJJQPj6+7aa8NAOk FInmjY1U/LF/fFtkru1zMA1f7LTmbJ8iUV7qdlJ+VVQ0w7O+9gwTeeY9S8Y+L7W7jkANBj K3Saz6EnA4LbYltM4H6QRPoe4m9t3Jo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-114-bdkMFFMdMC2mePsygQNzLg-1; Tue, 10 Mar 2020 09:48:17 -0400 X-MC-Unique: bdkMFFMdMC2mePsygQNzLg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A1E858017DF; Tue, 10 Mar 2020 13:48:16 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-246.ams2.redhat.com [10.36.116.246]) by smtp.corp.redhat.com (Postfix) with ESMTP id A898419C58; Tue, 10 Mar 2020 13:48:15 +0000 (UTC) Subject: Re: WSMT bits From: "Laszlo Ersek" To: Jiewen Yao Cc: edk2-devel-groups-io , Ray Ni References: Message-ID: <3c32815c-3ee9-261a-b473-1be341bdfb0c@redhat.com> Date: Tue, 10 Mar 2020 14:48:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi again Jiewen, On 03/10/20 10:36, Laszlo Ersek wrote: > Hi Jiewen, > > reading the following chapter: > > https://edk2-docs.gitbooks.io/a-tour-beyond-bios-memory-protection-in-uefi-bios/content/memory-protection-in-SMM.html > > I'm having trouble associating the protection features implemented in > edk2 with the various bits in the WSMT (per > "MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h"). > > For example, it seems like the bits a platform sets in the WSMT *might* > depend on "PcdCpuSmmRestrictedMemoryAccess". > > Can someone clarify these please? > > > FWIW, in the edk2-platforms tree, the > "Platform/Intel/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c" source > file sets EFI_WSMT_PROTECTION_FLAGS_FIXED_COMM_BUFFERS and > EFI_WSMT_PROTECTION_FLAGS_COMM_BUFFER_NESTED_PTR_PROTECTION. It does not > set EFI_WSMT_PROTECTION_FLAGS_SYSTEM_RESOURCE_PROTECTION. > > Is this bitmask (from Vlv2TbltDevicePkg) the general pattern that other > edk2 platforms with SMM support should expose too, as a starting point? I have now read another whitepaper from you: A Tour Beyond BIOS Secure SMM Communication in the EFI Developer Kit II It's a great whitepaper, it answers all my questions. Based on it, I think that OVMF should enable all three bits in the WSMT: (1) BIT0 -- FIXED_COMM_BUFFERS: (1.1) OVMF uses the standard edk2 SMM infrastructure. Drivers in that infrastructure verify that the communication buffers that they receive are in permitted regions (no overlap with SMRAM, and resident in permitted memory types), via SmmIsBufferOutsideSmmValid(). (1.2) OVMF contains only one custom SMI handler (which is for CPU hotplug). This handler does use normal RAM for a bit of communication with hot-added CPUs, but the RAM used for this purpose is allocated as reserved memory, and before End-of-Dxe. Furthermore, TOC-TOU is actively considered and mitigated, as the "communication area" is a single byte (a boolean flag), and the design considers the OS actively attacking that byte. (2) BIT1 -- COMM_BUFFER_NESTED_PTR_PROTECTION: OVMF uses the standard edk2 SMM infra, which validates the targets of nested pointers. The custom SMI handler (for CPU hotplug) does not process pointers that arrive from an untrusted context. (3) BIT2 -- SYSTEM_RESOURCE_PROTECTION: This bit is defined somewhat unclearly, but OVMF does lock both TSEG, and the QEMU-specific "SMRAM at default SMBASE", at SmmReadyToLock. See e.g. commit 9108fc17b09c ("OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE", 2020-02-05). So I think OVMF should install the WSMT, and set all three bits. However, there's a catch, for (1) FIXED_COMM_BUFFERS: (1.3) While OVMF produces a Memory Type Information HOB, it is not *adaptive*. I'm not sure what the whitepaper suggests: (1.3.1) that the HOB exist (because then released / unused BINs will never become usable memory in the final memory map), (1.3.2) or that BINs should actually accommodate all the allocations (so that no runtime memory is reallocated *ever*). Because, in the non-adaptive approach (1.3.1), what happens if there is a RuntimeData reallocation after End-of-Dxe, but even the *previous* allocation (that's now getting released) used to live outside of a BIN? Unfortunately, enabling the adaptive Memory Type Information (1.3.2) for OVMF is challenging, due to . OVMF can be booted with 128 MiB RAM and 1 TiB RAM just the same, and so a platform PEIM cannot tell, in advance, what is a valid Memory Type Information variable that the DXE core will accept, vs. an invalid Memory Type Information variable that the DXE core will reject (and hang upon, due to BIN priming failure). Thanks Laszlo