[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZoreAN1w6uBgLRi7YY2cbgqEVvg-Dyxyb4rHZM3i0r1zrw@mail.gmail.com>
Date: Mon, 23 Sep 2024 17:27:20 -0400
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Subject: Re: getrandom via vDSO
yeah, fwiw i had most of the same thoughts for bionic too. and i've not
really understood who the intended user of this is.
(but it will be years before anyone's shipping an Android device with a
6.12 kernel anyway, so i can afford to sit this out for now and see how
well it goes :-) )
On Mon, Sep 23, 2024 at 5:19 PM Schrodinger ZHU Yifan <i@...yi.fan> wrote:
> 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
>
> [image: image]
> 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 "image" of type "image/png" (19680 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.
