linux-kernel - Re: [PATCH 0/3] add %pX specifier

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: <CA+55aFwSJ4mJOSBqQ9TQyNc99+x=ZanFHnQjMaQCtF6_KKZPag@mail.gmail.com>
Date:   Thu, 12 Oct 2017 11:37:22 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     "Tobin C. Harding" <me@...in.cc>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        KVM list <kvm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Tycho Andersen <tycho@...ker.com>,
        "Roberts, William C" <william.c.roberts@...el.com>,
        Tejun Heo <tj@...nel.org>,
        Jordan Glover <Golden_Miller83@...tonmail.ch>,
        Greg KH <gregkh@...uxfoundation.org>,
        Petr Mladek <pmladek@...e.com>, Joe Perches <joe@...ches.com>,
        Ian Campbell <ijc@...lion.org.uk>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Chris Fries <cfries@...gle.com>,
        Dave Weinstein <olorin@...gle.com>,
        Daniel Micay <danielmicay@...il.com>,
        Djalal Harouni <tixxdz@...il.com>,
        Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
        Jann Horn <jann@...jh.net>, pbsd-hn@...tonmail.com
Subject: Re: [PATCH 0/3] add %pX specifier

On Wed, Oct 11, 2017 at 3:11 PM, Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> On another topic: the approach we're discussing here is using a PRF
> (pseudo-random function), also known as a keyed hash function. It's
> not reversible; it isn't encryption. Mapping 64-bit inputs to 64-bit
> outputs means there _might_ be collisions.

I really wouldn't worry about it.

In fact, I'd prefer mapping the pointer to a 32-bit value, even on
64-bit architectures. When people use these things for debugging and
for identifying which device node or socket or whatever they are
tracking, we're generally talking a (small) handful of different
devices or whatever.

Tobin did the statistics, most of the %p users are in drivers, and
they tend to be things like identifying *which* ACPI descriptor we're
talking about, or which command/request we're tracing, or which device
we're probing etc.  So _when_ we're talking about identities (as
opposed to when people actually want the true physical device address
or whatever), we're generally talking just a few entries. Maybe tens.

Can we get collisions when unlucky? Sure. But most of the time it's
literally about trying to track the commands to one particular device,
or track one particular command through the debug output. A 32-bit
hash is fine, because if we have so many different things going on at
the same time that you'd have a noticeable risk of collisions, you'd
not depend on debug traces etc anyway, you'd start doing fancier
tracing (ie start filtering using ebpf etc).

> But there is something slightly different that you might be interested
> in: a PRP (psuedo-random permutation), also known as a block cipher.
> In this case, there'd be a 64-bit to 64-bit reversible map, based on a
> secret key, with no collisions. In other words, pointer encryption,
> rather than hashing. Aarch64 has some special instructions for this,
> with the QARMA tweakable block cipher being built-in. Might be fun to
> nerd out about, but I don't know that we actually need this or would
> want the complexity, and probably a PRF like SipHash is sufficient.
> But thought I'd make you aware of the possibility, in case you're
> interested.

My guess would be that something like that might be nice if it would
mean that we'd get hw acceleration for the hashing, and that the
reversibility would be entirely secondary.

But I assume that even when you do have some hardware support for
something like that, the kernel would likely not really be able to use
it, for the simple reason that people would expect it to be used for
other things (and then setup/teardown costs would likely make it more
expensive than just doing the software SipHash() or equivalent). The
kernel use would likely simply be too rare and occasional to warrant
dedicated hardware use.

                     Linus