Re: [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/27/21 11:11 AM, Petr Mladek wrote:
> On Tue 2021-01-26 12:40:32, Steven Rostedt wrote:
>> On Tue, 26 Jan 2021 12:39:12 -0500
>> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>> 
>> > On Tue, 26 Jan 2021 11:30:02 -0600
>> > Timur Tabi <timur@xxxxxxxxxx> wrote:
>> > 
>> > > On 1/26/21 11:14 AM, Vlastimil Babka wrote:  
>> > > > If it was a boot option, I would personally be for leaving hashing enabled by
>> > > > default, with opt-in boot option to disable it.    
>> > > 
>> > > A boot option would solve all my problems.  I wouldn't need to recompile 
>> > > the kernel, and it would apply to all variations of printk.  
>> > 
>> > Should it be called "make-printk-insecure"
> 
> Nit: This makes me feel that printk() might break (block) the system.
>      Please, make it more clear that it is about unveiling some secret
>      information, something like:
> 
> 	"non-secret-printk"
> 	"non-confidental-printk"
> 	"unretricted-printk"
> 
> I do not mind about the words order or using the
> "make-printk-non-secret" form.

Yeah, let's not be overly dramatic here.

>> And even if we make this a boot time option, perhaps we should still
>> include that nasty dmesg notice, which will let people know that the kernel
>> has unhashed values.
> 
> +1

If it's what it takes to have that option, fine :)

> Best Regards,
> Petr
> 





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux