Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add systemd patch for booting on AMD Ryzen #6183

Merged
merged 1 commit into from
Jan 3, 2020
Merged

Add systemd patch for booting on AMD Ryzen #6183

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions ...iso/minikube-iso/board/coreos/minikube/patches/systemd/240/rdrand-workaround-on-amd.patch
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
Index: systemd-240/src/basic/random-util.c
===================================================================
--- systemd-240.orig/src/basic/random-util.c
+++ systemd-240/src/basic/random-util.c
@@ -37,6 +37,7 @@ int rdrand(unsigned long *ret) {

#if defined(__i386__) || defined(__x86_64__)
static int have_rdrand = -1;
+ unsigned long v;
unsigned char err;

if (have_rdrand < 0) {
@@ -56,9 +57,22 @@ int rdrand(unsigned long *ret) {

asm volatile("rdrand %0;"
"setc %1"
- : "=r" (*ret),
+ : "=r" (v),
"=qm" (err));

+ /* Apparently on some AMD CPUs RDRAND will sometimes (after a suspend/resume cycle?) report success
+ * via the carry flag but nonetheless return the same fixed value -1 in all cases. This appears to be
+ * a bad bug in the CPU or firmware. Let's deal with that and work-around this by explicitly checking
+ * for this special value (and also 0, just to be sure) and filtering it out. This is a work-around
+ * only however and something AMD really should fix properly. The Linux kernel should probably work
+ * around this issue by turning off RDRAND altogether on those CPUs. See:
+ * https://github.com/systemd/systemd/issues/11810 */
+ if (v == 0 || v == ULONG_MAX)
+ return log_debug_errno(SYNTHETIC_ERRNO(EUCLEAN),
+ "RDRAND returned suspicious value %lx, assuming bad hardware RNG, not using value.", v);
+
+ *ret = v;
+
#if HAS_FEATURE_MEMORY_SANITIZER
__msan_unpoison(&err, sizeof(err));
#endif
1 change: 1 addition & 0 deletions deploy/iso/minikube-iso/configs/minikube_defconfig
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ BR2_SYSTEM_BIN_SH_BASH=y
# BR2_TARGET_GENERIC_GETTY is not set
BR2_ROOTFS_USERS_TABLES="$(BR2_EXTERNAL_MINIKUBE_PATH)/board/coreos/minikube/users"
BR2_ROOTFS_OVERLAY="$(BR2_EXTERNAL_MINIKUBE_PATH)/board/coreos/minikube/rootfs-overlay"
BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL_MINIKUBE_PATH)/board/coreos/minikube/patches"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL_MINIKUBE_PATH)/board/coreos/minikube/linux_defconfig"
Expand Down