[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <pJC6Xfp-dzUSXwVZcxD41xDVvMrMIPLVGeW9nqNcson0exmopb48dHDk7eTPfvOwVXdRbA7p12IMcbJwbi3onmHVnG8cAu8cjUStGCq5cy8=@zhuyi.fan>
Date: Mon, 23 Sep 2024 21:18:44 +0000
From: Schrodinger ZHU Yifan <i@...yi.fan>
To: "libc-coord@...ts.openwall.com" <libc-coord@...ts.openwall.com>
Subject: getrandom via vDSO
Hi,
It's Yifan, a regular committer to the LLVM-libc project.
We have recently merged the vDSO functionality into our codebase so I am checking existing syscall wrappers to apply vDSO if related symbols are feasible.
__vdso_getrandom/__kernel_getrandom has been recently introduced into the linux kernel, I wonder what should be a proper plan to utilize it. The additional userspace state structure looks a bit scary to me. It seems to me that the state requires proper maintenance across fork and clone, and has potential security implications. This reminds me of history of pid caching, so I am hesitating on whether I should go ahead to implement getrandom optimization when the vDSO symbols are available. (P.S. this time, kernel provides desired flags that can help us to keep the region safe to some extend: https://lore.kernel.org/linux-mm/20240703183115.1075219-2-Jason@zx2c4.com/T/)
Given that glibc is already working on a patch, I wonder if we have consensus on the following questions:
1. Is there a clear performance demand such that it becomes necessarily to avoid syscall inside `getrandom`?
2. Is it certain that such performance demand will pay off given all the additional complexity required to maintain per-thread/per-process state (with async-signal-safety)?
3. Is it clear that unwrapped clone/fork and other edge cases will not complicate the situation?
Best,
Yifan
Schrodinger ZHU Yifan, Ph.D. Student
Computer Science Department, University of Rochester
Personal Email: i@...yi.fan
Work Email: yifanzhu@...hester.edu
Website: https://www.cs.rochester.edu/~yzhu104/Main.html
Github: SchrodingerZhu
GPG Fingerprint: BA02CBEB8CB5D8181E9368304D2CC545A78DBCC3
Content of type "text/html" skipped
Download attachment "publickey - i@...yi.fan - 0xA98A3EAE.asc" of type "application/pgp-keys" (624 bytes)
Download attachment "image" of type "image/png" (19680 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (250 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
