linux-kernel - Re: [PATCH RFC v2] random: implement getrandom() in vDSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Aug 2022 02:12:31 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        x86@...nel.org, Nadia Heninger <nadiah@...ucsd.edu>,
        Thomas Ristenpart <ristenpart@...nell.edu>,
        Theodore Ts'o <tytso@....edu>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
        Florian Weimer <fweimer@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC v2] random: implement getrandom() in vDSO

On Tue, Aug 02, 2022 at 01:41:58AM +0200, Jason A. Donenfeld wrote:
> Hi Thomas,
> 
> On Mon, Aug 01, 2022 at 10:48:56PM +0200, Thomas Gleixner wrote:
> > On Sun, Jul 31 2022 at 03:31, Jason A. Donenfeld wrote:
> > You clearly forgot to tell people that they need a special config to
> > make this compile.
> 
> As I wrote in my patch body:
> 
> | The actual place that has the most work to do is in all of the other
> | files. Most of the vDSO shared page infrastructure is centered around
> | gettimeofday, and so the main structs are all in arrays for different
> | timestamp types, and attached to time namespaces, and so forth. I've
> | done the best I could to add onto this in an unintrusive way, but you'll
> | notice almost immediately from glancing at the code that it still needs
> | some untangling work. This also only works on x86 at the moment. I could
> | certainly use a hand with this part.
> 
> So I'm not surprised other things are screwed up. This works well in my
> test harness, indeed, but I imagine there are lots of fiddly bits like
> that to work out. I wanted to send an RFC to elicit comments on the idea
> and API before moving forward, as I have a strong sense this is one of
> those "90% 10%" things, where 10% of the details take 90% of the time.
> 
> Also, I haven't hooked up vdso32 yet.

Just to add, your "special config", "defconfig" remarks and such don't
strike me as very accurate. I had forgotten until a second ago that I'm
actually running this on my laptop's kernel, which is a fairly normal
"desktop distro" kernel with modules and lots of bloat turned on. So
c'mon now... the thing does work.

With that said, I've taken a stab at the various build, symbol, and
timens things you pointed out (thanks for that), and that's sitting now
in a branch, and will be part of a v3 if I ever post a v3:

https://git.zx2c4.com/linux-rng/commit/?h=jd/vdso

That pointer arithmetic around the timens stuff might not be super duper
appealing; I could add a symbol and have the linker resolve its location
and such. But also I wasn't keen on adding a symbol to a piece of data
that's not really there. So instead I calculate that offset from the
vdso_data and timens_vdso_data symbols.

By the way, in writing a test for that, I thought it was interesting
that CLONE_NEWTIME requires a new process, rather than just an execve.
You don't want to do it immediately, because that'd involve a
potentially racy remapping of the vvar pages. But at the very least it
could have been done on execve, right? Since all the maps are thrown out
then.

Jason