login
Search
Theodore Ts'o proposed a new patch allowing a userland program to taint the kernel by writing to /proc/sys/kernel/tainted, "to be used when userspace is potentially doing something naughty that might compromise the kernel." When asked when this would be needed, Theodore went on to explain, "the problem is that the Real-Time Specification for Java (RTSJ) **requires** that the JVM provide class functions which provide direct access to physical memory; all physical memory. In fact, the RTSJ compliance test explicitly checks for this; it requires that you give the compliance test the address of a few hundred megs of physical memory for the test.". He went on to add, "I was so unhappy about being forced by the RTSJ specification to do this insane thing that I wanted to make sure that if it were ever used, it would set a TAINT flag to warn people that just about anything unsane could have happened, and the system's stability was at the mercy of the competence of Java application programmers.".
The conversation that followed proposed having the tainting happen automatically when a process opens /dev/mem for writing. The notion that running X would then taint the kernel was briefly discussed, and Theodore replied, "it may make sense to have an explicit taint flag which means direct access to memory, via /dev/mem or otherwise, with exceptions for I/O mapped memory not claimed by a device driver (and of course X until it is fixed, or never, whichever comes first)."
From: Theodore Ts'o [email blocked] To: akpm Subject: [PATCH] Add user taint flag Date: Sun, 21 May 2006 19:04:32 -0400 Allow taint flags to be set from userspace by writing to /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be used when userspace is potentially doing something naughty that might compromise the kernel. This will allow support personnel to ask further questions about what may have caused the user taint flag to have been set. (For example, by examining the logs of the JVM to determine what evil things might have been lurking in the hearts of Java programs. :-) Signed-off-by: "Theodore Ts'o" [email blocked]
From: Andrew Morton [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 03:36:44 -0700 "Theodore Ts'o" [email blocked] wrote: > > > Allow taint flags to be set from userspace by writing to > /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be > used when userspace is potentially doing something naughty that might > compromise the kernel. What sort of userspace actions are you thinking of here? And how is other userspace to detect what the naughty userspace is doing? Someone's done something and you're not telling us what it was ;) > > ... > > +/* > + * Taint values can only be increased > + */ > +int proc_dointvec_taint(ctl_table *table, int write, struct file *filp, > + void __user *buffer, size_t *lenp, loff_t *ppos) > +{ > + int op; > + > + if (!capable(CAP_SYS_ADMIN)) { > + return -EPERM; > + } Aren't the /proc file permissions sufficient?
From: Theodore Tso [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 14:33:52 -0400 On Mon, May 22, 2006 at 03:36:44AM -0700, Andrew Morton wrote: > "Theodore Ts'o" [email blocked] wrote: > > Allow taint flags to be set from userspace by writing to > > /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be > > used when userspace is potentially doing something naughty that might > > compromise the kernel. > > What sort of userspace actions are you thinking of here? You don't really want to know. No, really. :-) > And how is other userspace to detect what the naughty userspace is doing? When the kernel returns a panic or an Oops, then we'll know something bad had happened.... > Someone's done something and you're not telling us what it was ;) OK, OK. See the attached patch. Note especially the NOT-Signed-off-by.... I am not expecting nor requesting this to get anywhere near mainline. The problem is that the Real-Time Specification for Java (RTSJ) **requires** that the JVM provide class functions which provide direct access to physical memory; all physical memory. In fact, the RTSJ compliance test explicitly checks for this; it requires that you give the compliance test the address of a few hundred megs of physical memory for the test. The absolutely hilarious bit about all of this is that the same customer who wants RTSJ compliance because of federal procurement regulations is also interested in using SELinux. We've told them that actually using this feature of RTSJ is incompatible with their security needs, and that on production systems they should delete the rmem module from their configured systems. However, it must be present in order to demonstrate RTSJ compliance. Blame Sun for this insanity, especially since there is no documented way to actually determine which physical memory address are safe to use with this facility --- so any use of this particular RTSJ class *guarantees* that the Java program will be completely non-portable. So if something does actually use the rmem device, it the rmem module (see below) sets the user TAINT flag, for the same reason that we want to set the taint flag after loading a module from ATI or NVidia. Technically speaking, we don't need to be able to set it via the /proc interface, but it seems like a useful thing that could be useful for other applications. The basic idea as far as debuging is concerned when someone posts an oops on LKML is the same as any other taint flag; if you see that it came from a tainted kernel, you know not to waste any time looking at the oops. If this goes to our support people, they will know to ask for the JVM log files, which will show the use of this nasty RTSJ capability, and they will know to ask the right questions. > > + if (!capable(CAP_SYS_ADMIN)) { > > + return -EPERM; > > + } > > Aren't the /proc file permissions sufficient? Well, that would mean that anyone with CAP_DAC_OVERRIDE would be able to raise the taint level. I think CAP_SYS_ADMIN is actually the better capability; we do something similar with /proc/sys/kernel/cap-bound, which requires CAP_SYS_MODULE. - Ted These two kernel modules are needed for use by the TCK conformance test which tests the JVM's RTSJ implementation. Unfortunately, RTSJ requires that Java programs have direct access to physical memory, and /dev/mem does not allow mmap to work to anything beyond I/O mapped memory regions on the x86 platform. Since this is a spectacularly bad idea (so much for write once, debug everywhere) and could potentially destablize the kernel, set the TAINT_USER flag if available. Signed-off-by: "Theodore Ts'o" [email blocked] Index: 2.6.15-rc6/drivers/char/Kconfig =================================================================== --- 2.6.15-rc6.orig/drivers/char/Kconfig 2005-12-24 15:52:06.000000000 -0500 +++ 2.6.15-rc6/drivers/char/Kconfig 2005-12-24 15:52:13.000000000 -0500 @@ -1013,5 +1013,23 @@ sysfs directory, /sys/devices/platform/telco_clock, with a number of files for controlling the behavior of this hardware. +config ALLOC_RTSJ_MEM + tristate "RTSJ-specific hack to reserve memory" + default m + help + The RTSJ TCK conformance test requires reserving some physical + memory for testing /dev/rmem. + +config RMEM + tristate "Access to physical memory via /dev/rmem" + default m + help + The /dev/mem device only allows mmap() memory availble to + I/O mapped memory; it does not allow access to "real" + physical memory. The /dev/rmem device is a hack which does + allow access to physical memory. We use this instead of + patching /dev/mem because we don't expect this functionality + to ever be accepted into mainline. + endmenu Index: 2.6.15-rc6/drivers/char/Makefile =================================================================== --- 2.6.15-rc6.orig/drivers/char/Makefile 2005-12-24 15:52:06.000000000 -0500 +++ 2.6.15-rc6/drivers/char/Makefile 2005-12-24 15:52:13.000000000 -0500 @@ -93,6 +93,10 @@ obj-$(CONFIG_HANGCHECK_TIMER) += hangcheck-timer.o obj-$(CONFIG_TCG_TPM) += tpm/ + +obj-$(CONFIG_ALLOC_RTSJ_MEM) += alloc_rtsj_mem.o +obj-$(CONFIG_RMEM) += rmem.o + # Files generated that shall be removed upon make clean clean-files := consolemap_deftbl.c defkeymap.c qtronixmap.c Index: 2.6.15-rc6/drivers/char/alloc_rtsj_mem.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ 2.6.15-rc6/drivers/char/alloc_rtsj_mem.c 2005-12-24 18:10:57.000000000 -0500 @@ -0,0 +1,88 @@ +/* + * alloc_rtsj_mem.c -- Hack to allocate some memory + * + * Copyright (C) 2005 by Theodore Ts'o + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/types.h> +#include <linux/sysctl.h> +#include <linux/bootmem.h> + +#include <asm/io.h> + +MODULE_AUTHOR("Theodore Tso"); +MODULE_DESCRIPTION("RTSJ alloc memory"); +MODULE_LICENSE("GPL"); + +static void *mem = 0; +int size = 0, addr = 0; + +module_param(size, int, 0444); +module_param(addr, int, 0444); + +static void __exit shutdown_module(void) +{ + kfree(mem); +} + +#ifndef MODULE +void __init alloc_rtsj_mem_early_setup(void) +{ + if (size > PAGE_SIZE*2) { + mem = alloc_bootmem(size); + if (mem) { + printk(KERN_INFO "alloc_rtsj_mem: got %d bytes " + "using alloc_bootmem\n", size); + } else { + printk(KERN_INFO "alloc_rtsj_mem: failed to " + "get %d bytes from alloc_bootmem\n", size); + } + } +} +#endif + +static int __init startup_module(void) +{ + static char test_string[] = "The BOFH: Servicing users the way the " + "military\n\tservices targets for 15 years.\n"; + + if (!size) + return 0; + + if (!mem) { + mem = kmalloc(size, GFP_KERNEL); + if (mem) { + printk(KERN_INFO "alloc_rtsj_mem: got %d bytes " + "using kmalloc\n", size); + } else { + printk(KERN_ERR "alloc_rtsj_mem: failed to get " + "%d bytes using kmalloc\n", size); + return -ENOMEM; + } + } + memcpy(mem, test_string, min(sizeof(test_string), (size_t) size)); + addr = virt_to_phys(mem); + return 0; +} + +module_init(startup_module); +module_exit(shutdown_module); + Index: 2.6.15-rc6/drivers/char/rmem.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ 2.6.15-rc6/drivers/char/rmem.c 2005-12-24 15:52:13.000000000 -0500 @@ -0,0 +1,135 @@ +/* + * Rmem - REALLY simple memory mapping demonstration. + * + * Copyright (C) 2005 by Theodore Ts'o + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <linux/config.h> +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/init.h> + +#include <linux/kernel.h> +#include <linux/slab.h> +#include <linux/fs.h> +#include <linux/errno.h> +#include <linux/types.h> +#include <linux/mm.h> +#include <linux/kdev_t.h> +#include <asm/page.h> +#include <linux/cdev.h> +#include <linux/device.h> + +static int rmem_major = 0; +module_param(rmem_major, int, 0444); + +static struct class *rmem_class; + +MODULE_AUTHOR("Theodore Ts'o"); +MODULE_LICENSE("GPL"); + +struct page *rmem_vma_nopage(struct vm_area_struct *vma, + unsigned long address, int *type) +{ + struct page *pageptr; + unsigned long offset = vma->vm_pgoff << PAGE_SHIFT; + unsigned long physaddr = address - vma->vm_start + offset; + unsigned long pageframe = physaddr >> PAGE_SHIFT; + + if (!pfn_valid(pageframe)) + return NOPAGE_SIGBUS; + pageptr = pfn_to_page(pageframe); + get_page(pageptr); + if (type) + *type = VM_FAULT_MINOR; + return pageptr; +} + +static struct vm_operations_struct rmem_nopage_vm_ops = { + .nopage = rmem_vma_nopage, +}; + +static int rmem_nopage_mmap(struct file *filp, struct vm_area_struct *vma) +{ + unsigned long offset = vma->vm_pgoff << PAGE_SHIFT; + + if (offset >= __pa(high_memory) || (filp->f_flags & O_SYNC)) + vma->vm_flags |= VM_IO; + vma->vm_flags |= VM_RESERVED; + vma->vm_ops = &rmem_nopage_vm_ops; +#ifdef TAINT_USER + add_taint(TAINT_USER); +#endif + return 0; +} + +static struct file_operations rmem_nopage_ops = { + .owner = THIS_MODULE, + .mmap = rmem_nopage_mmap, +}; + +static struct cdev rmem_cdev = { + .kobj = {.name = "rmem", }, + .owner = THIS_MODULE, +}; + +static int __init rmem_init(void) +{ + int result; + dev_t dev = MKDEV(rmem_major, 0); + + /* Figure out our device number. */ + if (rmem_major) + result = register_chrdev_region(dev, 1, "rmem"); + else { + result = alloc_chrdev_region(&dev, 0, 1, "rmem"); + rmem_major = MAJOR(dev); + } + if (result < 0) { + printk(KERN_WARNING "rmem: unable to get major %d\n", rmem_major); + return result; + } + if (rmem_major == 0) + rmem_major = result; + + cdev_init(&rmem_cdev, &rmem_nopage_ops); + result = cdev_add(&rmem_cdev, dev, 1); + if (result) { + printk (KERN_NOTICE "Error %d adding /dev/rmem", result); + kobject_put(&rmem_cdev.kobj); + unregister_chrdev_region(dev, 1); + return 1; + } + + rmem_class = class_create(THIS_MODULE, "rmem"); + class_device_create(rmem_class, dev, NULL, "rmem"); + + return 0; +} + + +static void __exit rmem_cleanup(void) +{ + cdev_del(&rmem_cdev); + unregister_chrdev_region(MKDEV(rmem_major, 0), 1); + class_destroy(rmem_class); +} + + +module_init(rmem_init); +module_exit(rmem_cleanup); Index: 2.6.15-rc6/init/main.c =================================================================== --- 2.6.15-rc6.orig/init/main.c 2005-12-24 15:52:13.000000000 -0500 +++ 2.6.15-rc6/init/main.c 2005-12-24 19:17:49.000000000 -0500 @@ -100,6 +100,12 @@ #else static inline void acpi_early_init(void) { } #endif +#ifdef CONFIG_ALLOC_RTSJ_MEM +extern void alloc_rtsj_mem_early_setup(void); +#else +static inline void alloc_rtsj_mem_early_setup(void) { } +#endif + #ifdef CONFIG_TC extern void tc_init(void); @@ -509,6 +515,7 @@ } #endif vfs_caches_init_early(); + alloc_rtsj_mem_early_setup(); mem_init(); kmem_cache_init(); setup_per_cpu_pageset();
From: "Stephen C. Tweedie" [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 13:17:46 +0100 Hi, On Sun, 2006-05-21 at 19:04 -0400, Theodore Ts'o wrote: > Allow taint flags to be set from userspace by writing to > /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be > used when userspace is potentially doing something naughty that might > compromise the kernel. This will allow support personnel to ask further > questions about what may have caused the user taint flag to have been > set. (For example, by examining the logs of the JVM to determine what > evil things might have been lurking in the hearts of Java programs. :-) That's going to lead to a head-scratching fishing expedition from support people wondering just why this flag was set. At the very least we should force the caller to supply a log message explaining *why* the taint flag is being set and printk it at KERN_ERR loglevel or higher; so the user API would be echo $log > /proc/sys/kernel/taint rather than manipulating the bit directly. --Stephen
From: Arjan van de Ven [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 16:14:36 +0200 On Sun, 2006-05-21 at 19:04 -0400, Theodore Ts'o wrote: > Allow taint flags to be set from userspace by writing to > /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be > used when userspace is potentially doing something naughty that might > compromise the kernel. we should then patch the /dev/mem driver or something to set this :) (well and possibly give it an exception for now for PCI space until the X people fix their stuff to use the proper sysfs stuff)
From: Theodore Tso [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 21:11:23 -0400 On Mon, May 22, 2006 at 04:14:36PM +0200, Arjan van de Ven wrote: > On Sun, 2006-05-21 at 19:04 -0400, Theodore Ts'o wrote: > > Allow taint flags to be set from userspace by writing to > > /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be > > used when userspace is potentially doing something naughty that might > > compromise the kernel. > > we should then patch the /dev/mem driver or something to set this :) > (well and possibly give it an exception for now for PCI space until the > X people fix their stuff to use the proper sysfs stuff) It may make sense to have an explicit taint flag which means direct access to memory, via /dev/mem or otherwise, with exceptions for I/O mapped memory not claimed by a device driver (and of course X until it is fixed, or never, whichever comes first). As I've mentioned, the original reason why I did this was because I needed to mmap physical memory, which at the time when I originally did things, /dev/mem didn't support except for the I/O mapped memory range, and I assumed that any attempt to enhance /dev/mem's mmap() capabilities in a patch intended for mainline wouldn't be looked at as a friendly act. In fact, I was so unhappy about being forced by the RTSJ specification to do this insane thing that I wanted to make sure that if it were ever used, it would set a TAINT flag to warn people that just about anything unsane could have happened, and the system's stability was at the mercy of the competence of Java application programmers. :-) - Ted
From: Alan Cox [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 15:35:48 +0100 On Llu, 2006-05-22 at 16:14 +0200, Arjan van de Ven wrote: > we should then patch the /dev/mem driver or something to set this :) > (well and possibly give it an exception for now for PCI space until the > X people fix their stuff to use the proper sysfs stuff) /dev/mem is used for all sorts of sane things including DMIdecode. Tainting on it isn't terribly useful. Mind you this whole user taint patch seems bogus as it can only be set by root owned processes so doesn't appear to do the job it is intended for - perhaps Ted can explain ? What X needs btw is mmap on PCI mmio bars, teach the X mapping code to use those instead of /dev/mem is a simple matter of coding as the right abstractions are in the tree already. It would need the kernel to also provide a /dev/isa mapping however. Alan
From: Arjan van de Ven [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 16:37:54 +0200 On Mon, 2006-05-22 at 15:35 +0100, Alan Cox wrote: > On Llu, 2006-05-22 at 16:14 +0200, Arjan van de Ven wrote: > > we should then patch the /dev/mem driver or something to set this :) > > (well and possibly give it an exception for now for PCI space until the > > X people fix their stuff to use the proper sysfs stuff) > > /dev/mem is used for all sorts of sane things including DMIdecode. > Tainting on it isn't terribly useful. I meant taint-on-writable/write, dmi and others map it read only which is obviously different
From: Valdis.Kletnieks@vt.edu Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 10:29:21 -0400 On Mon, 22 May 2006 15:35:48 BST, Alan Cox said: > On Llu, 2006-05-22 at 16:14 +0200, Arjan van de Ven wrote: > > we should then patch the /dev/mem driver or something to set this :) > > (well and possibly give it an exception for now for PCI space until the > > X people fix their stuff to use the proper sysfs stuff) > > /dev/mem is used for all sorts of sane things including DMIdecode. > Tainting on it isn't terribly useful. Mind you this whole user taint > patch seems bogus as it can only be set by root owned processes so > doesn't appear to do the job it is intended for - perhaps Ted can > explain ? Taint on write to /dev/mem, perhaps? I don't think DMIdecode needs to scribble on /dev/mem, does it? (Figure if a userspace program runs OK on a recent Fedora or RedHat kernel, it doesn't need to scribble on /dev/mem too much, because the vast majority of it is lopped out via a patch....)
From: Jan Engelhardt [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Mon, 22 May 2006 20:56:50 +0200 (MEST) >> > we should then patch the /dev/mem driver or something to set this :) >> > (well and possibly give it an exception for now for PCI space until the >> > X people fix their stuff to use the proper sysfs stuff) >> >> /dev/mem is used for all sorts of sane things including DMIdecode. >> Tainting on it isn't terribly useful. Mind you this whole user taint >> patch seems bogus as it can only be set by root owned processes so >> doesn't appear to do the job it is intended for - perhaps Ted can >> explain ? > >Taint on write to /dev/mem, perhaps? I don't think DMIdecode needs to >scribble on /dev/mem, does it? (Figure if a userspace program runs OK > lm-sensors looks like it pokes (writes) to /dev/mem trying to figure out some devices. >on a recent Fedora or RedHat kernel, it doesn't need to scribble on /dev/mem >too much, because the vast majority of it is lopped out via a patch....) > And what about /dev/port? That can also screw up things, so should probably be included in the taint unless I am missing something. Jan Engelhardt
From: Stefan Seyfried [email blocked] Subject: Re: [PATCH] Add user taint flag Date: Wed, 24 May 2006 15:43:38 +0200 On Mon, May 22, 2006 at 03:36:44AM -0700, Andrew Morton wrote: > "Theodore Ts'o" [email blocked] wrote: > > > > Allow taint flags to be set from userspace by writing to > > /proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be > > used when userspace is potentially doing something naughty that might > > compromise the kernel. > > What sort of userspace actions are you thinking of here? I also thought about tainting the kernel from a userspace program that messes with runtime power management - switch off and on various devices at runtime (which is not recommended by anyone) - and you are clearly in Unsupportedland. So yes, this is a good idea (although i just would have written a module without MODULE_LICENSE that just printk'ed "Tainting kernel, we will use runtime power management" on load.) -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \ -- Leonard Cohen
