diff --git a/mcpp.toml b/mcpp.toml
index 8274037..b9d82ac 100644
--- a/mcpp.toml
+++ b/mcpp.toml
@@ -15,7 +15,7 @@ authors     = ["mcpplibs"]
 repo        = "https://github.com/mcpplibs/openkal-musl"
 
 [dependencies]
-openkal = "0.6.0"
+openkal = "0.7.0"
 
 # An ordinary consumer of openkal declares the specification and leaves the
 # choice of implementation to whoever builds the program, which is what the
diff --git a/port/include/sys/random.h b/port/include/sys/random.h
new file mode 100644
index 0000000..2d12764
--- /dev/null
+++ b/port/include/sys/random.h
@@ -0,0 +1,39 @@
+/* musl's <sys/random.h>, plus the declaration a consumer expects to find here.
+ *
+ * ⭐ THE SAME QUESTION EVERY OTHER OVERLAY IN THIS ECOSYSTEM ANSWERS: consumers
+ * ask "which OPERATING SYSTEM is this" and assume that system's C library. Here
+ * the C library is musl, whatever the system underneath.
+ *
+ * `getentropy` and `getrandom` live in different headers depending on the C
+ * library. glibc declares both here; musl declares `getrandom` here and
+ * `getentropy` in <unistd.h>. A consumer written against glibc's layout
+ * includes this header alone and does not find `getentropy`. Measured
+ * 2026-08-25, building libc++'s `src/random.cpp` with
+ * `_LIBCPP_USING_GETENTROPY`:
+ *
+ *     random.cpp:52:14: error: use of undeclared identifier 'getentropy'
+ *
+ * ⚠️ THIS ADDS A DECLARATION AND NOTHING ELSE. The definition is musl's, in
+ * `src/misc/getentropy.c`, unchanged; what this file corrects is where a
+ * consumer looks for its name. Declaring it in both places is what glibc does
+ * and what the consumer was written against.
+ */
+#ifndef OKM_SYS_RANDOM_H
+#define OKM_SYS_RANDOM_H
+
+#include_next <sys/random.h>
+
+#define __NEED_size_t
+#include <bits/alltypes.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+int getentropy(void*, size_t);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* OKM_SYS_RANDOM_H */
diff --git a/port/src/okm_syscall.c b/port/src/okm_syscall.c
index b1c2b86..0cb80dd 100644
--- a/port/src/okm_syscall.c
+++ b/port/src/okm_syscall.c
@@ -24,6 +24,7 @@
 #define _GNU_SOURCE
 #include "okm.h"
 #include "okm_opt.h"
+#include <openkal/random.h>
 
 #include <errno.h>
 #include <fcntl.h>
@@ -821,6 +822,28 @@ syscall_arg_t __okm_syscall(syscall_arg_t n, syscall_arg_t a1, syscall_arg_t a2,
 	/* --- execution contexts ------------------------------------------------ */
 	case SYS_futex:
 		return __okm_futex((const int*)a1, (int)a2, (int)a3, (const struct timespec*)a4);
+	/* ⭐ THROUGH THE INTERFACE, NOT THROUGH THE PLATFORM.
+	 *
+	 * musl's own `src/linux/getrandom.c` issues SYS_getrandom directly, which
+	 * is right where a Linux kernel is underneath and wrong here: this port
+	 * exists so that every request reaches the environment through openkal.
+	 * The call below is the whole difference.
+	 *
+	 * ⚠️ AND IT IS WHY `openkal.random` HAD TO EXIST. Entropy is not derivable
+	 * from the other interfaces --- a clock reading is unpredictable to a
+	 * reader of the source and not to an adversary, which the AT_RANDOM note
+	 * in okm_start.c already says about the bytes it derives, and openkal.fs
+	 * deliberately cannot open `/dev/urandom`. Neither bypassing the layer nor
+	 * inventing entropy was acceptable, so the layer gained an interface.
+	 *
+	 * The flags argument is ignored: GRND_NONBLOCK asks for a short read and
+	 * `kal_random_fill` has no partial success to report. An environment that
+	 * blocks says so in `kal_random_props`. */
+	case SYS_getrandom: {
+		const int rc = kal_random_fill((void*)a1, (kal_uintptr)a2);
+		if (rc != kal_ok) return -okm_errno(rc);
+		return (syscall_arg_t)a2;
+	}
 	case SYS_sched_yield: okm_task_yield(); return 0;
 	case SYS_gettid:      return (syscall_arg_t)OKM_CONTEXT_ID();
 	case SYS_getpid:      return 1;