linux-kernel - Re: Hashed pointer issues

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]

Message-ID: <CAGXu5jLVJxDJcbhrQU5-wduaP+OvePXP8VvCFMrJ47pYD-zaXg@mail.gmail.com>
Date:   Mon, 30 Apr 2018 11:38:42 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "Tobin C. Harding" <me@...in.cc>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Hashed pointer issues

On Mon, Apr 30, 2018 at 10:01 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Apr 30, 2018 at 9:57 AM Linus Torvalds <
> torvalds@...ux-foundation.org> wrote:
>
>> Although in *practice* we'd have tons of entropy on any modern development
>> CPU too, since any new hardware will have the hardware random number
>> generation. Some overly cautious person might not trust it, of course.
>
> In fact, maybe that's the right policy. Avoid a boot-time parameter by just
> saying
>
>   "if you have hardware random number generation, we can fill entropy
> immediately"

Something like this? (Untested.)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 30c0cb8cc9bc..2d8615f14dc9 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1672,9 +1672,8 @@ char *pointer_string(char *buf, char *end, const
void *ptr,
 static bool have_filled_random_ptr_key __read_mostly;
 static siphash_key_t ptr_key __read_mostly;

-static void fill_random_ptr_key(struct random_ready_callback *unused)
+static void ptr_key_ready(void)
 {
-       get_random_bytes(&ptr_key, sizeof(ptr_key));
        /*
         * have_filled_random_ptr_key==true is dependent on get_random_bytes().
         * ptr_to_id() needs to see have_filled_random_ptr_key==true
@@ -1684,14 +1683,28 @@ static void fill_random_ptr_key(struct
random_ready_callback *unused)
        WRITE_ONCE(have_filled_random_ptr_key, true);
 }

+static void fill_random_ptr_key(struct random_ready_callback *unused)
+{
+       get_random_bytes(&ptr_key, sizeof(ptr_key));
+       ptr_key_ready();
+}
+
 static struct random_ready_callback random_ready = {
        .func = fill_random_ptr_key
 };

 static int __init initialize_ptr_random(void)
 {
-       int ret = add_random_ready_callback(&random_ready);
+       int ret;
+
+       /* If we have hw RNG, start hashing immediately. */
+       if (arch_has_random()) {
+               get_random_bytes_arch(&ptr_key, sizeof(ptr_key));
+               ptr_key_ready();
+               return 0;
+       }

+       ret = add_random_ready_callback(&random_ready);
        if (!ret) {
                return 0;
        } else if (ret == -EALREADY) {


>
> No kernel command line needed in practice any more. That's assuming any
> kernel developer will have an IvyBridge or newer.
>
> The "I don't trust my hardware" people can still disable that with
> "nordrand".
>
> Hmm?
>
>                     Linus



-- 
Kees Cook
Pixel Security