On 1/26/21 5:59 PM, Timur Tabi wrote: > On 1/26/21 10:47 AM, Vlastimil Babka wrote: >> Given Linus' current stance later in this thread, could we revive the idea of a >> boot time option, or at least a CONFIG (I assume a runtime toggle would be too >> much, even if limited to !kernel_lockdown:) , that would disable all hashing? >> It would be really useful for a development/active debugging, as evidenced >> below. Thanks. > > So you're saying: > > if CONFIG_PRINTK_NEVER_HASH is disabled, then %p prints hashed addresses and %px > prints unhashed. > > If CONFIG_PRINTK_NEVER_HASH is enabled, then %p and %px both print unhashed > addresses. Minimally, yes. KASLR is configurable like this, so why not printing of kernel pointers? > I like this idea, and I would accept it as a solution if I had to, but I still > would also like for an option for print_hex_dump() to print unhashed addresses > even when CONFIG_PRINTK_NEVER_HASH is disabled. I can't always recompile the > entire kernel for my testing purposes. Yeah, obviously a boot option would be nicer. The discussion Kees pointed to [1] seemed to be about papering over problems with entropy? Not about making development/debugging easier. But I understand it was not the first time and I didn't check the older ones. > The only drawback to this idea is: what happens if distros start enabling > CONFIG_PRINTK_NEVER_HASH by default, just because it makes debugging easier? There's tons of other options already where the choice is between security and performance, and distros make their choice (including, again, KASLR itself). Pointer hashing would be just another one. If it was a boot option, I would personally be for leaving hashing enabled by default, with opt-in boot option to disable it. Then if I'm instructing a user to boot the distro kernel (without recompile) with e.g. slub_debug or debug_pagealloc or page_owner in order to debug some issue, I would additionally instruct them to add the 'no_pointer_hashing' parameter. [1] https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@xxxxxxxxxxxxxx/
