All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"Andreas Noever" <andreas.noever@gmail.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Dave Airlie" <airlied@redhat.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Florian Westphal" <fw@strlen.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Helge Deller" <deller@gmx.de>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Hugh Dickins" <hughd@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Jan Kara" <jack@suse.com>, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jozsef Kadlecsik" <kadlec@netfilter.org>,
	"KP Singh" <kpsingh@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Marco Elver" <elver@google.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Pablo Neira Ayuso" <pablo@netfilter.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Russell King" <linux@armlinux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Thomas Graf" <tgraf@suug.ch>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"WANG Xuerui" <kernel@xen0n.name>,
	"Will Deacon" <will@kernel.org>,
	"Yury Norov" <yury.norov@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Chuck Lever" <chuck.lever@oracle.com>, "Jan Kara" <jack@suse.cz>
Subject: Re: [PATCH v3 3/5] treewide: use get_random_u32() when possible
Date: Fri, 7 Oct 2022 08:07:58 -0600	[thread overview]
Message-ID: <Y0Ayvov/KQmrIwTS@zx2c4.com> (raw)
In-Reply-To: <501b0fc3-6c67-657f-781e-25ee0283bc2e@csgroup.eu>

On Fri, Oct 07, 2022 at 04:57:24AM +0000, Christophe Leroy wrote:
> 
> 
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> >>>> Hi Christophe,
> >>>>
> >>>> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> >>>> <christophe.leroy@csgroup.eu> wrote:
> >>>>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> >>>>>> The prandom_u32() function has been a deprecated inline wrapper around
> >>>>>> get_random_u32() for several releases now, and compiles down to the
> >>>>>> exact same code. Replace the deprecated wrapper with a direct call to
> >>>>>> the real function. The same also applies to get_random_int(), which is
> >>>>>> just a wrapper around get_random_u32().
> >>>>>>
> >>>>>> Reviewed-by: Kees Cook <keescook@chromium.org>
> >>>>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> # for sch_cake
> >>>>>> Acked-by: Chuck Lever <chuck.lever@oracle.com> # for nfsd
> >>>>>> Reviewed-by: Jan Kara <jack@suse.cz> # for ext4
> >>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >>>>>> ---
> >>>>>
> >>>>>> diff --git a/arch/powerpc/kernel/process.c
> >>>>>> b/arch/powerpc/kernel/process.c
> >>>>>> index 0fbda89cd1bb..9c4c15afbbe8 100644
> >>>>>> --- a/arch/powerpc/kernel/process.c
> >>>>>> +++ b/arch/powerpc/kernel/process.c
> >>>>>> @@ -2308,6 +2308,6 @@ void notrace __ppc64_runlatch_off(void)
> >>>>>>     unsigned long arch_align_stack(unsigned long sp)
> >>>>>>     {
> >>>>>>         if (!(current->personality & ADDR_NO_RANDOMIZE) &&
> >>>>>> randomize_va_space)
> >>>>>> -             sp -= get_random_int() & ~PAGE_MASK;
> >>>>>> +             sp -= get_random_u32() & ~PAGE_MASK;
> >>>>>>         return sp & ~0xf;
> >>>>>
> >>>>> Isn't that a candidate for prandom_u32_max() ?
> >>>>>
> >>>>> Note that sp is deemed to be 16 bytes aligned at all time.
> >>>>
> >>>> Yes, probably. It seemed non-trivial to think about, so I didn't. But
> >>>> let's see here... maybe it's not too bad:
> >>>>
> >>>> If PAGE_MASK is always ~(PAGE_SIZE-1), then ~PAGE_MASK is
> >>>> (PAGE_SIZE-1), so prandom_u32_max(PAGE_SIZE) should yield the same
> >>>> thing? Is that accurate? And holds across platforms (this comes up a
> >>>> few places)? If so, I'll do that for a v4.
> >>>>
> >>>
> >>> On powerpc it is always (from arch/powerpc/include/asm/page.h) :
> >>>
> >>> /*
> >>>    * Subtle: (1 << PAGE_SHIFT) is an int, not an unsigned long. So if we
> >>>    * assign PAGE_MASK to a larger type it gets extended the way we want
> >>>    * (i.e. with 1s in the high bits)
> >>>    */
> >>> #define PAGE_MASK      (~((1 << PAGE_SHIFT) - 1))
> >>>
> >>> #define PAGE_SIZE        (1UL << PAGE_SHIFT)
> >>>
> >>>
> >>> So it would work I guess.
> >>
> >> But taking into account that sp must remain 16 bytes aligned, would it
> >> be better to do something like ?
> >>
> >> 	sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
> >>
> >> 	return sp;
> > 
> > Does this assume that sp is already aligned at the beginning of the
> > function? I'd assume from the function's name that this isn't the
> > case?
> 
> Ah you are right, I overlooked it.

So I think to stay on the safe side, I'm going to go with
`prandom_u32_max(PAGE_SIZE)`. Sound good?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"x86@kernel.org" <x86@kernel.org>, "Jan Kara" <jack@suse.cz>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"KP Singh" <kpsingh@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Andreas Noever" <andreas.noever@gmail.com>,
	"WANG Xuerui" <kernel@xen0n.name>,
	"Will Deacon" <will@kernel.org>, "Christoph Hellwig" <hch@lst.de>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Helge Deller" <deller@gmx.de>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Hugh Dickins" <hughd@google.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"Jozsef Kadlecsik" <kadlec@netfilter.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Dave Airlie" <airlied@redhat.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Pablo Neira Ayuso" <pablo@netfilter.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Marco Elver" <elver@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Borislav Petkov" <bp@alien8.de>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Jens Axboe" <axboe@kernel.dk>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"Florian Westphal" <fw@strlen.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Chuck Lever" <chuck.lever@oracle.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"Jan Kara" <jack@suse.com>, "Thomas Graf" <tgraf@suug.ch>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 3/5] treewide: use get_random_u32() when possible
