On Wed, Nov 29, 2017 at 11:22:29AM -0800, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 8:59 PM, Tobin C. Harding <m...@tobin.cc> wrote: > > > > git://github.com/tcharding/linux.git tags/printk-hash-pointer-4.15-rc2 > > Bah.
Sorry for creating extra work for you. > What I didn't realize until after pulling this and testing, is that it > completely breaks '%pK'. If you haven't wasted enough time on this can you tell me what you mean by 'completely breaks %pK'? If I am at fault I do not want to repeat the same mistake again. I have just re-run my tests and it passes so something must be wrong with my tests or method. I wrote a module to print various pointers using %pK (same module that tests the hashing stuff), built the kernel with the patch set applied then booted the kernel in a VM and inserted the module (kptr_restrict==0). Confirmed that addresses were displayed. Then I set kptr_restrict to 2 and re-inserted the module. Confirmed that pointers were zeroed out when printed with %pK. > We've marked various sensitive pointers with %pK, but that is now > _less_ secure than %p is, since it doesn't do the hashing because of > how you refactored the %pK code out of 'pointer()' into its own > function. Oh, I think I get it. You mean that it is better to hash the address for %pK (kpt_restrict==0) than to zero it out? > So now %pK ends up using the plain "number()" function. Reading > through the series I hadn't noticed that the refactoring ended up > messing with that. > > I'll fix it up somehow. (I saw the fix in the next email) thanks, Tobin.
