[PATCH] x86, kernel: make dump_pagetables a tristate

[PATCH] x86, kernel: make dump_pagetables a tristate

[Kees Cook]

Being able to examine page tables is handy, so make this a module that
can be loaded as needed.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/Kconfig.debug        |    2 +-
 arch/x86/kernel/head.c        |    6 ++++++
 arch/x86/mm/dump_pagetables.c |   13 ++++++++++---
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index c198b7e..a43b7ca 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -70,7 +70,7 @@ config DEBUG_STACKOVERFLOW
 	  If in doubt, say "N".
 
 config X86_PTDUMP
-	bool "Export kernel pagetable layout to userspace via debugfs"
+	tristate "Export kernel pagetable layout to userspace via debugfs"
 	depends on DEBUG_KERNEL
 	select DEBUG_FS
 	---help---
diff --git a/arch/x86/kernel/head.c b/arch/x86/kernel/head.c
index 992f442..871c0ca 100644
--- a/arch/x86/kernel/head.c
+++ b/arch/x86/kernel/head.c
@@ -69,3 +69,9 @@ void __init reserve_ebda_region(void)
 	/* reserve all memory between lowmem and the 1MB mark */
 	memblock_reserve(lowmem, 0x100000 - lowmem);
 }
+
+#ifdef CONFIG_X86_64
+EXPORT_SYMBOL_GPL(init_level4_pgt);
+#else
+EXPORT_SYMBOL_GPL(swapper_pg_dir);
+#endif
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 0002a3a..7a54145 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -340,6 +340,8 @@ static int ptdump_open(struct inode *inode, struct file *filp)
 	return single_open(filp, ptdump_show, NULL);
 }
 
+static struct dentry *pe;
+
 static const struct file_operations ptdump_fops = {
 	.open		= ptdump_open,
 	.read		= seq_read,
@@ -347,9 +349,8 @@ static const struct file_operations ptdump_fops = {
 	.release	= single_release,
 };
 
-static int pt_dump_init(void)
+static int __init pt_dump_init(void)
 {
-	struct dentry *pe;
 
 #ifdef CONFIG_X86_32
 	/* Not a compile-time constant on x86-32 */
@@ -369,7 +370,13 @@ static int pt_dump_init(void)
 	return 0;
 }
 
-__initcall(pt_dump_init);
+static void __exit pt_dump_exit(void)
+{
+	debugfs_remove_recursive(pe);
+}
+
+module_init(pt_dump_init);
+module_exit(pt_dump_exit);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Arjan van de Ven <arjan@linux.intel.com>");
 MODULE_DESCRIPTION("Kernel debugging helper that dumps pagetables");
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

Re: [PATCH] x86, kernel: make dump_pagetables a tristate

[Arjan van de Ven]

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"


> +#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

Re: [PATCH] x86, kernel: make dump_pagetables a tristate

[Kees Cook]

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).

-Kees

--
Kees Cook
Chrome OS Security

Re: [PATCH] x86, kernel: make dump_pagetables a tristate

[Arjan van de Ven]

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

Re: [PATCH] x86, kernel: make dump_pagetables a tristate

[Kees Cook]

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