lkml.org 
[lkml]   [2013]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] x86, kernel: make dump_pagetables a tristate
From
On Mon, Jul 1, 2013 at 9:35 AM, Arjan van de Ven <arjan@linux.intel.com> wrote:
> On 7/1/2013 8:55 AM, Kees Cook wrote:
>>
>> On Mon, Jul 1, 2013 at 6:58 AM, Arjan van de Ven <arjan@linux.intel.com>
>> wrote:
>>>
>>> On 6/29/2013 9:05 PM, Kees Cook wrote:
>>>>
>>>>
>>>> Being able to examine page tables is handy, so make this a module that
>>>> can be loaded as needed.
>>>
>>>
>>> I personally don't think this is a good idea due to the various
>>> security/etc implications of this feature... should really just
>>> be off for non-debug kernels, not "off unless you load the module"
>>
>>
>> I struggled with this too, but I couldn't come up with any reason that
>> made sense. If a system is running without modules_disabled, this code
>> is still loadable:
>>
>> https://www.outflux.net/blog/archives/2011/04/27/non-executable-kernel-memory-progress/
>>
>> The root user just needs to look at /proc/kallsyms before passing an
>> argument. So having it NOT a tristate doesn't actually change anything
>> except make it awkward to get it done.
>>
>> If a system is running with verified modules, then just not
>> signing/including ptdump makes it unavailable. And running with
>> modules_disabled, obviously, blocks it.
>>
>>>> +#ifdef CONFIG_X86_64
>>>> +EXPORT_SYMBOL_GPL(init_level4_pgt);
>>>> +#else
>>>> +EXPORT_SYMBOL_GPL(swapper_pg_dir);
>>>> +#endif
>>>
>>>
>>> like these really have no business in any module
>>
>>
>> Well, that's why I took me 2 years to send this patch. Those symbols
>> shouldn't be used outside of page table debugging, so it didn't really
>> seem upstreamable. However, now that I need to do regular examination
>> of the page tables, I wanted to do it without the hacky thing above. I
>> want to do at will on our test images (we use the same kernel for
>> production and test, but production images leave out the test modules,
>> etc).
>
>
> the code is small...
> how about making it a command line option to enable?
>
> rather than making something like this a module

Hmm. The Chrome OS build infrastructure frowns on making cmdline
changes between production and testing images. I could probably do it
this way, but it'd be more of a pain to maintain than just carrying
the hack patch.

Since there's no actual loss to system security by making this a
module, how about we allow it to be a tristate and continue to
recommend it being "n" by default?

As far as the export goes, could ptdump read cr3 instead of needing a
symbol export?

-Kees

--
Kees Cook
Chrome OS Security


\
 
 \ /
  Last update: 2013-07-01 19:41    [W:3.110 / U:1.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site