On Wed, Jun 20, 2018 at 09:09:49PM -0700, Randy Dunlap wrote: > On 06/20/2018 08:15 PM, Tobin C. Harding wrote: > > On Wed, Jun 20, 2018 at 04:38:05PM -0700, Randy Dunlap wrote: > >> On 06/20/2018 04:22 PM, Tobin C. Harding wrote: > >>> On Wed, Jun 20, 2018 at 03:36:44PM -0700, Randy Dunlap wrote: > >>>> On 06/20/2018 03:30 PM, Tobin C. Harding wrote: > >>>>> On Wed, Jun 20, 2018 at 09:09:49AM -0700, Randy Dunlap wrote: > >>>>>> On 06/19/2018 09:20 PM, Tobin C. Harding wrote: > >>>>>>> Currently printing [hashed] pointers requires enough entropy to be > >>>>>>> available. Early in the boot sequence this may not be the case > >>>>>>> resulting in a dummy string '(____ptrval____)' being printed. This > >>>>>>> makes debugging the early boot sequence difficult. We can relax the > >>>>>>> requirement to use cryptographically secure hashing during debugging. > >>>>>>> This enables debugging while keeping development/production kernel > >>>>>>> behaviour the same. > >>>>>>> > >>>>>>> If new command line option debug_boot_weak_hash is enabled use > >>>>>>> cryptographically insecure hashing and hash pointer value immediately. > >>>>>>> > >>>>>>> Signed-off-by: Tobin C. Harding <m...@tobin.cc> > >>>>>>> Reviewed-by: Steven Rostedt (VMware) <rost...@goodmis.org> > >>>>>>> --- > >>>>>>> Documentation/admin-guide/kernel-parameters.txt | 9 +++++++++ > >>>>>>> lib/vsprintf.c | 17 > >>>>>>> +++++++++++++++++ > >>>>>>> 2 files changed, 26 insertions(+) > >>>>>>> > >>>>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt > >>>>>>> b/Documentation/admin-guide/kernel-parameters.txt > >>>>>>> index 638342d0a095..a116fc0366b0 100644 > >>>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt > >>>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt > >>>>>>> @@ -748,6 +748,15 @@ > >>>>>>> > >>>>>>> debug [KNL] Enable kernel debugging (events log > >>>>>>> level). > >>>>>>> > >>>>>>> + debug_boot_weak_hash > >>>>>>> + [KNL] Enable printing pointers early in the boot > >>>>>>> + sequence. If enabled, we use a weak hash > >>>>>>> instead of > >>>>>>> + siphash to hash pointers. Use this option if > >>>>>>> you need > >>>>>>> + to see pointer values during early boot (i.e > >>>>>>> you are > >>>>>> > >>>>>> maybe: > >>>>>> to see hashed pointer values > >>>>>> i.e., not raw pointers. > >>>>> > >>>>> You cannot see 'raw pointers' anyways? > >>>> > >>>> only if using %px ? > >>>> > >>>> Maybe it's just terminology. I don't consider a hashed value as a > >>>> pointer value. > >>>> It's just a key or handle or some other number, but it's not a pointer. > >>>> > >>>>>> > >>>>>>> + seeing instances of '(___ptrval___)'). > >>>>>>> + Cryptographically insecure, please do not use on > >>>>>>> + production kernels. > >>>>> > >>>>> thanks for the review, I don't quiet see how to use your suggestion to > >>>>> make the text clearer. If you still feel this change is needed perhaps > >>>>> you could write so I understand i.e 'Use this option if ...' > >>>> > >>>> > >>>> OK, if you are good with it, I am too. :) > >>> > >>> I get you know. I agree, how about this > >>> > >>> [KNL] Enable printing pointers early in the boot > >>> sequence. If enabled, we use a weak hash instead of > >>> siphash to hash pointers. Use this option if you need > >>> to print pointers with %px during early boot > >>> (i.e you are seeing instances of '(___ptrval___)'). > >>> Cryptographically insecure, please do not use on > >>> production kernels. > >> > >> Sorry, I'm still confused by this paragraph. It seems to say two different > >> things. > > > > My bad, I got totally confused myself. After all this time you would > > think I knew which specifier hashed and which didn't. My apologies, > > how about this: > > > > [KNL] Enable printing [hashed] pointers early in > > the boot sequence. If enabled, we use a weak hash > > instead of siphash to hash pointers. Use this option if > > you are seeing instances of '(___ptrval___)') and need > > to see a value (hashed pointer) instead. > > Cryptographically > > insecure, please do not use on production kernels. > > > > > > thanks for your patience, > > Tobin. > > Yes, that's good. Thanks.
Awesome, v9 on it's way :) thanks, Tobin.
