Removal of the kernel code/data/bss resources does break kexec/kdump

[Kees Cook]

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
>>> thing.
>>
>> 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
> right.
>
> 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!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security