* Xen Security Advisory 372 v3 (CVE-2021-28693) - xen/arm: Boot modules are not scrubbed
@ 2021-06-08 17:04 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2021-06-08 17:04 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 4236 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2021-28693 / XSA-372
version 3
xen/arm: Boot modules are not scrubbed
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
The bootloader will load boot modules (e.g. kernel, initramfs...) in a
temporary area before they are copied by Xen to each domain memory.
To ensure sensitive data is not leaked from the modules, Xen must
"scrub" them before handing the page over to the allocator.
Unfortunately, it was discovered that modules will not be scrubbed on
Arm.
IMPACT
======
Sensitive information from the boot modules might be visible to another
domain after boot.
VULNERABLE SYSTEMS
==================
Only Arm systems are vulnerable. System running with "bootscrub=off"
(disabling boot scrubbing) are not vulnerable.
All versions of Xen since 4.12 are vulnerable.
MITIGATION
==========
There is no mitigation available.
CREDITS
=======
This issue was discovered by Julien Grall of Amazon.
RESOLUTION
==========
Applying the appropriate set of attached patches resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa372/*.patch xen-unstable
xsa372-4.15/*.patch Xen 4.15.x
xsa372-4.14/*.patch Xen 4.14.x - Xen 4.13.x
xsa372-4.12/*.patch Xen 4.12.x
$ sha256sum xsa372* xsa372*/*
06e43684c2d8a3085d55b8b40f57e1b9f1ee47519fac844dcbc21b57fb039915 xsa372.meta
8f872c7abe6c795dbef2e401f2223fda0dbb9d7c57dfebd8047eef37e1caf952 xsa372-4.12/0001-xen-arm-Create-dom0less-domUs-earlier.patch
a43c6c11481cc3f13900908cee79cc6c5401921f6f4e8858c0796cf301cfe923 xsa372-4.12/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
6d1fad53795ebd251520022b6be901215426ba78ccbbc075841698973b74d2a2 xsa372-4.14/0001-xen-arm-Create-dom0less-domUs-earlier.patch
2ceb5d4d8d4f8a18046721daa3bb29633a620c4794b54e1265f5d4d69a314c3b xsa372-4.14/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
7feae5f9f7f2df0ec38c0b9358dc32671a9955f966b3120e17bb3fd820ce33ff xsa372-4.15/0001-xen-arm-Create-dom0less-domUs-earlier.patch
0cc73b4751fa49f68c6584b1c7882606c6e1f18561d8a6547017ab068de4eb4b xsa372-4.15/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
950672405c695ebf6ae59eebeb454bc0738b7afc3efa35ef9680d76eef4d4ec0 xsa372/0001-xen-arm-Create-dom0less-domUs-earlier.patch
9ceccd39c795e7756052a2f00256e043c8dda42e2c691df30e3f8b59190d6e8e xsa372/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmC/oxIMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZmdYIAMlZ2woM1hnb97BytpKkRM3v8AnyP4xhm29OoVI+
eaclrapZBPxi8qxv0+fxhe/2/t9gf98miEJftI8VRz5btiStmsgIjlEXUGpC6iwE
u7HmLzu7QBX7r2FzpSTFnVVdbFwXCU3scYuO4qM8frCpxH4kevSSxPrT5E/oFVvA
Y83ux8aKg041WTVQvK0gEVA7CgRVoxmbiYeag2JIaRGt8WnEKprbmGWQ5+DYq+pr
8tsLppHtyxppqSa7d6L67xdiNoRqAacfIezNFTpSIdyfS1m0QIIAJTr6Bg7Fd6zi
F2AYcoZiNO53OSnobH3c64axIc5iBINZeXisVMnTDzKU3XE=
=eQ/r
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa372.meta --]
[-- Type: application/octet-stream, Size: 1331 bytes --]
{
"XSA": 372,
"SupportedVersions": [
"master",
"4.15",
"4.14",
"4.13",
"4.12"
],
"Trees": [
"xen"
],
"Recipes": {
"4.12": {
"Recipes": {
"xen": {
"StableRef": "5984905b2638df87a0262d1ee91f0a6e14a86df6",
"Prereqs": [],
"Patches": [
"xsa372-4.12/*.patch"
]
}
}
},
"4.13": {
"Recipes": {
"xen": {
"StableRef": "284132938900ce8c3b11babf7255f5c6dbb21716",
"Prereqs": [],
"Patches": [
"xsa372-4.14/*.patch"
]
}
}
},
"4.14": {
"Recipes": {
"xen": {
"StableRef": "10f0b2d49376865d49680f06c52b451fabce3bb5",
"Prereqs": [],
"Patches": [
"xsa372-4.14/*.patch"
]
}
}
},
"4.15": {
"Recipes": {
"xen": {
"StableRef": "280d472f4fca070a10377e318d90cabfc2540810",
"Prereqs": [],
"Patches": [
"xsa372-4.15/*.patch"
]
}
}
},
"master": {
"Recipes": {
"xen": {
"StableRef": "aa77acc28098d04945af998f3fc0dbd3759b5b41",
"Prereqs": [],
"Patches": [
"xsa372/*.patch"
]
}
}
}
}
}
[-- Attachment #3: xsa372-4.12/0001-xen-arm-Create-dom0less-domUs-earlier.patch --]
[-- Type: application/octet-stream, Size: 2998 bytes --]
From eefbabd85ac504f4b474f79abc765dae91b91e1b Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Mon, 17 May 2021 17:47:13 +0100
Subject: [PATCH 1/2] xen/arm: Create dom0less domUs earlier
In a follow-up patch we will need to unallocate the boot modules
before heap_init_late() is called.
The modules will contain the domUs kernel and initramfs. Therefore Xen
will need to create extra domUs (used by dom0less) before heap_init_late().
This has two consequences on dom0less:
1) Domains will not be unpaused as soon as they are created but
once all have been created. However, Xen doesn't guarantee an order
to unpause, so this is not something one could rely on.
2) The memory allocated for a domU will not be scrubbed anymore when an
admin select bootscrub=on. This is not something we advertised, but if
this is a concern we can introduce either force scrub for all domUs or
a per-domain flag in the DT. The behavior for bootscrub=off and
bootscrub=idle (default) has not changed.
This is part of XSA-372 / CVE-2021-28693.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/domain_build.c | 2 --
xen/arch/arm/setup.c | 9 +++++----
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9836779d17c..6c5a6db14466 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2092,8 +2092,6 @@ void __init create_domUs(void)
if ( construct_domU(d, node) != 0 )
panic("Could not set up domain %s\n", dt_node_name(node));
-
- domain_unpause_by_systemcontroller(d);
}
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d986f84f8d2a..0e54e9c73e06 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -736,7 +736,7 @@ void __init start_xen(unsigned long boot_phys_offset,
int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
- struct domain *dom0;
+ struct domain *dom0, *d;
struct xen_domctl_createdomain dom0_cfg = {
.flags = XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap,
.max_evtchn_port = -1,
@@ -902,6 +902,8 @@ void __init start_xen(unsigned long boot_phys_offset,
if ( construct_dom0(dom0) != 0)
panic("Could not set up DOM0 guest OS\n");
+ create_domUs();
+
heap_init_late();
init_trace_bufs();
@@ -915,9 +917,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
- create_domUs();
-
- domain_unpause_by_systemcontroller(dom0);
+ for_each_domain( d )
+ domain_unpause_by_systemcontroller(d);
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
--
2.17.1
[-- Attachment #4: xsa372-4.12/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch --]
[-- Type: application/octet-stream, Size: 1945 bytes --]
From 7f10ab7019b1dc56ea3587c9c5cbc073427e02ce Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Sat, 17 Apr 2021 17:38:28 +0100
Subject: [PATCH 2/2] xen/arm: Boot modules should always be scrubbed if
bootscrub={on, idle}
The function to initialize the pages (see init_heap_pages()) will request
scrub when the admin request idle bootscrub (default) and state ==
SYS_STATE_active. When bootscrub=on, Xen will scrub any free pages in
heap_init_late().
Currently, the boot modules (e.g. kernels, initramfs) will be discarded/
freed after heap_init_late() is called and system_state switched to
SYS_STATE_active. This means the pages associated with the boot modules
will not get scrubbed before getting re-purposed.
If the memory is assigned to an untrusted domU, it may be able to
retrieve secrets from the modules.
This is part of XSA-372 / CVE-2021-28693.
Fixes: 1774e9b1df27 ("xen/arm: introduce create_domUs")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/setup.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 0e54e9c73e06..ba95c06d89f2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -73,7 +73,6 @@ static __used void init_done(void)
/* Must be done past setting system_state. */
unregister_init_virtual_region();
- discard_initial_modules();
free_init_memory();
startup_cpu_idle_loop();
}
@@ -904,6 +903,12 @@ void __init start_xen(unsigned long boot_phys_offset,
create_domUs();
+ /*
+ * This needs to be called **before** heap_init_late() so modules
+ * will be scrubbed (unless suppressed).
+ */
+ discard_initial_modules();
+
heap_init_late();
init_trace_bufs();
--
2.17.1
[-- Attachment #5: xsa372-4.14/0001-xen-arm-Create-dom0less-domUs-earlier.patch --]
[-- Type: application/octet-stream, Size: 2992 bytes --]
From f98c20aaaf909be04ada5cb6cb88c14b9bc75e15 Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Mon, 17 May 2021 17:47:13 +0100
Subject: [PATCH 1/2] xen/arm: Create dom0less domUs earlier
In a follow-up patch we will need to unallocate the boot modules
before heap_init_late() is called.
The modules will contain the domUs kernel and initramfs. Therefore Xen
will need to create extra domUs (used by dom0less) before heap_init_late().
This has two consequences on dom0less:
1) Domains will not be unpaused as soon as they are created but
once all have been created. However, Xen doesn't guarantee an order
to unpause, so this is not something one could rely on.
2) The memory allocated for a domU will not be scrubbed anymore when an
admin select bootscrub=on. This is not something we advertised, but if
this is a concern we can introduce either force scrub for all domUs or
a per-domain flag in the DT. The behavior for bootscrub=off and
bootscrub=idle (default) has not changed.
This is part of XSA-372 / CVE-2021-28693.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/domain_build.c | 2 --
xen/arch/arm/setup.c | 9 +++++----
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e824ba34b012..b07461f5d376 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2515,8 +2515,6 @@ void __init create_domUs(void)
if ( construct_domU(d, node) != 0 )
panic("Could not set up domain %s\n", dt_node_name(node));
-
- domain_unpause_by_systemcontroller(d);
}
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7968cee47d05..1f26080b30bf 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -779,7 +779,7 @@ void __init start_xen(unsigned long boot_phys_offset,
int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
- struct domain *dom0;
+ struct domain *dom0, *d;
struct xen_domctl_createdomain dom0_cfg = {
.flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
.max_evtchn_port = -1,
@@ -962,6 +962,8 @@ void __init start_xen(unsigned long boot_phys_offset,
if ( construct_dom0(dom0) != 0)
panic("Could not set up DOM0 guest OS\n");
+ create_domUs();
+
heap_init_late();
init_trace_bufs();
@@ -975,9 +977,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
- create_domUs();
-
- domain_unpause_by_systemcontroller(dom0);
+ for_each_domain( d )
+ domain_unpause_by_systemcontroller(d);
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
--
2.17.1
[-- Attachment #6: xsa372-4.14/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch --]
[-- Type: application/octet-stream, Size: 1945 bytes --]
From e7e475c1a3dc6b149252413589eebaa4ae138824 Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Sat, 17 Apr 2021 17:38:28 +0100
Subject: [PATCH 2/2] xen/arm: Boot modules should always be scrubbed if
bootscrub={on, idle}
The function to initialize the pages (see init_heap_pages()) will request
scrub when the admin request idle bootscrub (default) and state ==
SYS_STATE_active. When bootscrub=on, Xen will scrub any free pages in
heap_init_late().
Currently, the boot modules (e.g. kernels, initramfs) will be discarded/
freed after heap_init_late() is called and system_state switched to
SYS_STATE_active. This means the pages associated with the boot modules
will not get scrubbed before getting re-purposed.
If the memory is assigned to an untrusted domU, it may be able to
retrieve secrets from the modules.
This is part of XSA-372 / CVE-2021-28693.
Fixes: 1774e9b1df27 ("xen/arm: introduce create_domUs")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/setup.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1f26080b30bf..34b1c1a11ef6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -75,7 +75,6 @@ static __used void init_done(void)
/* Must be done past setting system_state. */
unregister_init_virtual_region();
- discard_initial_modules();
free_init_memory();
startup_cpu_idle_loop();
}
@@ -964,6 +963,12 @@ void __init start_xen(unsigned long boot_phys_offset,
create_domUs();
+ /*
+ * This needs to be called **before** heap_init_late() so modules
+ * will be scrubbed (unless suppressed).
+ */
+ discard_initial_modules();
+
heap_init_late();
init_trace_bufs();
--
2.17.1
[-- Attachment #7: xsa372-4.15/0001-xen-arm-Create-dom0less-domUs-earlier.patch --]
[-- Type: application/octet-stream, Size: 3059 bytes --]
From b1e5a89f19d9919c3eae17ab9c6a663b0801ad9c Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Mon, 17 May 2021 17:47:13 +0100
Subject: [PATCH 1/2] xen/arm: Create dom0less domUs earlier
In a follow-up patch we will need to unallocate the boot modules
before heap_init_late() is called.
The modules will contain the domUs kernel and initramfs. Therefore Xen
will need to create extra domUs (used by dom0less) before heap_init_late().
This has two consequences on dom0less:
1) Domains will not be unpaused as soon as they are created but
once all have been created. However, Xen doesn't guarantee an order
to unpause, so this is not something one could rely on.
2) The memory allocated for a domU will not be scrubbed anymore when an
admin select bootscrub=on. This is not something we advertised, but if
this is a concern we can introduce either force scrub for all domUs or
a per-domain flag in the DT. The behavior for bootscrub=off and
bootscrub=idle (default) has not changed.
This is part of XSA-372 / CVE-2021-28693.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/domain_build.c | 2 --
xen/arch/arm/setup.c | 11 ++++++-----
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 374bf655ee34..4203ddcca0e3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2515,8 +2515,6 @@ void __init create_domUs(void)
if ( construct_domU(d, node) != 0 )
panic("Could not set up domain %s\n", dt_node_name(node));
-
- domain_unpause_by_systemcontroller(d);
}
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2532ec973913..441e0e16e9f0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -804,7 +804,7 @@ void __init start_xen(unsigned long boot_phys_offset,
int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
- struct domain *dom0;
+ struct domain *dom0, *d;
struct xen_domctl_createdomain dom0_cfg = {
.flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
.max_evtchn_port = -1,
@@ -987,6 +987,9 @@ void __init start_xen(unsigned long boot_phys_offset,
if ( construct_dom0(dom0) != 0)
panic("Could not set up DOM0 guest OS\n");
+ if ( acpi_disabled )
+ create_domUs();
+
heap_init_late();
init_trace_bufs();
@@ -1000,10 +1003,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
- if ( acpi_disabled )
- create_domUs();
-
- domain_unpause_by_systemcontroller(dom0);
+ for_each_domain( d )
+ domain_unpause_by_systemcontroller(d);
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
--
2.17.1
[-- Attachment #8: xsa372-4.15/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch --]
[-- Type: application/octet-stream, Size: 1963 bytes --]
From 09bb28bdef3fb5e7d08bdd641601ca0c0d4d82b4 Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Sat, 17 Apr 2021 17:38:28 +0100
Subject: [PATCH 2/2] xen/arm: Boot modules should always be scrubbed if
bootscrub={on, idle}
The function to initialize the pages (see init_heap_pages()) will request
scrub when the admin request idle bootscrub (default) and state ==
SYS_STATE_active. When bootscrub=on, Xen will scrub any free pages in
heap_init_late().
Currently, the boot modules (e.g. kernels, initramfs) will be discarded/
freed after heap_init_late() is called and system_state switched to
SYS_STATE_active. This means the pages associated with the boot modules
will not get scrubbed before getting re-purposed.
If the memory is assigned to an untrusted domU, it may be able to
retrieve secrets from the modules.
This is part of XSA-372 / CVE-2021-28693.
Fixes: 1774e9b1df27 ("xen/arm: introduce create_domUs")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/setup.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 441e0e16e9f0..8afb78f2c985 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -72,8 +72,6 @@ domid_t __read_mostly max_init_domid;
static __used void init_done(void)
{
- discard_initial_modules();
-
/* Must be done past setting system_state. */
unregister_init_virtual_region();
@@ -990,6 +988,12 @@ void __init start_xen(unsigned long boot_phys_offset,
if ( acpi_disabled )
create_domUs();
+ /*
+ * This needs to be called **before** heap_init_late() so modules
+ * will be scrubbed (unless suppressed).
+ */
+ discard_initial_modules();
+
heap_init_late();
init_trace_bufs();
--
2.17.1
[-- Attachment #9: xsa372/0001-xen-arm-Create-dom0less-domUs-earlier.patch --]
[-- Type: application/octet-stream, Size: 4098 bytes --]
From a24fef73edc75c7aff7dc2cbcc2ee6df9893a2eb Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Mon, 17 May 2021 17:47:13 +0100
Subject: [PATCH 1/2] xen/arm: Create dom0less domUs earlier
In a follow-up patch we will need to unallocate the boot modules
before heap_init_late() is called.
The modules will contain the domUs kernel and initramfs. Therefore Xen
will need to create extra domUs (used by dom0less) before heap_init_late().
This has two consequences on dom0less:
1) Domains will not be unpaused as soon as they are created but
once all have been created. However, Xen doesn't guarantee an order
to unpause, so this is not something one could rely on.
2) The memory allocated for a domU will not be scrubbed anymore when an
admin select bootscrub=on. This is not something we advertised, but if
this is a concern we can introduce either force scrub for all domUs or
a per-domain flag in the DT. The behavior for bootscrub=off and
bootscrub=idle (default) has not changed.
This is part of XSA-372 / CVE-2021-28693.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/domain_build.c | 6 +-----
xen/arch/arm/setup.c | 14 +++++++-------
xen/include/asm-arm/setup.h | 2 +-
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 282416e74da4..6c86d527810f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2521,8 +2521,6 @@ void __init create_domUs(void)
if ( construct_domU(d, node) != 0 )
panic("Could not set up domain %s\n", dt_node_name(node));
-
- domain_unpause_by_systemcontroller(d);
}
}
@@ -2584,7 +2582,7 @@ static int __init construct_dom0(struct domain *d)
return construct_domain(d, &kinfo);
}
-struct domain* __init create_dom0(void)
+void __init create_dom0(void)
{
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {
@@ -2615,8 +2613,6 @@ struct domain* __init create_dom0(void)
if ( construct_dom0(dom0) != 0)
panic("Could not set up DOM0 guest OS\n");
-
- return dom0;
}
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 00aad1c194b9..e17532c132cf 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -836,7 +836,7 @@ void __init start_xen(unsigned long boot_phys_offset,
int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
- struct domain *dom0 = NULL;
+ struct domain *d;
int rc;
dcache_line_bytes = read_dcache_line_bytes();
@@ -992,10 +992,13 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Create initial domain 0. */
if ( !is_dom0less_mode() )
- dom0 = create_dom0();
+ create_dom0();
else
printk(XENLOG_INFO "Xen dom0less mode detected\n");
+ if ( acpi_disabled )
+ create_domUs();
+
heap_init_late();
init_trace_bufs();
@@ -1009,11 +1012,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
- if ( acpi_disabled )
- create_domUs();
-
- if ( dom0 )
- domain_unpause_by_systemcontroller(dom0);
+ for_each_domain( d )
+ domain_unpause_by_systemcontroller(d);
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 528324401511..c4b6af602995 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -94,7 +94,7 @@ void acpi_create_efi_mmap_table(struct domain *d,
int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
void create_domUs(void);
-struct domain* create_dom0(void);
+void create_dom0(void);
void discard_initial_modules(void);
void fw_unreserved_regions(paddr_t s, paddr_t e,
--
2.17.1
[-- Attachment #10: xsa372/0002-xen-arm-Boot-modules-should-always-be-scrubbed-if-bo.patch --]
[-- Type: application/octet-stream, Size: 1963 bytes --]
From 757a461ed906248a56cc1bb922a1ba07a7ee1154 Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Sat, 17 Apr 2021 17:38:28 +0100
Subject: [PATCH 2/2] xen/arm: Boot modules should always be scrubbed if
bootscrub={on, idle}
The function to initialize the pages (see init_heap_pages()) will request
scrub when the admin request idle bootscrub (default) and state ==
SYS_STATE_active. When bootscrub=on, Xen will scrub any free pages in
heap_init_late().
Currently, the boot modules (e.g. kernels, initramfs) will be discarded/
freed after heap_init_late() is called and system_state switched to
SYS_STATE_active. This means the pages associated with the boot modules
will not get scrubbed before getting re-purposed.
If the memory is assigned to an untrusted domU, it may be able to
retrieve secrets from the modules.
This is part of XSA-372 / CVE-2021-28693.
Fixes: 1774e9b1df27 ("xen/arm: introduce create_domUs")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/setup.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e17532c132cf..63a908e325ee 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -71,8 +71,6 @@ domid_t __read_mostly max_init_domid;
static __used void init_done(void)
{
- discard_initial_modules();
-
/* Must be done past setting system_state. */
unregister_init_virtual_region();
@@ -999,6 +997,12 @@ void __init start_xen(unsigned long boot_phys_offset,
if ( acpi_disabled )
create_domUs();
+ /*
+ * This needs to be called **before** heap_init_late() so modules
+ * will be scrubbed (unless suppressed).
+ */
+ discard_initial_modules();
+
heap_init_late();
init_trace_bufs();
--
2.17.1
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2021-06-08 17:04 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-08 17:04 Xen Security Advisory 372 v3 (CVE-2021-28693) - xen/arm: Boot modules are not scrubbed Xen.org security team
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.