[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: Wed, 5 Oct 2022 08:15:07 +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=/SXlFQl4ElpS1x8Q77iosu7H/vrhFX98uDhyfXvAEh8=; b=WWpbK2bCGpaPfEQGBL7HZWLEuGr4TgHQG8MVDHUFX6zxJll2wde/Civlb4nQsZ8jd84nSgxnCGxBL4GmoSMB+MZPCrfkRbxIcfRgQPWcFl0KAnuTuHKichJEJZYupTiyWbThjFbdvA6/kkR8Y/ERthXSUHmji6oWe4RlAD9f5/W//P8Xs25CGfQZvTQEMfQ1MjqqLx+yFKc13D4oou4mswhPGSuS4JKSrdFZS3r3h2X2CdDR7Dk60EIKucTqA+Gz7NuvCbjU+sZVPJU4hEhE9M8KZykStRfSzwV9f+aITh+g/r6Ib0vnHK2lW0JSmVYju0EOwb/vJ46Wvg/xcidWmA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KXP9lYxsmpdTgO3rr/vm4vGzNyUAddXFrZyUejpfne0Zu8buOZkr5uDg48bt0kfSjTaCazWnBzPd76vjqwoqqD3t5f1coTGmUTuGyJjs13mGNnVA0xjq2jrp7QccKnONhzW9tHlIScy6/JZJ27mr9I68+QXQ3cWrMcVnpfrHeYnJWfzNVvxAEcmJhJpFCPKBmrdQlxhetOcr0LAcrsoXNXTr7l9d5kNET7Yp9cFo/BjJcqjP6Jpqp/WCPucL5MwMXWADkD8sBPv9NMn0BP0rVocjnXj5W7XoEDzPQiOC/WJiAAG3hZYtBDJ3dTkpZLsTIA1MEF7yEpumR09HQPmXog==
- 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>, Kees Cook <keescook@xxxxxxxxxxxx>, Anton Vorontsov <anton@xxxxxxxxxx>, Colin Cross <ccross@xxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Ard Biesheuvel <ardb@xxxxxxxxxx>
- Delivery-date: Wed, 05 Oct 2022 06:15:31 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 04.10.2022 17:46, Demi Marie Obenour wrote:
> Linux has a function called efi_mem_reserve() that is used to reserve
> EfiBootServicesData memory that contains e.g. EFI configuration tables.
> This function does not work under Xen because Xen could have already
> clobbered the memory. efi_mem_reserve() not working is the whole reason
> for this thread, as it prevents EFI tables that are in
> EfiBootServicesData from being used under Xen.
>
> A much nicer approach would be for Xen to reserve boot services memory
> unconditionally, but provide a hypercall that dom0 could used to free
> the parts of EfiBootServicesData memory that are no longer needed. This
> would allow efi_mem_reserve() to work normally.
efi_mem_reserve() actually working would be a layering violation;
controlling the EFI memory map is entirely Xen's job.
As to the hypercall you suggest - I wouldn't mind its addition, but only
for the case when -mapbs is used. As I've indicated before, I'm of the
opinion that default behavior should be matching the intentions of the
spec, and the intention of EfiBootServices* is for the space to be
reclaimed. Plus I'm sure you realize there's a caveat with Dom0 using
that hypercall: It might use it for regions where data lives which it
wouldn't care about itself, but which an eventual kexec-ed (or alike)
entity would later want to consume. Code/data potentially usable by
_anyone_ between two resets of the system cannot legitimately be freed
(and hence imo is wrong to live in EfiBootServices* regions). In a way
one could view the Dom0 kernel as an "or alike" entity ...
Jan
|
