Skip to content

Commit b2d4541

Browse files
PlaidCatPlaidCat
committed
x86/coco: Require seeding RNG with RDRAND on CoCo systems
jira LE-1907 cve CVE-2024-35875 Rebuild_History Non-Buildable kernel-5.14.0-427.35.1.el9_4 commit-author Jason A. Donenfeld <Jason@zx2c4.com> commit 99485c4 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-5.14.0-427.35.1.el9_4/99485c4c.failed There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. Many device drivers and platforms have some desire to contribute something to the RNG, and add_device_randomness() is specifically meant for this purpose. Any driver can call it with seed data of any quality, or even garbage quality, and it can only possibly make the quality of the RNG better or have no effect, but can never make it worse. Rather than trying to build something into the core of the RNG, consider the particular CoCo issue just a CoCo issue, and therefore separate it all out into driver (well, arch/platform) code. [ bp: Massage commit message. ] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Elena Reshetova <elena.reshetova@intel.com> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240326160735.73531-1-Jason@zx2c4.com (cherry picked from commit 99485c4) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # arch/x86/coco/core.c # arch/x86/kernel/setup.c
1 parent 1b28bb8 commit b2d4541

File tree

1 file changed

+151
-0
lines changed

1 file changed

+151
-0
lines changed

‎ciq/ciq_backports/kernel-5.14.0-427.35.1.el9_4/99485c4c.failed‎

Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
x86/coco: Require seeding RNG with RDRAND on CoCo systems
2+
3+
jira LE-1907
4+
cve CVE-2024-35875
5+
Rebuild_History Non-Buildable kernel-5.14.0-427.35.1.el9_4
6+
commit-author Jason A. Donenfeld <Jason@zx2c4.com>
7+
commit 99485c4c026f024e7cb82da84c7951dbe3deb584
8+
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
9+
Will be included in final tarball splat. Ref for failed cherry-pick at:
10+
ciq/ciq_backports/kernel-5.14.0-427.35.1.el9_4/99485c4c.failed
11+
12+
There are few uses of CoCo that don't rely on working cryptography and
13+
hence a working RNG. Unfortunately, the CoCo threat model means that the
14+
VM host cannot be trusted and may actively work against guests to
15+
extract secrets or manipulate computation. Since a malicious host can
16+
modify or observe nearly all inputs to guests, the only remaining source
17+
of entropy for CoCo guests is RDRAND.
18+
19+
If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole
20+
is meant to gracefully continue on gathering entropy from other sources,
21+
but since there aren't other sources on CoCo, this is catastrophic.
22+
This is mostly a concern at boot time when initially seeding the RNG, as
23+
after that the consequences of a broken RDRAND are much more
24+
theoretical.
25+
26+
So, try at boot to seed the RNG using 256 bits of RDRAND output. If this
27+
fails, panic(). This will also trigger if the system is booted without
28+
RDRAND, as RDRAND is essential for a safe CoCo boot.
29+
30+
Add this deliberately to be "just a CoCo x86 driver feature" and not
31+
part of the RNG itself. Many device drivers and platforms have some
32+
desire to contribute something to the RNG, and add_device_randomness()
33+
is specifically meant for this purpose.
34+
35+
Any driver can call it with seed data of any quality, or even garbage
36+
quality, and it can only possibly make the quality of the RNG better or
37+
have no effect, but can never make it worse.
38+
39+
Rather than trying to build something into the core of the RNG, consider
40+
the particular CoCo issue just a CoCo issue, and therefore separate it
41+
all out into driver (well, arch/platform) code.
42+
43+
[ bp: Massage commit message. ]
44+
45+
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
46+
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
47+
Reviewed-by: Elena Reshetova <elena.reshetova@intel.com>
48+
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
49+
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
50+
Cc: stable@vger.kernel.org
51+
Link: https://lore.kernel.org/r/20240326160735.73531-1-Jason@zx2c4.com
52+
(cherry picked from commit 99485c4c026f024e7cb82da84c7951dbe3deb584)
53+
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
54+
55+
# Conflicts:
56+
# arch/x86/coco/core.c
57+
# arch/x86/kernel/setup.c
58+
diff --cc arch/x86/coco/core.c
59+
index c6e6b6f7dcaa,ddd4efdc79d6..000000000000
60+
--- a/arch/x86/coco/core.c
61+
+++ b/arch/x86/coco/core.c
62+
@@@ -149,12 -153,39 +153,50 @@@ u64 cc_mkdec(u64 val
63+
}
64+
EXPORT_SYMBOL_GPL(cc_mkdec);
65+
66+
++<<<<<<< HEAD
67+
+__init void cc_set_vendor(enum cc_vendor v)
68+
+{
69+
+ vendor = v;
70+
+}
71+
+
72+
+__init void cc_set_mask(u64 mask)
73+
+{
74+
+ cc_mask = mask;
75+
++=======
76+
+ __init void cc_random_init(void)
77+
+ {
78+
+ /*
79+
+ * The seed is 32 bytes (in units of longs), which is 256 bits, which
80+
+ * is the security level that the RNG is targeting.
81+
+ */
82+
+ unsigned long rng_seed[32 / sizeof(long)];
83+
+ size_t i, longs;
84+
+
85+
+ if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
86+
+ return;
87+
+
88+
+ /*
89+
+ * Since the CoCo threat model includes the host, the only reliable
90+
+ * source of entropy that can be neither observed nor manipulated is
91+
+ * RDRAND. Usually, RDRAND failure is considered tolerable, but since
92+
+ * CoCo guests have no other unobservable source of entropy, it's
93+
+ * important to at least ensure the RNG gets some initial random seeds.
94+
+ */
95+
+ for (i = 0; i < ARRAY_SIZE(rng_seed); i += longs) {
96+
+ longs = arch_get_random_longs(&rng_seed[i], ARRAY_SIZE(rng_seed) - i);
97+
+
98+
+ /*
99+
+ * A zero return value means that the guest doesn't have RDRAND
100+
+ * or the CPU is physically broken, and in both cases that
101+
+ * means most crypto inside of the CoCo instance will be
102+
+ * broken, defeating the purpose of CoCo in the first place. So
103+
+ * just panic here because it's absolutely unsafe to continue
104+
+ * executing.
105+
+ */
106+
+ if (longs == 0)
107+
+ panic("RDRAND is defective.");
108+
+ }
109+
+ add_device_randomness(rng_seed, sizeof(rng_seed));
110+
+ memzero_explicit(rng_seed, sizeof(rng_seed));
111+
++>>>>>>> 99485c4c026f (x86/coco: Require seeding RNG with RDRAND on CoCo systems)
112+
}
113+
diff --cc arch/x86/kernel/setup.c
114+
index 41fcc003b64d,e125e059e2c4..000000000000
115+
--- a/arch/x86/kernel/setup.c
116+
+++ b/arch/x86/kernel/setup.c
117+
@@@ -1088,7 -991,8 +1089,12 @@@ void __init setup_arch(char **cmdline_p
118+
* Needs to run after memblock setup because it needs the physical
119+
* memory size.
120+
*/
121+
++<<<<<<< HEAD
122+
+ sev_setup_arch();
123+
++=======
124+
+ mem_encrypt_setup_arch();
125+
+ cc_random_init();
126+
++>>>>>>> 99485c4c026f (x86/coco: Require seeding RNG with RDRAND on CoCo systems)
127+
128+
efi_fake_memmap();
129+
efi_find_mirror();
130+
* Unmerged path arch/x86/coco/core.c
131+
diff --git a/arch/x86/include/asm/coco.h b/arch/x86/include/asm/coco.h
132+
index d2c6a2e8d04d..1bc19560a7cf 100644
133+
--- a/arch/x86/include/asm/coco.h
134+
+++ b/arch/x86/include/asm/coco.h
135+
@@ -16,6 +16,7 @@ void cc_set_mask(u64 mask);
136+
#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
137+
u64 cc_mkenc(u64 val);
138+
u64 cc_mkdec(u64 val);
139+
+void cc_random_init(void);
140+
#else
141+
static inline u64 cc_mkenc(u64 val)
142+
{
143+
@@ -26,6 +27,7 @@ static inline u64 cc_mkdec(u64 val)
144+
{
145+
return val;
146+
}
147+
+static inline void cc_random_init(void) { }
148+
#endif
149+
150+
#endif /* _ASM_X86_COCO_H */
151+
* Unmerged path arch/x86/kernel/setup.c

0 commit comments

Comments
 (0)