From: Petr Mladek <pmladek@suse.com>
To: "Uwe Kleine-König" <uwe@kleine-koenig.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
linux-kernel@vger.kernel.org, Ilya Dryomov <idryomov@gmail.com>,
Kees Cook <keescook@chromium.org>,
"Tobin C . Harding" <me@tobin.cc>
Subject: Re: [PATCH 1/3] lib/test_printf: Clean up test of hashed pointers
Date: Mon, 2 Mar 2020 11:24:27 +0100 [thread overview]
Message-ID: <20200302102427.brzxardpanwqlyfy@pathway.suse.cz> (raw)
In-Reply-To: <bdb7d995-f16f-335c-c06a-b6732dcbbfa2@kleine-koenig.org>
On Thu 2020-02-27 15:30:51, Uwe Kleine-König wrote:
> Hello Petr,
>
> On 2/27/20 2:01 PM, Petr Mladek wrote:
> > The commit ad67b74d2469d9b82a ("printk: hash addresses printed with %p")
> > helps to prevent leaking kernel addresses.
> >
> > The testing of this functionality is a bit problematic because the output
> > depends on a random key that is generated during boot. Though, it is
> > still possible to check some aspects:
> >
> > + output string length
> > + hash differs from the original pointer value
> > + top half bits are zeroed on 64-bit systems
>
> Is "hash differs from the original pointer value" a valid check?
> Depending on the random value and the actual pointer I can imagine a
> valid match. Such a match is unlikely but not necessarily bogus, is it?
Yes, there is a small risk or false negative.
It might be possible to try if the problem persist with PTR+1 value or
so. But I am not sure if it is worth it.
The problem is only on 32-bit systems. The chance is really small.
I have added a comment above the check. It can be found via the added
error message.
Note that this check has been there even before in plain_hash().
But it was worse because it was without any comment or error message.
Best Regards,
Petr
next prev parent reply other threads:[~2020-03-02 10:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 13:01 [PATCH 0/3] lib/test_printf: Clean up basic pointer testing Petr Mladek
2020-02-27 13:01 ` [PATCH 1/3] lib/test_printf: Clean up test of hashed pointers Petr Mladek
2020-02-27 14:30 ` Uwe Kleine-König
2020-03-02 10:24 ` Petr Mladek [this message]
2020-03-03 11:14 ` Rasmus Villemoes
2020-02-27 13:01 ` [PATCH 2/3] lib/test_printf: Fix structure of basic pointer tests Petr Mladek
2020-02-27 13:01 ` [PATCH 3/3] lib/test_printf: Clean up invalid pointer value testing Petr Mladek
2020-03-03 7:24 ` [PATCH 0/3] lib/test_printf: Clean up basic pointer testing Sergey Senozhatsky
2020-03-03 9:22 ` Petr Mladek
2020-03-03 10:32 ` Sergey Senozhatsky
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=20200302102427.brzxardpanwqlyfy@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=idryomov@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=me@tobin.cc \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=uwe@kleine-koenig.org \
/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.