From cb42938bd4bc20f9f7d3c646b37fa30fc194587f Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Tue, 25 Aug 2026 04:28:39 +0800 Subject: [PATCH 1/2] feat: getrandom through the interface layer, and getentropy where a consumer looks for it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit musl 自己的 `src/linux/getrandom.c` 直接发 `SYS_getrandom`。在 Linux 内核 底下时这是对的,在这里是错的:**这个 port 存在的理由就是让每一次请求 经 openkal 到达环境。** dispatch 里加一个 case,转给 `kal_random_fill` —— 与已经在那里的 69 个 系统调用同一条路。 ⚠️ flags 被忽略:`GRND_NONBLOCK` 要的是短读,而 `kal_random_fill` 没有 部分成功可报。一个会阻塞的环境在 `kal_random_props` 里说这件事。 ── ⚠️ 并且 `getentropy` 的声明位置,glibc 与 musl 不同 ──────── glibc 声明 getrandom 与 getentropy musl 只声明 getrandom;getentropy 在 而 libc++ 的 GETENTROPY 分支只 include 前者: random.cpp:52:14: error: use of undeclared identifier 'getentropy' ⭐ 这正是 `port/include/` overlay 存在的问题类型 —— 消费者问的是 「这是哪个操作系统」并假定那个系统的 C 库,而这里的 C 库是 musl。 `port/include/sys/random.h` 用 `#include_next` 取回 musl 那份, 再补上那一行声明。 ⚠️ **只加声明,别的什么都不加。** 定义仍是 musl 的 `src/misc/getentropy.c`, 未经修改;本文件纠正的是消费者去哪里找这个名字。两处都声明正是 glibc 的做法, 也是消费者所针对的。 实测:`getentropy` 返回 0,两次调用字节不同 —— 整条链 `std::random_device → getentropy → getrandom → kal_random_fill → 后端` 全程走接口层。 --- port/include/sys/random.h | 39 +++++++++++++++++++++++++++++++++++++++ port/src/okm_syscall.c | 23 +++++++++++++++++++++++ 2 files changed, 62 insertions(+) create mode 100644 port/include/sys/random.h 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 , 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 . 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 + +#define __NEED_size_t +#include + +#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 #include #include @@ -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; From 1abbc90e34d969a4b06d1cdd2921b0d20c642a3c Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Tue, 25 Aug 2026 04:49:08 +0800 Subject: [PATCH 2/2] deps: follow openkal 0.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 规范新增 `openkal.random`,版本升到 0.7.0。CI 的版本同步门要求实现与规范 同步声明 —— 它的诊断说得很准:「Nothing is wrong with either; they are not in step.」 --- mcpp.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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