Messages in this thread | | | Date | Thu, 30 Nov 2017 08:08:48 +1100 | From | "Tobin C. Harding" <> | Subject | Re: [GIT PULL] hash addresses printed with %p |
| |
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 <me@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.
| |