[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 09/10] x86/ucode: Drop ucode_mod and ucode_blob
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 2 Nov 2024 13:14:17 -0400
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1730567660; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=BVRclYSW9tVf9nbPBcAG6zNkx0FUYxb3FvY6YhhGGP8=; b=FoNH+wPaaBjPfuirflMINjhXAe1lCkrBwXFimWp+Ks8brR1UimKE7dGmll+16Th+ka+ZF84bnFeptQGmcbqZhOEb4+pZ3f6ETr53Skvrn+c/0GEc15ClpS5iaeUBgk/Thx5NyaNvYkh8h4rpOr4vlZvA+XK1kagIBXO3cCMD02k=
- Arc-seal: i=1; a=rsa-sha256; t=1730567660; cv=none; d=zohomail.com; s=zohoarc; b=GEuGT4SWGAbGji9IA5xA2uVhMzH+olJ5F7VA+imKPCVlcgXlfpE5+iXf7PSO4Iifm6DpQp7q9ojFQSq5Xcvyfmf+iz5+e6N6coQcIqH7pAqu2erREgX8wOJn8zZboCEE2JQYRw279m/5OcbLcemk8txt7uadsa68z4s7csPs5x4=
- Cc: Jan Beulich <JBeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Sat, 02 Nov 2024 17:14:39 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10/28/24 05:18, Andrew Cooper wrote:
Both are used to pass information from early_microcode_load() to
microcode_init_cache(), and both constitute use-after-free's in certain cases.
* ucode_mod is a copy of the module_t identified by `ucode=$n`. Except it's
a copy from prior to Xen relocating the modules. microcode_init_cache()
might happen to find the data still intact in it's old location, but it
might be an arbitrary part of some other module.
* ucode_blob is a stashed pointer to a bootstrap_map() which becomes invalid
the moment control returns to __start_xen(), where other logic is free to
to make temporary mappings. This was even noticed and
microcode_init_cache() adjusted to "fix" the stashed pointers.
The information which should be passed between these two functions is which
module to look in. Introduce early_mod_idx for this purpose. opt_scan can be
reused to distinguish between CPIO archives and raw containers.
Notably this means microcode_init_cache() doesn't need to scan all modules any
more; we know exactly which one to look in. However, we do re-parse the CPIO
header for simplicity.
Furthermore, microcode_init_cache(), being a presmp_initcall does not need to
use bootstrap_map() to access modules; it can use mfn_to_virt() directly,
which avoids needing to funnel exit paths through bootstrap_unmap().
Fold microcode_scan_module() into what is now it's single caller. It operates
on the function-wide idx/data/size state which allows for a unified "found"
path irrespective of module selection method.
This resolves all issues to do with holding pointers (physical or virtual)
across returning to __start_xen().
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
CC: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
---
Reviewed-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
|
