Thread (23 messages) 23 messages, 7 authors, 2022-10-09

Re: [PATCH v3 3/5] treewide: use get_random_u32() when possible

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2022-10-06 23:37:13
Also in: dri-devel, kernel-janitors, linux-block, linux-crypto, linux-doc, linux-fsdevel, linux-media, linux-mips, linux-mm, linux-mmc, linux-nvme, linux-patches, linux-rdma, linux-s390, linux-um, linux-usb, linux-wireless, lkml, loongarch, netdev, sparclinux

On 10/6/22, Christophe Leroy [off-list ref] wrote:

Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
quoted

Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
quoted
Hi Christophe,

On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
[off-list ref] wrote:
quoted
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
quoted
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 <redacted>
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>
---
quoted
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?

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help