Removal of the kernel code/data/bss resources does break kexec/kdump
keescook at chromium.org
Thu Apr 14 21:41:58 PDT 2016
On Thu, Apr 14, 2016 at 6:02 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Thu, Apr 14, 2016 at 1:27 PM, Emrah Demir <ed at abdsec.com> wrote:
>> On 2016-04-14 13:40, Linus Torvalds wrote:
>>> Actually, %pK is horrible in /proc and /sys files, and does the wrong
>> I agree with that, but for now there is no way to make things right in /proc
>> or /sys.
> Well, there is now.
> I've pushed out my attempt at fixing things properly. Please check
> that kexec works - and if kexec ends up reading that file as non-root,
> I don't know what to say/do.
> Here's the three relevant cases:
> cat /proc/iomem
> sudo cat /proc/iomem
> sudo cat < /proc/iomem
> and two of them will now show the resource ranges as just plain
> zeroes. But yes, it needed extra infrastructure to be able to get this
> Note that while %pK is always wrong in /proc and /sys files, in this
> case it would have been particularly wrong, since the values can be
> 64-bit even on a 32-bit architecture, so trying to show them as
> pointers would have gotten not just the capability handling wrong, it
> would have truncated a 64-bit value to 32 bits in that case.
Yup, that's why I was saying I was going to try to cook something up
for -next. It isn't a trivial change. :) Thanks for fixing it up!
Chrome OS & Brillo Security
More information about the kexec