[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Tue, 19 Mar 2024 09:50:37 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- 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=YxZJ1cpPIu3+aUkREpmAJNKOP0nGyjhxGXKT5XyKIWE=; b=DVndPCYxVHL+42N2fKvphUXgiNNTI4pEuvLOmpjUIhaWgOCO/FM5fVrXsZ4kAczdSmjafeJau32lP51fmoX+17WXV++LHNHkLH42vhH1XIJ43Co2XU6feQIzqtbnk5iPq7obE0Qi/Wkjzqp3uDkJKVzoX+WG7owwskuw/XaK6/mBczp3+/5TgdVWk614Myk3IIzTPSuqrP4fDxWD2ox5nu9GqnhoWdAYhvoHyN7AW3rx0P0GB5hRUSlS8zpbGrdopWbDDsJQJ1d97Mtmc6nnbP+FnhHppqKO6u7HHRbOCjkIM47h0dPGZA8QLD4Iyvx6I6p8jwgOq3qWugXDNQfYHw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ksMnGQoHXRuTd7VJE8kSr1LiGxTbIncU0NG4Wj1YWvLtjgaFIO9kT4etf8yTzn7L2Z+tYxISa0Zb8DLy7KJQfRes2QHp4ShTMEEushJfOLTi+YSbLaJohjkPoMBsnZ20qxj6LGAYlTV7r/mwRrvQmIt3k8gFled8g/ogcSvWIJ2OCDal0SlcZjcvY2RAlavgJjvOuL2oL4T+XCgwDY/gd9c2K8AQziHodgaleWaGuPQ8kRGlrqyc85iCGAUW2FmCS/6nOaT8BgBSbAM95YCHCZFoj4ebKLRDigggmscuRh3UkR/MtOfEhCInQWCjn9ebDSdtYETOtF9cB/Eo68gDMQ==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 19 Mar 2024 13:51:06 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2024-03-19 04:15, Jan Beulich wrote:
On 18.03.2024 22:21, Jason Andryuk wrote:
On 2024-03-15 05:48, Jan Beulich wrote:
On 14.03.2024 20:19, Jason Andryuk wrote:
On 2024-03-14 09:31, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,108 @@ static paddr_t __init find_memory(
return INVALID_PADDR;
}
+static bool __init check_load_address(
+ const struct domain *d, const struct elf_binary *elf)
+{
+ paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
+ paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
Both casts act on a pointer value. Such cannot legitimately be converted
to paddr_t; it only so happens that paddr_t is effectively the same as
uintptr_t right now. (Same issue again further down.) That said, I notice
we have pre-existing examples of this ...
Yes, I followed existing code. Do you want dest_base to be switched to
a uintptr_t?
I think it was deliberately switched to being a pointer at some point,
maybe even in a security fix.
commit 65808a8ed41cc7c044f588bd6cab5af0fdc0e029 "libelf: check all
pointer accesses", part of XSA-55, switched from a single dest pointer
to dest_base & dest_size.
For libxenguest, it's a pointer to guest-mapped memory to copy in the
kernel. For PV dom0 creation, it's a pointer - Xen switches to the dom0
page tables and performs the copy with it as-is. For PVH dom0, it's a
guest physical address.
Are you looking for this to be addressed in this series?
I'm sorry to ask, but what is "this" here? I'd like your change to leave
all types alone. I'd further like your change to preferably avoid cloning
questionable code (i.e. casts using the wrong type in particular). Plus,
where technically possible, adhere to the general principle of avoiding
casts (for typically being at least somewhat risky towards hiding
potential bugs).
I intended "this" to refer to changing dest_base's type. I won't do
that. With some of your other suggestions, most castings are gone.
Thanks,
Jason
|
