Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, Jun 07, 2018 at 10:00:02AM -0400, Theodore Y. Ts'o wrote: > On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > > I'm also happy to take the whole patch series through the random tree > > > if everyone else is OK with it. > > > > Looks like every one is happy (or silent) now Ted, can you please take > > this version through your tree. > > Ok, it's now on the random.git tree. I'm going to give it a few days > of soak time in linux-next, and then I'll push it to Linus before the > end of the merge window. Great, thanks. Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, Jun 07, 2018 at 10:00:02AM -0400, Theodore Y. Ts'o wrote: > On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > > I'm also happy to take the whole patch series through the random tree > > > if everyone else is OK with it. > > > > Looks like every one is happy (or silent) now Ted, can you please take > > this version through your tree. > > Ok, it's now on the random.git tree. I'm going to give it a few days > of soak time in linux-next, and then I'll push it to Linus before the > end of the merge window. Great, thanks. Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > I'm also happy to take the whole patch series through the random tree > > if everyone else is OK with it. > > Looks like every one is happy (or silent) now Ted, can you please take > this version through your tree. Ok, it's now on the random.git tree. I'm going to give it a few days of soak time in linux-next, and then I'll push it to Linus before the end of the merge window. - Ted
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > I'm also happy to take the whole patch series through the random tree > > if everyone else is OK with it. > > Looks like every one is happy (or silent) now Ted, can you please take > this version through your tree. Ok, it's now on the random.git tree. I'm going to give it a few days of soak time in linux-next, and then I'll push it to Linus before the end of the merge window. - Ted
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, May 28, 2018 at 09:59:15AM -0400, Theodore Y. Ts'o wrote: > On Mon, May 28, 2018 at 11:46:38AM +1000, Tobin C. Harding wrote: > > > > During the versions of this set I have been totally confused about which > > patches go through which tree. This version again puts all 4 patches > > together in the hope they will go through Andrew's tree. > > I'm also happy to take the whole patch series through the random tree > if everyone else is OK with it. > > Thoughts? Looks like every one is happy (or silent) now Ted, can you please take this version through your tree. thanks, Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, May 28, 2018 at 09:59:15AM -0400, Theodore Y. Ts'o wrote: > On Mon, May 28, 2018 at 11:46:38AM +1000, Tobin C. Harding wrote: > > > > During the versions of this set I have been totally confused about which > > patches go through which tree. This version again puts all 4 patches > > together in the hope they will go through Andrew's tree. > > I'm also happy to take the whole patch series through the random tree > if everyone else is OK with it. > > Thoughts? Looks like every one is happy (or silent) now Ted, can you please take this version through your tree. thanks, Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Wed, Jun 06, 2018 at 03:02:20PM +0200, Thomas Gleixner wrote: > On Mon, 28 May 2018, Tobin C. Harding wrote: > > > Currently printing pointers early in the boot sequence can result in a > > dummy string '(ptrval)' being printed. While resolving this > > issue it was noticed that we can use the hw RNG if available for hashing > > pointers. > > > > Patch one and two do the ground work to be able to use hw RNG removing > > from get_random_bytes_arch() the call to get_random_bytes() and > > returning the number of bytes of random material successfully returned. > > > > Patch three uses the hw RNG to get keying material if it is available. > > > > Patch four further assists debugging early in the boot sequence for > > machines that do not have a hw RNG by adding a command line option > > 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing > > is used instead of siphash so we can hash at any time. > > > > During the versions of this set I have been totally confused about which > > patches go through which tree. This version again puts all 4 patches > > together in the hope they will go through Andrew's tree. > > > > > > Steve, > > > > Could you please take a quick squiz at the final 2 patches if you get a > > chance. I assumed we are in preemptible context during early_init based > > on your code (and code comment) and called static_branch_disable() > > directly if hw RNG returned keying material. It's a pretty simple > > change but I'd love to get someone else to check I've not noob'ed it. > > early_initcalls() are not that early :) They run in thread context fully > preemtible so calling static_branch_disable() is perfectly fine. Thanks for the explanation. Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Wed, Jun 06, 2018 at 03:02:20PM +0200, Thomas Gleixner wrote: > On Mon, 28 May 2018, Tobin C. Harding wrote: > > > Currently printing pointers early in the boot sequence can result in a > > dummy string '(ptrval)' being printed. While resolving this > > issue it was noticed that we can use the hw RNG if available for hashing > > pointers. > > > > Patch one and two do the ground work to be able to use hw RNG removing > > from get_random_bytes_arch() the call to get_random_bytes() and > > returning the number of bytes of random material successfully returned. > > > > Patch three uses the hw RNG to get keying material if it is available. > > > > Patch four further assists debugging early in the boot sequence for > > machines that do not have a hw RNG by adding a command line option > > 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing > > is used instead of siphash so we can hash at any time. > > > > During the versions of this set I have been totally confused about which > > patches go through which tree. This version again puts all 4 patches > > together in the hope they will go through Andrew's tree. > > > > > > Steve, > > > > Could you please take a quick squiz at the final 2 patches if you get a > > chance. I assumed we are in preemptible context during early_init based > > on your code (and code comment) and called static_branch_disable() > > directly if hw RNG returned keying material. It's a pretty simple > > change but I'd love to get someone else to check I've not noob'ed it. > > early_initcalls() are not that early :) They run in thread context fully > preemtible so calling static_branch_disable() is perfectly fine. Thanks for the explanation. Tobin.
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Wed, Jun 06, 2018 at 03:08:25PM +0200, Anna-Maria Gleixner wrote: > On Tue, 5 Jun 2018, Anna-Maria Gleixner wrote: > > > On Thu, 31 May 2018, Steven Rostedt wrote: > > > > > On Mon, 28 May 2018 11:46:38 +1000 > > > "Tobin C. Harding" wrote: > > > > > > > Steve, > > > > > > Hi Tobin, > > > > > > Sorry for the late reply, I'm currently at a conference and have had > > > little time to read email. > > > > > > > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > > > chance. I assumed we are in preemptible context during early_init based > > > > on your code (and code comment) and called static_branch_disable() > > > > directly if hw RNG returned keying material. It's a pretty simple > > > > change but I'd love to get someone else to check I've not noob'ed it. > > > > > > I can take a look, and perhaps do some tests. But it was Anna-Maria > > > that originally triggered the issue. She's on Cc, perhaps she can try > > > this and see if it works. > > > > I'll test it today - sorry for the delay. > > > > I tested it with command line option enabled. This works early enough > because it works right after early_trace_init(). Awesome, thanks Anna-Maria! Tobin
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Wed, Jun 06, 2018 at 03:08:25PM +0200, Anna-Maria Gleixner wrote: > On Tue, 5 Jun 2018, Anna-Maria Gleixner wrote: > > > On Thu, 31 May 2018, Steven Rostedt wrote: > > > > > On Mon, 28 May 2018 11:46:38 +1000 > > > "Tobin C. Harding" wrote: > > > > > > > Steve, > > > > > > Hi Tobin, > > > > > > Sorry for the late reply, I'm currently at a conference and have had > > > little time to read email. > > > > > > > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > > > chance. I assumed we are in preemptible context during early_init based > > > > on your code (and code comment) and called static_branch_disable() > > > > directly if hw RNG returned keying material. It's a pretty simple > > > > change but I'd love to get someone else to check I've not noob'ed it. > > > > > > I can take a look, and perhaps do some tests. But it was Anna-Maria > > > that originally triggered the issue. She's on Cc, perhaps she can try > > > this and see if it works. > > > > I'll test it today - sorry for the delay. > > > > I tested it with command line option enabled. This works early enough > because it works right after early_trace_init(). Awesome, thanks Anna-Maria! Tobin
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Tue, 5 Jun 2018, Anna-Maria Gleixner wrote: > On Thu, 31 May 2018, Steven Rostedt wrote: > > > On Mon, 28 May 2018 11:46:38 +1000 > > "Tobin C. Harding" wrote: > > > > > Steve, > > > > Hi Tobin, > > > > Sorry for the late reply, I'm currently at a conference and have had > > little time to read email. > > > > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > > chance. I assumed we are in preemptible context during early_init based > > > on your code (and code comment) and called static_branch_disable() > > > directly if hw RNG returned keying material. It's a pretty simple > > > change but I'd love to get someone else to check I've not noob'ed it. > > > > I can take a look, and perhaps do some tests. But it was Anna-Maria > > that originally triggered the issue. She's on Cc, perhaps she can try > > this and see if it works. > > I'll test it today - sorry for the delay. > I tested it with command line option enabled. This works early enough because it works right after early_trace_init(). Thanks, Anna-Maria
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Tue, 5 Jun 2018, Anna-Maria Gleixner wrote: > On Thu, 31 May 2018, Steven Rostedt wrote: > > > On Mon, 28 May 2018 11:46:38 +1000 > > "Tobin C. Harding" wrote: > > > > > Steve, > > > > Hi Tobin, > > > > Sorry for the late reply, I'm currently at a conference and have had > > little time to read email. > > > > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > > chance. I assumed we are in preemptible context during early_init based > > > on your code (and code comment) and called static_branch_disable() > > > directly if hw RNG returned keying material. It's a pretty simple > > > change but I'd love to get someone else to check I've not noob'ed it. > > > > I can take a look, and perhaps do some tests. But it was Anna-Maria > > that originally triggered the issue. She's on Cc, perhaps she can try > > this and see if it works. > > I'll test it today - sorry for the delay. > I tested it with command line option enabled. This works early enough because it works right after early_trace_init(). Thanks, Anna-Maria
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, 28 May 2018, Tobin C. Harding wrote: > Currently printing pointers early in the boot sequence can result in a > dummy string '(ptrval)' being printed. While resolving this > issue it was noticed that we can use the hw RNG if available for hashing > pointers. > > Patch one and two do the ground work to be able to use hw RNG removing > from get_random_bytes_arch() the call to get_random_bytes() and > returning the number of bytes of random material successfully returned. > > Patch three uses the hw RNG to get keying material if it is available. > > Patch four further assists debugging early in the boot sequence for > machines that do not have a hw RNG by adding a command line option > 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing > is used instead of siphash so we can hash at any time. > > During the versions of this set I have been totally confused about which > patches go through which tree. This version again puts all 4 patches > together in the hope they will go through Andrew's tree. > > > Steve, > > Could you please take a quick squiz at the final 2 patches if you get a > chance. I assumed we are in preemptible context during early_init based > on your code (and code comment) and called static_branch_disable() > directly if hw RNG returned keying material. It's a pretty simple > change but I'd love to get someone else to check I've not noob'ed it. early_initcalls() are not that early :) They run in thread context fully preemtible so calling static_branch_disable() is perfectly fine. Thanks, tglx
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, 28 May 2018, Tobin C. Harding wrote: > Currently printing pointers early in the boot sequence can result in a > dummy string '(ptrval)' being printed. While resolving this > issue it was noticed that we can use the hw RNG if available for hashing > pointers. > > Patch one and two do the ground work to be able to use hw RNG removing > from get_random_bytes_arch() the call to get_random_bytes() and > returning the number of bytes of random material successfully returned. > > Patch three uses the hw RNG to get keying material if it is available. > > Patch four further assists debugging early in the boot sequence for > machines that do not have a hw RNG by adding a command line option > 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing > is used instead of siphash so we can hash at any time. > > During the versions of this set I have been totally confused about which > patches go through which tree. This version again puts all 4 patches > together in the hope they will go through Andrew's tree. > > > Steve, > > Could you please take a quick squiz at the final 2 patches if you get a > chance. I assumed we are in preemptible context during early_init based > on your code (and code comment) and called static_branch_disable() > directly if hw RNG returned keying material. It's a pretty simple > change but I'd love to get someone else to check I've not noob'ed it. early_initcalls() are not that early :) They run in thread context fully preemtible so calling static_branch_disable() is perfectly fine. Thanks, tglx
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, 31 May 2018, Steven Rostedt wrote: > On Mon, 28 May 2018 11:46:38 +1000 > "Tobin C. Harding" wrote: > > > Steve, > > Hi Tobin, > > Sorry for the late reply, I'm currently at a conference and have had > little time to read email. > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > chance. I assumed we are in preemptible context during early_init based > > on your code (and code comment) and called static_branch_disable() > > directly if hw RNG returned keying material. It's a pretty simple > > change but I'd love to get someone else to check I've not noob'ed it. > > I can take a look, and perhaps do some tests. But it was Anna-Maria > that originally triggered the issue. She's on Cc, perhaps she can try > this and see if it works. I'll test it today - sorry for the delay. Anna-Maria
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, 31 May 2018, Steven Rostedt wrote: > On Mon, 28 May 2018 11:46:38 +1000 > "Tobin C. Harding" wrote: > > > Steve, > > Hi Tobin, > > Sorry for the late reply, I'm currently at a conference and have had > little time to read email. > > > > > Could you please take a quick squiz at the final 2 patches if you get a > > chance. I assumed we are in preemptible context during early_init based > > on your code (and code comment) and called static_branch_disable() > > directly if hw RNG returned keying material. It's a pretty simple > > change but I'd love to get someone else to check I've not noob'ed it. > > I can take a look, and perhaps do some tests. But it was Anna-Maria > that originally triggered the issue. She's on Cc, perhaps she can try > this and see if it works. I'll test it today - sorry for the delay. Anna-Maria
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, 28 May 2018 11:46:38 +1000 "Tobin C. Harding" wrote: > Steve, Hi Tobin, Sorry for the late reply, I'm currently at a conference and have had little time to read email. > > Could you please take a quick squiz at the final 2 patches if you get a > chance. I assumed we are in preemptible context during early_init based > on your code (and code comment) and called static_branch_disable() > directly if hw RNG returned keying material. It's a pretty simple > change but I'd love to get someone else to check I've not noob'ed it. I can take a look, and perhaps do some tests. But it was Anna-Maria that originally triggered the issue. She's on Cc, perhaps she can try this and see if it works. I'll still pull the patches and add some injections to see how it works. Thanks! -- Steve
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, 28 May 2018 11:46:38 +1000 "Tobin C. Harding" wrote: > Steve, Hi Tobin, Sorry for the late reply, I'm currently at a conference and have had little time to read email. > > Could you please take a quick squiz at the final 2 patches if you get a > chance. I assumed we are in preemptible context during early_init based > on your code (and code comment) and called static_branch_disable() > directly if hw RNG returned keying material. It's a pretty simple > change but I'd love to get someone else to check I've not noob'ed it. I can take a look, and perhaps do some tests. But it was Anna-Maria that originally triggered the issue. She's on Cc, perhaps she can try this and see if it works. I'll still pull the patches and add some injections to see how it works. Thanks! -- Steve
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, May 28, 2018 at 11:46:38AM +1000, Tobin C. Harding wrote: > > During the versions of this set I have been totally confused about which > patches go through which tree. This version again puts all 4 patches > together in the hope they will go through Andrew's tree. I'm also happy to take the whole patch series through the random tree if everyone else is OK with it. Thoughts? - Ted
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Mon, May 28, 2018 at 11:46:38AM +1000, Tobin C. Harding wrote: > > During the versions of this set I have been totally confused about which > patches go through which tree. This version again puts all 4 patches > together in the hope they will go through Andrew's tree. I'm also happy to take the whole patch series through the random tree if everyone else is OK with it. Thoughts? - Ted
[PATCH v6 0/4] enable early printing of hashed pointers
Currently printing pointers early in the boot sequence can result in a dummy string '(ptrval)' being printed. While resolving this issue it was noticed that we can use the hw RNG if available for hashing pointers. Patch one and two do the ground work to be able to use hw RNG removing from get_random_bytes_arch() the call to get_random_bytes() and returning the number of bytes of random material successfully returned. Patch three uses the hw RNG to get keying material if it is available. Patch four further assists debugging early in the boot sequence for machines that do not have a hw RNG by adding a command line option 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing is used instead of siphash so we can hash at any time. During the versions of this set I have been totally confused about which patches go through which tree. This version again puts all 4 patches together in the hope they will go through Andrew's tree. Steve, Could you please take a quick squiz at the final 2 patches if you get a chance. I assumed we are in preemptible context during early_init based on your code (and code comment) and called static_branch_disable() directly if hw RNG returned keying material. It's a pretty simple change but I'd love to get someone else to check I've not noob'ed it. thanks, Tobin. v6 - Rebase on top of Steve's patch (fixing race condition). Uses static branch instead of memory barrier. v5 - Use 'upside-down-xmas-tree' style to declare local variables (Steve) - Added Reviewed-by tag from Steve (patch 2 and 3). v4 - remove last patch of series (command line option patch) v3 - Add __ro_after_init (suggested by Kees). v2 - Use min_t() instead of min() (thanks checkpatch). - Add __must_check to function declaration (thanks Steve). - Use hw RNG by default if available (as originally suggested by Kees). - Add command line option to use cryptographically insecure hashing. If debug_early_boot is enabled use hash_long() instead of siphash (as requested by Steve, and solves original problem for Anna-Maria). - Added Acked-by tag from Ted (patch 1 and 2) Tobin C. Harding (4): random: Fix whitespace pre random-bytes work random: Return nbytes filled from hw RNG vsprintf: Use hw RNG for ptr_key vsprintf: Add command line option debug_boot_weak_hash Documentation/admin-guide/kernel-parameters.txt | 9 drivers/char/random.c | 19 include/linux/random.h | 2 +- lib/vsprintf.c | 30 - 4 files changed, 49 insertions(+), 11 deletions(-) -- 2.7.4
[PATCH v6 0/4] enable early printing of hashed pointers
Currently printing pointers early in the boot sequence can result in a dummy string '(ptrval)' being printed. While resolving this issue it was noticed that we can use the hw RNG if available for hashing pointers. Patch one and two do the ground work to be able to use hw RNG removing from get_random_bytes_arch() the call to get_random_bytes() and returning the number of bytes of random material successfully returned. Patch three uses the hw RNG to get keying material if it is available. Patch four further assists debugging early in the boot sequence for machines that do not have a hw RNG by adding a command line option 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing is used instead of siphash so we can hash at any time. During the versions of this set I have been totally confused about which patches go through which tree. This version again puts all 4 patches together in the hope they will go through Andrew's tree. Steve, Could you please take a quick squiz at the final 2 patches if you get a chance. I assumed we are in preemptible context during early_init based on your code (and code comment) and called static_branch_disable() directly if hw RNG returned keying material. It's a pretty simple change but I'd love to get someone else to check I've not noob'ed it. thanks, Tobin. v6 - Rebase on top of Steve's patch (fixing race condition). Uses static branch instead of memory barrier. v5 - Use 'upside-down-xmas-tree' style to declare local variables (Steve) - Added Reviewed-by tag from Steve (patch 2 and 3). v4 - remove last patch of series (command line option patch) v3 - Add __ro_after_init (suggested by Kees). v2 - Use min_t() instead of min() (thanks checkpatch). - Add __must_check to function declaration (thanks Steve). - Use hw RNG by default if available (as originally suggested by Kees). - Add command line option to use cryptographically insecure hashing. If debug_early_boot is enabled use hash_long() instead of siphash (as requested by Steve, and solves original problem for Anna-Maria). - Added Acked-by tag from Ted (patch 1 and 2) Tobin C. Harding (4): random: Fix whitespace pre random-bytes work random: Return nbytes filled from hw RNG vsprintf: Use hw RNG for ptr_key vsprintf: Add command line option debug_boot_weak_hash Documentation/admin-guide/kernel-parameters.txt | 9 drivers/char/random.c | 19 include/linux/random.h | 2 +- lib/vsprintf.c | 30 - 4 files changed, 49 insertions(+), 11 deletions(-) -- 2.7.4
