On Fri, 2020-02-28 at 14:47 +0800, Jason Yan wrote: > > 在 2020/2/28 13:53, Scott Wood 写道: > > On Wed, 2020-02-26 at 16:18 +0800, Jason Yan wrote: > > > Hi Daniel, > > > > > > 在 2020/2/26 15:16, Daniel Axtens 写道: > > > > Maybe replacing the REG format string in KASLR mode would be > > > > sufficient? > > > > > > > > > > Most archs have removed the address printing when dumping stack. Do we > > > really have to print this? > > > > > > If we have to do this, maybe we can use "%pK" so that they will be > > > hidden from unprivileged users. > > > > I've found the addresses to be useful, especially if I had a way to dump > > the > > stack data itself. Wouldn't the register dump also be likely to give away > > the > > addresses? > > If we have to print the address, then kptr_restrict and dmesg_restrict > must be set properly so that unprivileged users cannot see them. And how does that work with crash dumps that could be from any context? dmesg_restrict is irrelevant as it just controls who can see the dmesg, not what goes into it. kptr_restrict=1 will only get the value if you're not in any sort of IRQ, *and* if the crashing context happened to have CAP_SYSLOG. No other value of kptr_restrict will ever get you the raw value. > > > > I don't see any debug setting for %pK (or %p) to always print the actual > > address (closest is kptr_restrict=1 but that only works in certain > > contexts)... from looking at the code it seems it hashes even if kaslr is > > entirely disabled? Or am I missing something? > > > > Yes, %pK (or %p) always hashes whether kaslr is disabled or not. So if > we want the real value of the address, we cannot use it. But if you only > want to distinguish if two pointers are the same, it's ok. Am I the only one that finds this a bit crazy? If you want to lock a system down then fine, but why wage war on debugging even when there's no randomization going on? Comparing two pointers for equality is not always adequate. -Scott
