From patchwork Wed Oct 23 10:57:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13846913 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9659CDDE64 for ; Wed, 23 Oct 2024 10:58:26 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.824524.1238665 (Exim 4.92) (envelope-from ) id 1t3Z43-0000SL-Pl; Wed, 23 Oct 2024 10:58:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 824524.1238665; Wed, 23 Oct 2024 10:58:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3Z43-0000RQ-Kq; Wed, 23 Oct 2024 10:58:07 +0000 Received: by outflank-mailman (input) for mailman id 824524; Wed, 23 Oct 2024 10:58:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3Z42-0000Ow-Np for xen-devel@lists.xenproject.org; Wed, 23 Oct 2024 10:58:06 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ada6390a-912d-11ef-99a3-01e77a169b0f; Wed, 23 Oct 2024 12:58:04 +0200 (CEST) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5c9552d02e6so8441646a12.2 for ; Wed, 23 Oct 2024 03:58:04 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a91571e3asm462067266b.147.2024.10.23.03.58.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Oct 2024 03:58:02 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ada6390a-912d-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1729681083; x=1730285883; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PiZxguWTJ+3SGGRPO/U42i+dgE2giroEnnA16gZDT+E=; b=s4OgVZ/jlkzgse03D5AIgVo0muFxwE5V9Bm/sWLzl8UW5er4HgVbaJdPBkwj+B8meS y77qFkzbP6GEMpISWzzZT5yi7EtCWouPdXhvLIjVeoSs+zTu8a0w0tOVzD2Df8Igaz4p OGxr50OpH0Fr+qSz+6HWN7bkIX+TiwVGB51RI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729681083; x=1730285883; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PiZxguWTJ+3SGGRPO/U42i+dgE2giroEnnA16gZDT+E=; b=pT0x9BQPEFlFLmgm1X426/GexA5yCG9GOr8HQgiL89RSajQ6AY0eBdgoPA3aJRBV6C A+VETYmmBwEtHbdGVl+AWPTu8DtJPxbFVVekjZAhakNXyqhA/X37nIZY5ZUL/QlG7Eor AIbsyWewa0Fz/0I9KJOhPKYB86w7TEaAnmxBNd7jfXhU1DnY6CRSAU+YO6yGlHpdjiEA OfLQ97Ag9tloRQam3mzS1TgcCDzR3qcygSCkb8RVDwXEm41VkuLdQaIpqvDvFYD1w+lj vjF9ZWVugu7WERHm1dzzpMKOaxC85aDN3d0I4/Hd7IwJPteDcUdZREezpMfEGsstUkMs IopQ== X-Gm-Message-State: AOJu0YzYIRSuiFuNw/pB9ZZMaS0xenti2mOtcBtJeZm0t352HjNGGLyZ 4MOa/hFKA3Nnk3DCLhYLvoJJShxODM+GcLdIOl1YNRpzoHHLM7uL3Z0vceBwzuI+riO7buLMIPV n X-Google-Smtp-Source: AGHT+IFIsPAa9xnQjyqUO5z1QLm+iAT23rgeuuNu8jOjdEAWIoFppgJ0o4PiStlDqAVfIkqcIX3EZA== X-Received: by 2002:a17:907:9811:b0:a99:eb94:3e37 with SMTP id a640c23a62f3a-a9abf964492mr168095366b.58.1729681083050; Wed, 23 Oct 2024 03:58:03 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" Subject: [PATCH 1/3] x86/boot: Add a temporary module_map pointer to boot_image Date: Wed, 23 Oct 2024 11:57:54 +0100 Message-Id: <20241023105756.641695-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241023105756.641695-1-andrew.cooper3@citrix.com> References: <20241023105756.641695-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 ... in order to untangle parameter handling independently from other other logic changes. Signed-off-by: Andrew Cooper Reviewed-by: Daniel P. Smith CC: Roger Pau Monné CC: Daniel P. Smith --- xen/arch/x86/include/asm/bootinfo.h | 1 + xen/arch/x86/setup.c | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h index ffa443406747..6237da7e4d86 100644 --- a/xen/arch/x86/include/asm/bootinfo.h +++ b/xen/arch/x86/include/asm/bootinfo.h @@ -31,6 +31,7 @@ struct boot_info { size_t memmap_length; unsigned int nr_modules; + unsigned long *module_map; /* Temporary */ struct boot_module mods[MAX_NR_BOOTMODS + 1]; }; diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index c5b37bd2112e..d8001867c925 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1086,6 +1086,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) } bi = multiboot_fill_boot_info(mbi, mod); + bi->module_map = module_map; /* Temporary */ /* Parse the command-line options. */ if ( (kextra = strstr(bi->cmdline, " -- ")) != NULL ) From patchwork Wed Oct 23 10:57:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13846914 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C3529CDDE64 for ; Wed, 23 Oct 2024 10:58:35 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.824525.1238679 (Exim 4.92) (envelope-from ) id 1t3Z45-0000rb-VM; Wed, 23 Oct 2024 10:58:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 824525.1238679; Wed, 23 Oct 2024 10:58:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3Z45-0000rS-Rn; Wed, 23 Oct 2024 10:58:09 +0000 Received: by outflank-mailman (input) for mailman id 824525; Wed, 23 Oct 2024 10:58:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3Z43-0000Ow-Pw for xen-devel@lists.xenproject.org; Wed, 23 Oct 2024 10:58:07 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ae8928c7-912d-11ef-99a3-01e77a169b0f; Wed, 23 Oct 2024 12:58:06 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5c903f5bd0eso4136111a12.3 for ; Wed, 23 Oct 2024 03:58:06 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a91571e3asm462067266b.147.2024.10.23.03.58.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Oct 2024 03:58:03 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae8928c7-912d-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1729681085; x=1730285885; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=a8SPZF1bqa9Lk4OYKepi92x25hB7trhEWs2vbib+stU=; b=rKzP6aNekPT1RcD7Grp+I8wlneptF9Pvpxiqk9NDhctfpOednbGGwiGdUurbYpFujC DLgYAeM7t3bDNbrIk2D2vTB+zN5vqEKU7Xz1WVqzhUuZ4EOOvISYki3Byd+w/6FtdgxZ 7RmbXkxPQKy5HujHsy8thc7dl4HBAUbWI+t4Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729681085; x=1730285885; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a8SPZF1bqa9Lk4OYKepi92x25hB7trhEWs2vbib+stU=; b=QThtI+/Hgs0keBL/I1VMWQ20r7bMmRRPq0FGjzf2H4WcxZBFM2/Smqu1dHJzSjUXC2 7mEJs4iAMNN3zYt67sby+C7SLYyxOIjWRzukil880JXP3UHZfdc3NvIS/EE9yLlvCp3O z7ecux8GI7ejV/iYG34gXTkNguzwZgSxWjd1h0CD09B8ZfN8AdgtvacKn/JsXhb+N4sj b0lvAQoBVVrn9Bfam5/HXpl3A6tpzowGb8QN0VV70lWTHxcCunXdjAB5soriXfqIGrcE A7VTiwdNZctn1/cM+1feqfXIcIqhMFZ1a/5DsRnzMtgJRWU6WEvwVvQYNHrA/UDlPA6X U54w== X-Gm-Message-State: AOJu0YxqmYHqJFxyCkCHCXKOTtcFJMq1e7CeOEs0zlu7WJdJsw7Vy1NS hDS+Rn+WzA+tDzT+Vuzn2e8pPPKfGBIm6jX2tULDsKPHcQg5S1/eUkWGOvgGBzC0xASmyy6bYSn G X-Google-Smtp-Source: AGHT+IHmTNn0JVHgpbYVl+Y31smPoUXgo9AyjVpRj/G14FOate2Tlhsisc8tNZ2unCNQ/s/U0173Tg== X-Received: by 2002:a17:907:3dac:b0:a99:ce2f:b0ff with SMTP id a640c23a62f3a-a9abf8a4f1dmr207886566b.33.1729681085103; Wed, 23 Oct 2024 03:58:05 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: "Daniel P. Smith" , Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 2/3] x86/boot: Fix microcode module handling during PVH boot Date: Wed, 23 Oct 2024 11:57:55 +0100 Message-Id: <20241023105756.641695-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241023105756.641695-1-andrew.cooper3@citrix.com> References: <20241023105756.641695-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 From: "Daniel P. Smith" As detailed in commit 0fe607b2a144 ("x86/boot: Fix PVH boot during boot_info transition period"), the use of __va(mbi->mods_addr) constitutes a use-after-free on the PVH boot path. This pattern has been in use since before PVH support was added. Inside a PVH VM, it will go unnoticed as long as the microcode container parser doesn't choke on the random data it finds. The use within early_microcode_init() happens to be safe because it's prior to move_xen(). microcode_init_cache() is after move_xen(), and therefore unsafe. Plumb the boot_info pointer down, replacing module_map and mbi. Importantly, bi->mods[].mod is a safe way to access the module list during PVH boot. Note: microcode_scan_module() is still bogusly stashing a bootstrap_map()'d pointer in ucode_blob.data, which constitutes a different use-after-free, and only works in general because of a second bug. This is unrelated to PVH, and needs untangling differently. Signed-off-by: Daniel P. Smith Signed-off-by: Andrew Cooper Reviewed-by: Daniel P. Smith Acked-by: Roger Pau Monné --- CC: Jan Beulich CC: Roger Pau Monné CC: Daniel P. Smith Refectored/extracted from the hyperlaunch series. There's no good Fixes tag for this, because it can't reasonably be "introduce PVH", nor can the fix as-is reasonably be backported. If we want to fix the bug in older trees, we need to plumb the mod pointer down alongside mbi. --- xen/arch/x86/cpu/microcode/core.c | 40 +++++++++++----------------- xen/arch/x86/include/asm/microcode.h | 8 +++--- xen/arch/x86/setup.c | 4 +-- 3 files changed, 22 insertions(+), 30 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 8564e4d2c94c..1d58cb0f3bc1 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -35,6 +35,7 @@ #include #include +#include #include #include #include @@ -152,11 +153,8 @@ static int __init cf_check parse_ucode(const char *s) } custom_param("ucode", parse_ucode); -static void __init microcode_scan_module( - unsigned long *module_map, - const multiboot_info_t *mbi) +static void __init microcode_scan_module(struct boot_info *bi) { - module_t *mod = (module_t *)__va(mbi->mods_addr); uint64_t *_blob_start; unsigned long _blob_size; struct cpio_data cd; @@ -178,13 +176,13 @@ static void __init microcode_scan_module( /* * Try all modules and see whichever could be the microcode blob. */ - for ( i = 1 /* Ignore dom0 kernel */; i < mbi->mods_count; i++ ) + for ( i = 1 /* Ignore dom0 kernel */; i < bi->nr_modules; i++ ) { - if ( !test_bit(i, module_map) ) + if ( !test_bit(i, bi->module_map) ) continue; - _blob_start = bootstrap_map(&mod[i]); - _blob_size = mod[i].mod_end; + _blob_start = bootstrap_map(bi->mods[i].mod); + _blob_size = bi->mods[i].mod->mod_end; if ( !_blob_start ) { printk("Could not map multiboot module #%d (size: %ld)\n", @@ -204,21 +202,17 @@ static void __init microcode_scan_module( } } -static void __init microcode_grab_module( - unsigned long *module_map, - const multiboot_info_t *mbi) +static void __init microcode_grab_module(struct boot_info *bi) { - module_t *mod = (module_t *)__va(mbi->mods_addr); - if ( ucode_mod_idx < 0 ) - ucode_mod_idx += mbi->mods_count; - if ( ucode_mod_idx <= 0 || ucode_mod_idx >= mbi->mods_count || - !__test_and_clear_bit(ucode_mod_idx, module_map) ) + ucode_mod_idx += bi->nr_modules; + if ( ucode_mod_idx <= 0 || ucode_mod_idx >= bi->nr_modules || + !__test_and_clear_bit(ucode_mod_idx, bi->module_map) ) goto scan; - ucode_mod = mod[ucode_mod_idx]; + ucode_mod = *bi->mods[ucode_mod_idx].mod; scan: if ( ucode_scan ) - microcode_scan_module(module_map, mbi); + microcode_scan_module(bi); } static struct microcode_ops __ro_after_init ucode_ops; @@ -822,8 +816,7 @@ static int __init early_update_cache(const void *data, size_t len) return rc; } -int __init microcode_init_cache(unsigned long *module_map, - const struct multiboot_info *mbi) +int __init microcode_init_cache(struct boot_info *bi) { int rc = 0; @@ -832,7 +825,7 @@ int __init microcode_init_cache(unsigned long *module_map, if ( ucode_scan ) /* Need to rescan the modules because they might have been relocated */ - microcode_scan_module(module_map, mbi); + microcode_scan_module(bi); if ( ucode_mod.mod_end ) rc = early_update_cache(bootstrap_map(&ucode_mod), @@ -878,8 +871,7 @@ static int __init early_microcode_update_cpu(void) return microcode_update_cpu(patch, 0); } -int __init early_microcode_init(unsigned long *module_map, - const struct multiboot_info *mbi) +int __init early_microcode_init(struct boot_info *bi) { const struct cpuinfo_x86 *c = &boot_cpu_data; int rc = 0; @@ -922,7 +914,7 @@ int __init early_microcode_init(unsigned long *module_map, return -ENODEV; } - microcode_grab_module(module_map, mbi); + microcode_grab_module(bi); if ( ucode_mod.mod_end || ucode_blob.size ) rc = early_microcode_update_cpu(); diff --git a/xen/arch/x86/include/asm/microcode.h b/xen/arch/x86/include/asm/microcode.h index 57c08205d475..a278773f8b5d 100644 --- a/xen/arch/x86/include/asm/microcode.h +++ b/xen/arch/x86/include/asm/microcode.h @@ -24,10 +24,10 @@ DECLARE_PER_CPU(struct cpu_signature, cpu_sig); void microcode_set_module(unsigned int idx); int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len, unsigned int flags); -int early_microcode_init(unsigned long *module_map, - const struct multiboot_info *mbi); -int microcode_init_cache(unsigned long *module_map, - const struct multiboot_info *mbi); int microcode_update_one(void); +struct boot_info; +int early_microcode_init(struct boot_info *bi); +int microcode_init_cache(struct boot_info *bi); + #endif /* ASM_X86__MICROCODE_H */ diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index d8001867c925..c75b8f15fa5d 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1392,7 +1392,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) * TODO: load ucode earlier once multiboot modules become accessible * at an earlier stage. */ - early_microcode_init(module_map, mbi); + early_microcode_init(bi); if ( xen_phys_start ) { @@ -1936,7 +1936,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) timer_init(); - microcode_init_cache(module_map, mbi); /* Needs xmalloc() */ + microcode_init_cache(bi); /* Needs xmalloc() */ tsx_init(); /* Needs microcode. May change HLE/RTM feature bits. */ From patchwork Wed Oct 23 10:57:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13846916 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E81B2CDDE67 for ; Wed, 23 Oct 2024 10:58:43 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.824526.1238684 (Exim 4.92) (envelope-from ) id 1t3Z46-0000tz-6x; Wed, 23 Oct 2024 10:58:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 824526.1238684; Wed, 23 Oct 2024 10:58:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3Z46-0000tW-2T; Wed, 23 Oct 2024 10:58:10 +0000 Received: by outflank-mailman (input) for mailman id 824526; Wed, 23 Oct 2024 10:58:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3Z44-0000Oq-5p for xen-devel@lists.xenproject.org; Wed, 23 Oct 2024 10:58:08 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id af6f870f-912d-11ef-a0be-8be0dac302b0; Wed, 23 Oct 2024 12:58:07 +0200 (CEST) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5c941623a5aso1312582a12.0 for ; Wed, 23 Oct 2024 03:58:07 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a91571e3asm462067266b.147.2024.10.23.03.58.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Oct 2024 03:58:05 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af6f870f-912d-11ef-a0be-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1729681087; x=1730285887; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/Lb9ytF6JB17RhAg0W0RXGmRPpE1+HnU+Z6GNFh52Qc=; b=vP2NaT0lmx/1QnMhlXetG0LadCFhPbs14yJ5pSx21az9GeQHdgoE9bkGb0Hp4nzEgu f/yzmME6kvGSzTEu6wj2V5jYjcxJAHvoiGEJMJ8EaSXnOZMEop8BqDe6wWd0woTUk/ss SAqeGpNADObBbp5QSeF9juU4saNtuVteCAV74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729681087; x=1730285887; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/Lb9ytF6JB17RhAg0W0RXGmRPpE1+HnU+Z6GNFh52Qc=; b=PELRxoMV1IDlsIVYs2yN0277dAhIMotSQ7GQ5rD2mnICXFwxHAem+iV9tLCbPY+FA6 Kw94h4KiCwKvcB5pNVmNOujhzss2FgLUe0KM+w/l5auXNC/Ms6CiAmpWRwVXAEdspymF BQtz+joNVVzQJyDnzZ/dcKjyyCy/cWrYBEBYnthW4enUHVh6wqmlXUnGVU84KN9ExWeA lY2cdHzIHeDqbScFGCZdlPARVXrq7Pq6Gk694DcXu4OwQ/H4dL6kt+qArgD0EGFZ9bzR pwlSoO7WmxKi09QoCCTvu3m7l7xFKSvSlKHSaKTgfoxk08TczxTzC/E6yYoO0wZzbfri /edg== X-Gm-Message-State: AOJu0YyaZS9kpoFt5CYLQny4fXJub6OXrUPYczP4yIDZs0ewokGwNH1d fThoGTPIGCZes7xglsCZNrgNgPw0jq03SHRsE9Atbg6PncCv/glTrwZDP+Up3dx5ErBYsi+HLmT h X-Google-Smtp-Source: AGHT+IEJZI4upHZqGs4xzFVHTHSTqtsn6kBlDxFQY0Q6Ivu0fuFiQJyWFg7U8V0PMflWbAxcgL6UXw== X-Received: by 2002:a17:907:2d8e:b0:a9a:60b0:a8e7 with SMTP id a640c23a62f3a-a9abef2b5e2mr197241266b.2.1729681086499; Wed, 23 Oct 2024 03:58:06 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: "Daniel P. Smith" , Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 3/3] x86/boot: Fix XSM module handling during PVH boot Date: Wed, 23 Oct 2024 11:57:56 +0100 Message-Id: <20241023105756.641695-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241023105756.641695-1-andrew.cooper3@citrix.com> References: <20241023105756.641695-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 From: "Daniel P. Smith" As detailed in commit 0fe607b2a144 ("x86/boot: Fix PVH boot during boot_info transition period"), the use of __va(mbi->mods_addr) constitutes a use-after-free on the PVH boot path. This pattern has been in use since before PVH support was added. This has most likely gone unnoticed because no-one's tried using a detached Flask policy in a PVH VM before. Plumb the boot_info pointer down, replacing module_map and mbi. Importantly, bi->mods[].mod is a safe way to access the module list during PVH boot. As this is the final non-bi use of mbi in __start_xen(), make the pointer unusable once bi has been established, to prevent new uses creeping back in. This is a stopgap until mbi can be fully removed. Signed-off-by: Daniel P. Smith Signed-off-by: Andrew Cooper Reviewed-by: Daniel P. Smith Acked-by: Roger Pau Monné --- CC: Jan Beulich CC: Roger Pau Monné CC: Daniel P. Smith Refectored/extracted from the hyperlaunch series. There's no good Fixes tag for this, because it can't reasonably be "introduce PVH", nor can the fix as-is reasonably be backported. If we want to fix the bug in older trees, we need to plumb the mod pointer down alongside mbi. --- xen/arch/x86/setup.c | 5 ++++- xen/include/xsm/xsm.h | 12 +++++------- xen/xsm/xsm_core.c | 7 +++---- xen/xsm/xsm_policy.c | 16 +++++++--------- 4 files changed, 19 insertions(+), 21 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index c75b8f15fa5d..8974b0c6ede6 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1088,6 +1088,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) bi = multiboot_fill_boot_info(mbi, mod); bi->module_map = module_map; /* Temporary */ + /* Use bi-> instead */ +#define mbi DO_NOT_USE + /* Parse the command-line options. */ if ( (kextra = strstr(bi->cmdline, " -- ")) != NULL ) { @@ -1862,7 +1865,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", RANGESETF_prettyprint_hex); - xsm_multiboot_init(module_map, mbi); + xsm_multiboot_init(bi); /* * IOMMU-related ACPI table parsing may require some of the system domains diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index 627c0d2731af..4dbff9d866e0 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -17,7 +17,6 @@ #include #include -#include /* policy magic number (defined by XSM_MAGIC) */ typedef uint32_t xsm_magic_t; @@ -778,11 +777,10 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t) #endif /* XSM_NO_WRAPPERS */ #ifdef CONFIG_MULTIBOOT -int xsm_multiboot_init( - unsigned long *module_map, const multiboot_info_t *mbi); +struct boot_info; +int xsm_multiboot_init(struct boot_info *bi); int xsm_multiboot_policy_init( - unsigned long *module_map, const multiboot_info_t *mbi, - void **policy_buffer, size_t *policy_size); + struct boot_info *bi, void **policy_buffer, size_t *policy_size); #endif #ifdef CONFIG_HAS_DEVICE_TREE @@ -828,8 +826,8 @@ static const inline struct xsm_ops *silo_init(void) #include #ifdef CONFIG_MULTIBOOT -static inline int xsm_multiboot_init ( - unsigned long *module_map, const multiboot_info_t *mbi) +struct boot_info; +static inline int xsm_multiboot_init(struct boot_info *bi) { return 0; } diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c index eaa028109bde..6e3fac68c057 100644 --- a/xen/xsm/xsm_core.c +++ b/xen/xsm/xsm_core.c @@ -21,6 +21,7 @@ #ifdef CONFIG_XSM #ifdef CONFIG_MULTIBOOT +#include #include #endif @@ -139,8 +140,7 @@ static int __init xsm_core_init(const void *policy_buffer, size_t policy_size) } #ifdef CONFIG_MULTIBOOT -int __init xsm_multiboot_init( - unsigned long *module_map, const multiboot_info_t *mbi) +int __init xsm_multiboot_init(struct boot_info *bi) { int ret = 0; void *policy_buffer = NULL; @@ -150,8 +150,7 @@ int __init xsm_multiboot_init( if ( XSM_MAGIC ) { - ret = xsm_multiboot_policy_init(module_map, mbi, &policy_buffer, - &policy_size); + ret = xsm_multiboot_policy_init(bi, &policy_buffer, &policy_size); if ( ret ) { bootstrap_map(NULL); diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c index 8dafbc93810f..6f799dd28f5b 100644 --- a/xen/xsm/xsm_policy.c +++ b/xen/xsm/xsm_policy.c @@ -20,7 +20,7 @@ #include #ifdef CONFIG_MULTIBOOT -#include +#include #include #endif #include @@ -31,11 +31,9 @@ #ifdef CONFIG_MULTIBOOT int __init xsm_multiboot_policy_init( - unsigned long *module_map, const multiboot_info_t *mbi, - void **policy_buffer, size_t *policy_size) + struct boot_info *bi, void **policy_buffer, size_t *policy_size) { int i; - module_t *mod = (module_t *)__va(mbi->mods_addr); int rc = 0; u32 *_policy_start; unsigned long _policy_len; @@ -44,13 +42,13 @@ int __init xsm_multiboot_policy_init( * Try all modules and see whichever could be the binary policy. * Adjust module_map for the module that is the binary policy. */ - for ( i = mbi->mods_count-1; i >= 1; i-- ) + for ( i = bi->nr_modules - 1; i >= 1; i-- ) { - if ( !test_bit(i, module_map) ) + if ( !test_bit(i, bi->module_map) ) continue; - _policy_start = bootstrap_map(mod + i); - _policy_len = mod[i].mod_end; + _policy_start = bootstrap_map(bi->mods[i].mod); + _policy_len = bi->mods[i].mod->mod_end; if ( (xsm_magic_t)(*_policy_start) == XSM_MAGIC ) { @@ -60,7 +58,7 @@ int __init xsm_multiboot_policy_init( printk("Policy len %#lx, start at %p.\n", _policy_len,_policy_start); - __clear_bit(i, module_map); + __clear_bit(i, bi->module_map); break; } From patchwork Wed Oct 23 14:44:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13847184 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E5422CF5396 for ; Wed, 23 Oct 2024 14:45:13 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.824718.1238892 (Exim 4.92) (envelope-from ) id 1t3cbZ-0001Pz-Mn; Wed, 23 Oct 2024 14:44:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 824718.1238892; Wed, 23 Oct 2024 14:44:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3cbZ-0001Ps-K2; Wed, 23 Oct 2024 14:44:57 +0000 Received: by outflank-mailman (input) for mailman id 824718; Wed, 23 Oct 2024 14:44:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t3cbY-0001Pl-Fp for xen-devel@lists.xenproject.org; Wed, 23 Oct 2024 14:44:56 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5ca0e00d-914d-11ef-99a3-01e77a169b0f; Wed, 23 Oct 2024 16:44:52 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a9a16b310f5so886027166b.0 for ; Wed, 23 Oct 2024 07:44:52 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9a9159a231sm485756766b.210.2024.10.23.07.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Oct 2024 07:44:50 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ca0e00d-914d-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1729694691; x=1730299491; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Cv7BbkM+VyxuZiE18zNfLBSL+qc31CadlEw9GXWIkw0=; b=quh+bahj7UU8IoYpzZtgGJQQz1Hxc02QwujUqZmSgR8TKzJK2U7PImXejiHv0ow5z1 mDqkSvpcs43985wmB+fLBZVB4BSDcCEBeHMlEezELjnUzDyRLSWTNc0XQTenWsRS2745 3EnS2pOCVRMKirkc9mZGdQsFndAirKSxs2w60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729694691; x=1730299491; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Cv7BbkM+VyxuZiE18zNfLBSL+qc31CadlEw9GXWIkw0=; b=I3P4PrB+08fpY307KMdqFFfR9rmiUZeM9QpzvtyCachvW6f+VInGVWz1xNanC+Ku5Y vNpBgJFXyPE3gcRhCK1VfA+j40LND2MQtKC1xF0eO+d96iGuG93VJY801k6CFroxTlkL 1Lr3e0HFMqNvOptlxcbaNssYWxc9fuX2CIa7YMXY5jT9Au7rtPYmhkToYS/L858daWn8 uyi4xadNZQJxBboD5TxEHsNQUPQuopxW6BX4r1pnrp8/j//YX66TMHGDAUByRMoiOQoK EPTzVW8o+gDcM3GKiI8ipIBIp49afht/3OaFcU/kMSZv1uwC9rcTH+lA9oAd7Vr7Tt/m 64vA== X-Gm-Message-State: AOJu0Yxk3UHXf39V0Df6+/dwxMgbzb8vVR9mmCJPjYM4R5BXAPONvXVP qxrnVxHNAY54mOaflXPzW827gh2GPiAQafSYn3GaHD7STjHYV2sv5UiDIVNAXEIAUwe4D/jUDHm K X-Google-Smtp-Source: AGHT+IGCS+qrW5WCJrlrmPw8TwvM4/GKq/U1g8u3zg/oeKOXN9F6nTzw21pt1hi0F3/5TKiboKWIlA== X-Received: by 2002:a17:907:944c:b0:a99:f9e6:1d0 with SMTP id a640c23a62f3a-a9abf8b7bc1mr269118366b.27.1729694691431; Wed, 23 Oct 2024 07:44:51 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , =?utf-8?q?Marek_Ma?= =?utf-8?q?rczykowski-G=C3=B3recki?= , "Daniel P . Smith" Subject: [PATCH 4/3] x86/boot: Remove the mbi_p parameter from __start_xen() Date: Wed, 23 Oct 2024 15:44:48 +0100 Message-Id: <20241023144448.731688-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241023105756.641695-1-andrew.cooper3@citrix.com> References: <20241023105756.641695-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 The use of physical addresses in __start_xen() has proved to be fertile soure of bugs. The MB1/2 path stashes the MBI pointer in multiboot_ptr (a setup.c variable even), then re-loads it immediately before calling __start_xen(). For this, we can just drop the function parameter and read multiboot_ptr in the one place it's used. The EFI path also passes this parameter into __start_xen(). Have the EFI path set up multiboot_ptr too, and move the explanation of phyiscal-mode pointers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Daniel P. Smith Reviewed-by: Daniel P. Smith --- CC: Jan Beulich CC: Roger Pau Monné CC: Marek Marczykowski-Górecki CC: Daniel P. Smith https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1509072662 --- xen/arch/x86/boot/x86_64.S | 2 -- xen/arch/x86/efi/efi-boot.h | 9 +++++++-- xen/arch/x86/include/asm/setup.h | 1 + xen/arch/x86/setup.c | 14 +++++--------- 4 files changed, 13 insertions(+), 13 deletions(-) base-commit: be84e7fe58b51f6b6dd907a038f0ef998a1e281e prerequisite-patch-id: 795f6e9425cc6a953166b530ae68df466a7a3c2b diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S index 04bb62ae8680..26b9d1c2df9a 100644 --- a/xen/arch/x86/boot/x86_64.S +++ b/xen/arch/x86/boot/x86_64.S @@ -77,8 +77,6 @@ ENTRY(__high_start) tailcall start_secondary .L_bsp: - /* Pass off the Multiboot info structure to C land (if applicable). */ - mov multiboot_ptr(%rip),%edi tailcall __start_xen .section .data.page_aligned, "aw", @progbits diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 94f34433640f..3b26f0b0f500 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -248,6 +248,12 @@ static void __init noreturn efi_arch_post_exit_boot(void) efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start); memcpy((void *)trampoline_phys, trampoline_start, cfg.size); + /* + * We're in physical mode right now (i.e. identity map), so a regular + * pointer is also a phyiscal address to the rest of Xen. + */ + multiboot_ptr = (unsigned long)&mbi; + /* Set system registers and transfer control. */ asm volatile("pushq $0\n\tpopfq"); rdmsrl(MSR_EFER, efer); @@ -279,8 +285,7 @@ static void __init noreturn efi_arch_post_exit_boot(void) [cr4] "+&r" (cr4) : [cr3] "r" (idle_pg_table), [cs] "i" (__HYPERVISOR_CS), - [ds] "r" (__HYPERVISOR_DS), - "D" (&mbi) + [ds] "r" (__HYPERVISOR_DS) : "memory" ); unreachable(); } diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h index 3d189521189d..811855e57478 100644 --- a/xen/arch/x86/include/asm/setup.h +++ b/xen/arch/x86/include/asm/setup.h @@ -14,6 +14,7 @@ extern unsigned long xenheap_initial_phys_start; extern uint64_t boot_tsc_stamp; extern void *stack_start; +extern unsigned int multiboot_ptr; void early_cpu_init(bool verbose); void early_time_init(void); diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index c5b37bd2112e..c9129c21787b 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -157,8 +157,8 @@ char asmlinkage __section(".init.bss.stack_aligned") __aligned(STACK_SIZE) /* Used by the BSP/AP paths to find the higher half stack mapping to use. */ void *stack_start = cpu0_stack + STACK_SIZE - sizeof(struct cpu_info); -/* Used by the boot asm to stash the relocated multiboot info pointer. */ -unsigned int asmlinkage __initdata multiboot_ptr; +/* Used by the boot asm and EFI to stash the multiboot_info paddr. */ +unsigned int __initdata multiboot_ptr; struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 }; @@ -1014,7 +1014,7 @@ static struct domain *__init create_dom0(const module_t *image, /* How much of the directmap is prebuilt at compile time. */ #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) -void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) +void asmlinkage __init noreturn __start_xen(void) { const char *memmap_type = NULL; char *kextra; @@ -1059,7 +1059,6 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) if ( pvh_boot ) { - ASSERT(mbi_p == 0); pvh_init(&mbi, &mod); /* * mbi and mod are regular pointers to .initdata. These remain valid @@ -1068,7 +1067,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) } else { - mbi = __va(mbi_p); + mbi = __va(multiboot_ptr); mod = __va(mbi->mods_addr); /* @@ -1078,11 +1077,8 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) * For EFI, these are directmap pointers into the Xen image. They do * not remain valid across move_xen(). EFI boot only functions * because a non-zero xen_phys_start inhibits move_xen(). - * - * Don't be fooled by efi_arch_post_exit_boot() passing "D" (&mbi). - * This is a EFI physical-mode (i.e. identity map) pointer. */ - ASSERT(mbi_p < MB(1) || xen_phys_start); + ASSERT(multiboot_ptr < MB(1) || xen_phys_start); } bi = multiboot_fill_boot_info(mbi, mod);