[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered


  • To: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 30 Sep 2022 08:44:21 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ig5/f9yGkJ9lGAtU8YAhY4+anw7sGzZbBu/lcG43jwk=; b=cgHtxCOIMcQ+1xKN/dfS27i4LCeSxos2wF+ome7jtPjd2CiAYKQm9aVX6Tvv6BJqPZBGeNUGRWOIqG2amb1BAmenee2ZNa3CbmiX+rUvunzbJ2eV3eFptTETX4v3xIFBNzZ2r0LmqBwa0cSK7A2oh6oCbhTAl2lqIMpAbnsUPC12uwxS9TZJvshSXdYyzXD7tdEiYxgECf0nxq/KoMfaW24b3GCbYokSeNpHZhJP7Nkg3O7AioVAGhqMSjlkW4/VDB3qfO4zY4bBIKFOGXCgcYDKUK5QFtX8tRSHNYLcKqiNeB8PuKwC5kve2piWWES3oK8VKC/epjPyGgaOd0TCEg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aMhftuYmIpZd2kcU82FdL1vpqKzb+hHWeXh/AJsbK4XyDn3QBsdBqIC/F0x2Voei2EWL7ta9Fc2cUaWLUzySBm4o2HSKO9rL8MtX9fbFgO6lpdW+qXUV2XJqq7gycrlAAV6EwHMCiJiFvUbquICRMgfP9JV7fBe7NPBMjYRCTAnjVewFiR7/1FKgFGHGFLA+XTbDW0fLDRg3RSX7OwZRpwY/mCaM4WSEWoKBHAC6wVJePaPFvAf/knCZJpzNB3fJfQ6gmyEsCyh/tQGNpvnZ4vX8F5oVNoL0p/yT+NjBbwvfus8QG6oeUjpf5sdPILGuyYk2gN8GsHMmbZEoEJrvDA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-efi@xxxxxxxxxxxxxxx, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Ard Biesheuvel <ardb@xxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, Anton Vorontsov <anton@xxxxxxxxxx>, Colin Cross <ccross@xxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 30 Sep 2022 06:44:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.09.2022 01:02, Demi Marie Obenour wrote:
> Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> Xen before Linux gets to start using it.  Therefore, Linux under Xen
> must not use EFI tables from such memory.  Most of the remaining EFI
> memory types are not suitable for EFI tables, leaving only
> EFI_ACPI_RECLAIM_MEMORY, EFI_RUNTIME_SERVICES_DATA, and
> EFI_RUNTIME_SERVICES_CODE.  When running under Xen, Linux should only
> use tables that are located in one of these types of memory.
> 
> This patch ensures this, and also adds a function
> (xen_config_table_memory_region_max()) that will be used later to
> replace the usage of the EFI memory map in esrt.c when running under
> Xen.  This function can also be used in mokvar-table.c and efi-bgrt.c,
> but I have not implemented this.
> 
> Signed-off-by: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>

In Xen we don't clobber EfiBootServices{Code,Data} when xen.efi was passed
"-mapbs". Should we perhaps extend the interface such that Dom0 can then
also use tables located in such regions, perhaps by faking
EFI_MEMORY_RUNTIME in the attributes returned by XEN_FW_EFI_MEM_INFO?

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.