Date: Fri, 7 Oct 2022 08:07:58 -0600	[thread overview]
Message-ID: <Y0Ayvov/KQmrIwTS@zx2c4.com> (raw)
In-Reply-To: <501b0fc3-6c67-657f-781e-25ee0283bc2e@csgroup.eu>

On Fri, Oct 07, 2022 at 04:57:24AM +0000, Christophe Leroy wrote:
> 
> 
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> >>>> Hi Christophe,
> >>>>
> >>>> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> >>>> <christophe.leroy@csgroup.eu> wrote:
> >>>>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> >>>>>> The prandom_u32() function has been a deprecated inline wrapper around
> >>>>>> get_random_u32() for several releases now, and compiles down to the
> >>>>>> exact same code. Replace the deprecated wrapper with a direct call to
> >>>>>> the real function. The same also applies to get_random_int(), which is
> >>>>>> just a wrapper around get_random_u32().
> >>>>>>
> >>>>>> Reviewed-by: Kees Cook <keescook@chromium.org>
> >>>>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> # for sch_cake
> >>>>>> Acked-by: Chuck Lever <chuck.lever@oracle.com> # for nfsd
> >>>>>> Reviewed-by: Jan Kara <jack@suse.cz> # for ext4
> >>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >>>>>> ---
> >>>>>
> >>>>>> diff --git a/arch/powerpc/kernel/process.c
> >>>>>> b/arch/powerpc/kernel/process.c
> >>>>>> index 0fbda89cd1bb..9c4c15afbbe8 100644
> >>>>>> --- a/arch/powerpc/kernel/process.c
> >>>>>> +++ b/arch/powerpc/kernel/process.c
> >>>>>> @@ -2308,6 +2308,6 @@ void notrace __ppc64_runlatch_off(void)
> >>>>>>     unsigned long arch_align_stack(unsigned long sp)
> >>>>>>     {
> >>>>>>         if (!(current->personality & ADDR_NO_RANDOMIZE) &&
> >>>>>> randomize_va_space)
> >>>>>> -             sp -= get_random_int() & ~PAGE_MASK;
> >>>>>> +             sp -= get_random_u32() & ~PAGE_MASK;
> >>>>>>         return sp & ~0xf;
> >>>>>
> >>>>> Isn't that a candidate for prandom_u32_max() ?
> >>>>>
> >>>>> Note that sp is deemed to be 16 bytes aligned at all time.
> >>>>
> >>>> Yes, probably. It seemed non-trivial to think about, so I didn't. But
> >>>> let's see here... maybe it's not too bad:
> >>>>
> >>>> If PAGE_MASK is always ~(PAGE_SIZE-1), then ~PAGE_MASK is
> >>>> (PAGE_SIZE-1), so prandom_u32_max(PAGE_SIZE) should yield the same
> >>>> thing? Is that accurate? And holds across platforms (this comes up a
> >>>> few places)? If so, I'll do that for a v4.
> >>>>
> >>>
> >>> On powerpc it is always (from arch/powerpc/include/asm/page.h) :
> >>>
> >>> /*
> >>>    * Subtle: (1 << PAGE_SHIFT) is an int, not an unsigned long. So if we
> >>>    * assign PAGE_MASK to a larger type it gets extended the way we want
> >>>    * (i.e. with 1s in the high bits)
> >>>    */
> >>> #define PAGE_MASK      (~((1 << PAGE_SHIFT) - 1))
> >>>
> >>> #define PAGE_SIZE        (1UL << PAGE_SHIFT)
> >>>
> >>>
> >>> So it would work I guess.
> >>
> >> But taking into account that sp must remain 16 bytes aligned, would it
> >> be better to do something like ?
> >>
> >> 	sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
> >>
> >> 	return sp;
> > 
> > Does this assume that sp is already aligned at the beginning of the
> > function? I'd assume from the function's name that this isn't the
> > case?
> 
> Ah you are right, I overlooked it.

So I think to stay on the safe side, I'm going to go with
`prandom_u32_max(PAGE_SIZE)`. Sound good?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"Andreas Noever" <andreas.noever@gmail.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Dave Airlie" <airlied@redhat.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Florian Westphal" <fw@strlen.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Helge Deller" <deller@gmx.de>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Hugh Dickins" <hughd@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Jan Kara" <jack@suse.com>, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jozsef Kadlecsik" <kadlec@netfilter.org>,
	"KP Singh" <kpsingh@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Marco Elver" <elver@google.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Pablo Neira Ayuso" <pablo@netfilter.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Russell King" <linux@armlinux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Thomas Graf" <tgraf@suug.ch>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"WANG Xuerui" <kernel@xen0n.name>,
	"Will Deacon" <will@kernel.org>,
	"Yury Norov" <yury.norov@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Chuck Lever" <chuck.lever@oracle.com>, "Jan Kara" <jack@suse.cz>
Subject: Re: [PATCH v3 3/5] treewide: use get_random_u32() when possible
Date: Fri, 7 Oct 2022 08:07:58 -0600	[thread overview]
Message-ID: <Y0Ayvov/KQmrIwTS@zx2c4.com> (raw)
In-Reply-To: <501b0fc3-6c67-657f-781e-25ee0283bc2e@csgroup.eu>

On Fri, Oct 07, 2022 at 04:57:24AM +0000, Christophe Leroy wrote:
> 
> 
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> >>>> Hi Christophe,
> >>>>
> >>>> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> >>>> <christophe.leroy@csgroup.eu> wrote:
> >>>>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> >>>>>> The prandom_u32() function has been a deprecated inline wrapper around
> >>>>>> get_random_u32() for several releases now, and compiles down to the
> >>>>>> exact same code. Replace the deprecated wrapper with a direct call to
> >>>>>> the real function. The same also applies to get_random_int(), which is
> >>>>>> just a wrapper around get_random_u32().
> >>>>>>
> >>>>>> Reviewed-by: Kees Cook <keescook@chromium.org>
> >>>>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> # for sch_cake
> >>>>>> Acked-by: Chuck Lever <chuck.lever@oracle.com> # for nfsd
> >>>>>> Reviewed-by: Jan Kara <jack@suse.cz> # for ext4
> >>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >>>>>> ---
> >>>>>
> >>>>>> diff --git a/arch/powerpc/kernel/process.c
> >>>>>> b/arch/powerpc/kernel/process.c
> >>>>>> index 0fbda89cd1bb..9c4c15afbbe8 100644
> >>>>>> --- a/arch/powerpc/kernel/process.c
> >>>>>> +++ b/arch/powerpc/kernel/process.c
> >>>>>> @@ -2308,6 +2308,6 @@ void notrace __ppc64_runlatch_off(void)
> >>>>>>     unsigned long arch_align_stack(unsigned long sp)
> >>>>>>     {
> >>>>>>         if (!(current->personality & ADDR_NO_RANDOMIZE) &&
> >>>>>> randomize_va_space)
> >>>>>> -             sp -= get_random_int() & ~PAGE_MASK;
> >>>>>> +             sp -= get_random_u32() & ~PAGE_MASK;
> >>>>>>         return sp & ~0xf;
> >>>>>
> >>>>> Isn't that a candidate for prandom_u32_max() ?
> >>>>>
> >>>>> Note that sp is deemed to be 16 bytes aligned at all time.
> >>>>
> >>>> Yes, probably. It seemed non-trivial to think about, so I didn't. But
> >>>> let's see here... maybe it's not too bad:
> >>>>
> >>>> If PAGE_MASK is always ~(PAGE_SIZE-1), then ~PAGE_MASK is
> >>>> (PAGE_SIZE-1), so prandom_u32_max(PAGE_SIZE) should yield the same
> >>>> thing? Is that accurate? And holds across platforms (this comes up a
> >>>> few places)? If so, I'll do that for a v4.
> >>>>
> >>>
> >>> On powerpc it is always (from arch/powerpc/include/asm/page.h) :
> >>>
> >>> /*
> >>>    * Subtle: (1 << PAGE_SHIFT) is an int, not an unsigned long. So if we
> >>>    * assign PAGE_MASK to a larger type it gets extended the way we want
> >>>    * (i.e. with 1s in the high bits)
> >>>    */
> >>> #define PAGE_MASK      (~((1 << PAGE_SHIFT) - 1))
> >>>
> >>> #define PAGE_SIZE        (1UL << PAGE_SHIFT)
> >>>
> >>>
> >>> So it would work I guess.
> >>
> >> But taking into account that sp must remain 16 bytes aligned, would it
> >> be better to do something like ?
> >>
> >> 	sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
> >>
> >> 	return sp;
> > 
> > Does this assume that sp is already aligned at the beginning of the
> > function? I'd assume from the function's name that this isn't the
> > case?
> 
> Ah you are right, I overlooked it.

So I think to stay on the safe side, I'm going to go with
`prandom_u32_max(PAGE_SIZE)`. Sound good?

Jason

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"x86@kernel.org" <x86@kernel.org>, "Jan Kara" <jack@suse.cz>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"KP Singh" <kpsingh@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Andreas Noever" <andreas.noever@gmail.com>,
	"WANG Xuerui" <kernel@xen0n.name>,
	"Will Deacon" <will@kernel.org>, "Christoph Hellwig" <hch@lst.de>,
	"linux-s390@vger. kernel.org" <linux-s390@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"Helge Deller" <deller@gmx.de>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Hugh Dickins" <hughd@google.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"Jozsef Kadlecsik" <kadlec@netfilter.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Dave Airlie" <airlied@redhat.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Pablo Neira Ayuso" <pablo@netfilter.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Marco Elver" <elver@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Toke Høiland-Jørgensen" <toke@t>
Subject: Re: [PATCH v3 3/5] treewide: use get_random_u32() when possible
Date: Fri, 7 Oct 2022 08:07:58 -0600	[thread overview]
Message-ID: <Y0Ayvov/KQmrIwTS@zx2c4.com> (raw)
In-Reply-To: <501b0fc3-6c67-657f-781e-25ee0283bc2e@csgroup.eu>

On Fri, Oct 07, 2022 at 04:57:24AM +0000, Christophe Leroy wrote:
> 
> 
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> >>>> Hi Christophe,
> >>>>
> >>>> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> >>>> <christophe.leroy@csgroup.eu> wrote:
> >>>>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> >>>>>> The prandom_u32() function has been a deprecated inline wrapper around
> >>>>>> get_random_u32() for several releases now, and compiles down to the
> >>>>>> exact same code. Replace the deprecated wrapper with a direct call to
> >>>>>> the real function. The same also applies to get_random_int(), which is
> >>>>>> just a wrapper around get_random_u32().
> >>>>>>
> >>>>>> Reviewed-by: Kees Cook <keescook@chromium.org>
> >>>>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> # for sch_cake
> >>>>>> Acked-by: Chuck Lever <chuck.lever@oracle.com> # for nfsd
> >>>>>> Reviewed-by: Jan Kara <jack@suse.cz> # for ext4
> >>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >>>>>> ---
> >>>>>
> >>>>>> diff --git a/arch/powerpc/kernel/process.c
> >>>>>> b/arch/powerpc/kernel/process.c
> >>>>>> index 0fbda89cd1bb..9c4c15afbbe8 100644
> >>>>>> --- a/arch/powerpc/kernel/process.c
> >>>>>> +++ b/arch/powerpc/kernel/process.c
> >>>>>> @@ -2308,6 +2308,6 @@ void notrace __ppc64_runlatch_off(void)
> >>>>>>     unsigned long arch_align_stack(unsigned long sp)
> >>>>>>     {
> >>>>>>         if (!(current->personality & ADDR_NO_RANDOMIZE) &&
> >>>>>> randomize_va_space)
> >>>>>> -             sp -= get_random_int() & ~PAGE_MASK;
> >>>>>> +             sp -= get_random_u32() & ~PAGE_MASK;
> >>>>>>         return sp & ~0xf;
> >>>>>
> >>>>> Isn't that a candidate for prandom_u32_max() ?
> >>>>>
> >>>>> Note that sp is deemed to be 16 bytes aligned at all time.
> >>>>
> >>>> Yes, probably. It seemed non-trivial to think about, so I didn't. But
> >>>> let's see here... maybe it's not too bad:
> >>>>
> >>>> If PAGE_MASK is always ~(PAGE_SIZE-1), then ~PAGE_MASK is
> >>>> (PAGE_SIZE-1), so prandom_u32_max(PAGE_SIZE) should yield the same
> >>>> thing? Is that accurate? And holds across platforms (this comes up a
> >>>> few places)? If so, I'll do that for a v4.
> >>>>
> >>>
> >>> On powerpc it is always (from arch/powerpc/include/asm/page.h) :
> >>>
> >>> /*
> >>>    * Subtle: (1 << PAGE_SHIFT) is an int, not an unsigned long. So if we
> >>>    * assign PAGE_MASK to a larger type it gets extended the way we want
> >>>    * (i.e. with 1s in the high bits)
> >>>    */
> >>> #define PAGE_MASK      (~((1 << PAGE_SHIFT) - 1))
> >>>
> >>> #define PAGE_SIZE        (1UL << PAGE_SHIFT)
> >>>
> >>>
> >>> So it would work I guess.
> >>
> >> But taking into account that sp must remain 16 bytes aligned, would it
> >> be better to do something like ?
> >>
> >> 	sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
> >>
> >> 	return sp;
> > 
> > Does this assume that sp is already aligned at the beginning of the
> > function? I'd assume from the function's name that this isn't the
> > case?
> 
> Ah you are right, I overlooked it.

So I think to stay on the safe side, I'm going to go with
`prandom_u32_max(PAGE_SIZE)`. Sound good?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>,
	"Andreas Noever" <andreas.noever@gmail.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Dave Airlie" <airlied@redhat.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Florian Westphal" <fw@strlen.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Helge Deller" <deller@gmx.de>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Hugh Dickins" <hughd@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Jan Kara" <jack@suse.com>, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jozsef Kadlecsik" <kadlec@netfilter.org>,
	"KP Singh" <kpsingh@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Marco Elver" <elver@google.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Pablo Neira Ayuso" <pablo@netfilter.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Russell King" <linux@armlinux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Thomas Graf" <tgraf@suug.ch>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"WANG Xuerui" <kernel@xen0n.name>,
	"Will Deacon" <will@kernel.org>,
	"Yury Norov" <yury.norov@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Chuck Lever" <chuck.lever@oracle.com>, "Jan Kara" <jack@suse.cz>
Subject: Re: [PATCH v3 3/5] treewide: use get_random_u32() when possible
Date: Fri, 7 Oct 2022 08:07:58 -0600	[thread overview]
Message-ID: <Y0Ayvov/KQmrIwTS@zx2c4.com> (raw)
In-Reply-To: <501b0fc3-6c67-657f-781e-25ee0283bc2e@csgroup.eu>

On Fri, Oct 07, 2022 at 04:57:24AM +0000, Christophe Leroy wrote:
> 
> 
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> >>>> Hi Christophe,
> >>>>
> >>>> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> >>>> <christophe.leroy@csgroup.eu> wrote:
> >>>>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> >>>>>> The prandom_u32() function has been a deprecated inline wrapper around
> >>>>>> get_random_u32() for several releases now, and compiles down to the
> >>>>>> exact same code. Replace the deprecated wrapper with a direct call to
> >>>>>> the real function. The same also applies to get_random_int(), which is
> >>>>>> just a wrapper around get_random_u32().
> >>>>>>
> >>>>>> Reviewed-by: Kees Cook <keescook@chromium.org>
> >>>>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> # for sch_cake
> >>>>>> Acked-by: Chuck Lever <chuck.lever@oracle.com> # for nfsd
> >>>>>> Reviewed-by: Jan Kara <jack@suse.cz> # for ext4
> >>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >>>>>> ---
> >>>>>
> >>>>>> diff --git a/arch/powerpc/kernel/process.c
> >>>>>> b/arch/powerpc/kernel/process.c
> >>>>>> index 0fbda89cd1bb..9c4c15afbbe8 100644
> >>>>>> --- a/arch/powerpc/kernel/process.c
> >>>>>> +++ b/arch/powerpc/kernel/process.c
> >>>>>> @@ -2308,6 +2308,6 @@ void notrace __ppc64_runlatch_off(void)
> >>>>>>     unsigned long arch_align_stack(unsigned long sp)
> >>>>>>     {
> >>>>>>         if (!(current->personality & ADDR_NO_RANDOMIZE) &&
> >>>>>> randomize_va_space)
> >>>>>> -             sp -= get_random_int() & ~PAGE_MASK;
> >>>>>> +             sp -= get_random_u32() & ~PAGE_MASK;
> >>>>>>         return sp & ~0xf;
> >>>>>
> >>>>> Isn't that a candidate for prandom_u32_max() ?
> >>>>>
> >>>>> Note that sp is deemed to be 16 bytes aligned at all time.
> >>>>
> >>>> Yes, probably. It seemed non-trivial to think about, so I didn't. But
> >>>> let's see here... maybe it's not too bad:
> >>>>
> >>>> If PAGE_MASK is always ~(PAGE_SIZE-1), then ~PAGE_MASK is
> >>>> (PAGE_SIZE-1), so prandom_u32_max(PAGE_SIZE) should yield the same
> >>>> thing? Is that accurate? And holds across platforms (this comes up a
> >>>> few places)? If so, I'll do that for a v4.
> >>>>
> >>>
> >>> On powerpc it is always (from arch/powerpc/include/asm/page.h) :
> >>>
> >>> /*
> >>>    * Subtle: (1 << PAGE_SHIFT) is an int, not an unsigned long. So if we
> >>>    * assign PAGE_MASK to a larger type it gets extended the way we want
> >>>    * (i.e. with 1s in the high bits)
> >>>    */
> >>> #define PAGE_MASK      (~((1 << PAGE_SHIFT) - 1))
> >>>
> >>> #define PAGE_SIZE        (1UL << PAGE_SHIFT)
> >>>
> >>>
> >>> So it would work I guess.
> >>
> >> But taking into account that sp must remain 16 bytes aligned, would it
> >> be better to do something like ?
> >>
> >> 	sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
> >>
> >> 	return sp;
> > 
> > Does this assume that sp is already aligned at the beginning of the
> > function? I'd assume from the function's name that this isn't the
> > case?
> 
> Ah you are right, I overlooked it.

So I think to stay on the safe side, I'm going to go with
`prandom_u32_max(PAGE_SIZE)`. Sound good?

Jason

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

  reply	other threads:[~2022-10-07 14:08 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 16:53 [PATCH v3 0/5] treewide cleanup of random integer usage Jason A. Donenfeld
2022-10-06 16:53 ` Jason A. Donenfeld
2022-10-06 16:53 ` Jason A. Donenfeld
2022-10-06 16:53 ` Jason A. Donenfeld
2022-10-06 16:53 ` Jason A. Donenfeld
2022-10-06 16:53 ` [PATCH v3 1/5] treewide: use prandom_u32_max() when possible Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53 ` [PATCH v3 2/5] treewide: use get_random_{u8,u16}() " Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53 ` [PATCH v3 3/5] treewide: use get_random_u32() " Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 17:21   ` Christophe Leroy
2022-10-06 17:21     ` Christophe Leroy
2022-10-06 17:21     ` Christophe Leroy
2022-10-06 17:21     ` Christophe Leroy
2022-10-06 17:24     ` Jason A. Donenfeld
2022-10-06 17:24       ` Jason A. Donenfeld
2022-10-06 17:24       ` Jason A. Donenfeld
2022-10-06 17:24       ` Jason A. Donenfeld
2022-10-06 17:24       ` Jason A. Donenfeld
2022-10-06 17:31       ` Christophe Leroy
2022-10-06 17:31         ` Christophe Leroy
2022-10-06 17:31         ` Christophe Leroy
2022-10-06 17:31         ` Christophe Leroy
2022-10-06 17:31         ` Christophe Leroy
2022-10-06 17:42         ` Christophe Leroy
2022-10-06 17:42           ` Christophe Leroy
2022-10-06 17:42           ` Christophe Leroy
2022-10-06 17:42           ` Christophe Leroy
2022-10-06 17:42           ` Christophe Leroy
2022-10-06 23:36           ` Jason A. Donenfeld
2022-10-06 23:36             ` Jason A. Donenfeld
2022-10-06 23:36             ` Jason A. Donenfeld
2022-10-06 23:36             ` Jason A. Donenfeld
2022-10-06 23:36             ` Jason A. Donenfeld
2022-10-07  4:57             ` Christophe Leroy
2022-10-07  4:57               ` Christophe Leroy
2022-10-07  4:57               ` Christophe Leroy
2022-10-07  4:57               ` Christophe Leroy
2022-10-07  4:57               ` Christophe Leroy
2022-10-07 14:07               ` Jason A. Donenfeld [this message]
2022-10-07 14:07                 ` Jason A. Donenfeld
2022-10-07 14:07                 ` Jason A. Donenfeld
2022-10-07 14:07                 ` Jason A. Donenfeld
2022-10-07 14:07                 ` Jason A. Donenfeld
2022-10-07 17:12                 ` Kees Cook
2022-10-07 17:12                   ` Kees Cook
2022-10-07 17:12                   ` Kees Cook
2022-10-07 17:12                   ` Kees Cook
2022-10-07 17:56                   ` Jason A. Donenfeld
2022-10-07 17:56                     ` Jason A. Donenfeld
2022-10-07 17:56                     ` Jason A. Donenfeld
2022-10-07 17:56                     ` Jason A. Donenfeld
2022-10-07 17:56                     ` Jason A. Donenfeld
2022-10-08 21:53                     ` David Laight
2022-10-08 21:53                       ` David Laight
2022-10-08 21:53                       ` David Laight
2022-10-08 21:53                       ` David Laight
2022-10-08 21:53                       ` David Laight
2022-10-09  2:57                       ` Jason A. Donenfeld
2022-10-09  2:57                         ` Jason A. Donenfeld
2022-10-09  2:57                         ` Jason A. Donenfeld
2022-10-09  2:57                         ` Jason A. Donenfeld
2022-10-09  2:57                         ` Jason A. Donenfeld
2022-10-07  9:14           ` David Laight
2022-10-07  9:14             ` David Laight
2022-10-07  9:14             ` David Laight
2022-10-07  9:14             ` David Laight
2022-10-07  9:14             ` David Laight
2022-10-07  9:26   ` Mika Westerberg
2022-10-07  9:26     ` Mika Westerberg
2022-10-07  9:26     ` Mika Westerberg
2022-10-07  9:26     ` Mika Westerberg
2022-10-07  9:26     ` Mika Westerberg
2022-10-06 16:53 ` [PATCH v3 4/5] treewide: use get_random_bytes " Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 17:22   ` Christophe Leroy
2022-10-06 17:22     ` Christophe Leroy
2022-10-06 17:22     ` Christophe Leroy
2022-10-06 17:22     ` Christophe Leroy
2022-10-06 17:22     ` Christophe Leroy
2022-10-07  3:09   ` Bagas Sanjaya
2022-10-07  3:09     ` Bagas Sanjaya
2022-10-07  3:09     ` Bagas Sanjaya
2022-10-07  3:09     ` Bagas Sanjaya
2022-10-07  3:09     ` Bagas Sanjaya
2022-10-07  3:23     ` Jason A. Donenfeld
2022-10-07  3:23       ` Jason A. Donenfeld
2022-10-07  3:23       ` Jason A. Donenfeld
2022-10-07  3:23       ` Jason A. Donenfeld
2022-10-07  3:23       ` Jason A. Donenfeld
2022-10-06 16:53 ` [PATCH v3 5/5] prandom: remove unused functions Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-06 16:53   ` Jason A. Donenfeld
2022-10-07  9:11 ` [PATCH v3 0/5] treewide cleanup of random integer usage Ulf Hansson
2022-10-07  9:11   ` Ulf Hansson
2022-10-07  9:11   ` Ulf Hansson
2022-10-07  9:11   ` Ulf Hansson
2022-10-07  9:11   ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0Ayvov/KQmrIwTS@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=airlied@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreas.noever@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=christoph.boehmwalder@linbit.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=chuck.lever@oracle.com \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=fw@strlen.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=jejb@linux.ibm.com \
    --cc=jgg@ziepe.ca \
    --cc=johannes@sipsolutions.net \
    --cc=kadlec@netfilter.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kernel@xen0n.name \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=patches@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=richard@nod.at \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tgraf@suug.ch \
    --cc=toke@toke.dk \
    --cc=tsbogend@alpha.franken.de \
    --cc=tytso@mit.edu \
    --cc=ulf.hansson@linaro.org \
    --cc=vigneshr@ti.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.