linux-kernel - Re: [PATCH] random: move randomize

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] [day] [month] [year] [list]

Date:   Tue, 17 May 2022 00:07:12 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH] random: move randomize_page() into mm where it belongs

Hi Andrew,

On Mon, May 16, 2022 at 02:28:00PM -0700, Andrew Morton wrote:
> On Sat, 14 May 2022 14:05:56 +0200 "Jason A. Donenfeld" <Jason@...c4.com> wrote:
> 
> > randomize_page is an mm function. It is documented like one. It contains
> > the history of one. It has the naming convention of one. It looks
> > just like another very similar function in mm, randomize_stack_top().
> > And it has always been maintained and updated by mm people. There is no
> > need for it to be in random.c. In the "which shape does not look like
> > the other ones" test, pointing to randomize_page() is correct.
> > 
> > So move randomize_page() into mm/util.c, right next to the similar
> > randomize_stack_top() function.
> > 
> > This commit contains no actual code changes.
> 
> hm, does it make sense?
> 
> Probably randomize_page() (which used to be called randomize_range())
> should have been called randomize_address().  Is it an MM function
> then?  Not really - it's simply an application of the random number
> generator.  So I think it's more a random thing than an MM thing.

There are many uses of randomness in the Linux kernel. Your use in mm is
not a special snowflake usage. You want good random integers with
various crypto properties? No problem, you got it. But what you do
with those is your own business. (I'm just a random number dealer.) The
particulars of addresses or page aligned addresses or whatever weird
properties you need out of this thing is your own mm puzzle. It has no
business hanging out here. And as evidence of this, randomize_stack_
top() is also in mm/util.c where it belongs and where the various things
it does can be maintained by people who know a thing or two about mm.
Just imagine all the different types of domain-specific objects that we
could randomize according to certain rules, and how insane it would be
if those all wound up in random.c. 

So with all due respect, I must disagree with you.

> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -343,6 +343,38 @@ unsigned long randomize_stack_top(unsigned long stack_top)
> >  #endif
> >  }
> >  
> > +/**
> > + * randomize_page - Generate a random, page aligned address
> 
> The patch assumes that drivers/char/random.o is always built into
> vmlinux, which appears to be the case.  If some space-conscious person
> goes and makes random.o build-time optional then they'll need to make
> the appropriate adjustments in util.c.  I see no problems with this.

random.o has random_init() that is called by main.o, so just for that
reason alone, it's un-=m-able. Plus the zillion call sites everywhere in
the kernel. It'll always be a builtin (and rightly so too, I think).

Jason

>