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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux