LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Tobin C. Harding" <email@example.com>
To: "Theodore Y. Ts'o" <firstname.lastname@example.org>,
Linus Torvalds <email@example.com>,
Randy Dunlap <firstname.lastname@example.org>,
Steven Rostedt <email@example.com>,
Kees Cook <firstname.lastname@example.org>,
Anna-Maria Gleixner <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>
Subject: Re: [PATCH v3 0/4] enable early printing of hashed pointers
Date: Fri, 4 May 2018 13:50:29 +1000 [thread overview]
Message-ID: <20180504035029.GB3712@eros> (raw)
On Thu, May 03, 2018 at 10:23:49PM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 04, 2018 at 09:07:37AM +1000, Tobin C. Harding wrote:
> > Currently if an attempt is made to print a pointer before there is
> > enough entropy then '(____ptrval____)' is printed. This makes debugging
> > stack traces during early boot difficult.
> > It was observed that we can relax the requirement for cryptographically
> > secure hashing when debugging while still maintaining pointer hashing
> > behaviour. This allows kernels to be debugged without developers
> > relying on different pointer printing behavior.
> > Using the hw RNG if available solves this problem for those machines
> > that have a hardware RNG, we would like to solve it for _all_ machines.
> > Patch 1 - Whitespace fixes.
> > Patch 2 - Fix get_random_bytes_arch()
> > Patch 3 - Use hw RNG for pointer hashing if available (by default).
> > Patch 4 - Use insecure hashing with command line option 'debug_early_boot'.
> What tree are these patches going in? It seems to be equally split
> between random and core kernel code. I'm happy taking it in via the
> random tree, or if it goes in some other patch (I've already ack'ed
> the random changes). I just want to make sure other folks aren't
> assuming I was going take the patches, while I was assuming it would
> go to Linus some other way.
Thanks for verifying this Ted, I was wondering the same thing. Perhaps
this set should be split up, patch 4 is not related to the first three.
Assuming no comments come in over the next few days it looks like people
are ok with the first 3 patches, perhaps you could take those through
your tree (I can resend separately if easier for you). I could then
re-spin the final patch a few more times and perhaps Andrew would take
it through his tree?
Feel free to violently correct me, I'm still learning the ins-and-outs
of the patch pathway to Linus.
prev parent reply other threads:[~2018-05-04 3:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 23:07 Tobin C. Harding
2018-05-03 23:07 ` [PATCH v3 1/4] random: Fix whitespace pre random-bytes work Tobin C. Harding
2018-05-03 23:07 ` [PATCH v3 2/4] random: Return nbytes filled from hw RNG Tobin C. Harding
2018-05-03 23:07 ` [PATCH v3 3/4] vsprintf: Use hw RNG for ptr_key Tobin C. Harding
2018-05-03 23:07 ` [PATCH v3 4/4] vsprintf: Add command line option debug_early_boot Tobin C. Harding
2018-05-04 0:09 ` Steven Rostedt
2018-05-04 2:23 ` [PATCH v3 0/4] enable early printing of hashed pointers Theodore Y. Ts'o
2018-05-04 3:50 ` Tobin C. Harding [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH v3 0/4] enable early printing of hashed pointers' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).