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 protected]>
Index: linux-2.6/include/linux/kernel.h
===================================================================
--- linux-2.6.orig/include/linux/kernel.h 2006-04-28 21:16:55.000000000 -0400
+++ linux-2.6/include/linux/kernel.h 2006-05-21 19:00:15.000000000 -0400
@@ -198,6 +198,7 @@
#define TAINT_FORCED_RMMOD (1<<3)
#define TAINT_MACHINE_CHECK (1<<4)
#define TAINT_BAD_PAGE (1<<5)
+#define TAINT_USER (1<<6)
extern void dump_stack(void);
Index: linux-2.6/include/linux/sysctl.h
===================================================================
--- linux-2.6.orig/include/linux/sysctl.h 2006-03-25 21:26:37.000000000 -0500
+++ linux-2.6/include/linux/sysctl.h 2006-05-21 19:00:15.000000000 -0400
@@ -915,6 +915,8 @@
void __user *, size_t *, loff_t *);
extern int proc_dointvec_bset(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
+extern int proc_dointvec_taint(ctl_table *, int, struct file *,
+ void __user *, size_t *, loff_t *);
extern int proc_dointvec_minmax(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
extern int proc_dointvec_jiffies(ctl_table *, int, struct file *,
Index: linux-2.6/kernel/panic.c
===================================================================
--- linux-2.6.orig/kernel/panic.c 2006-04-28 21:16:55.000000000 -0400
+++ linux-2.6/kernel/panic.c 2006-05-21 19:00:15.000000000 -0400
@@ -150,6 +150,7 @@
* 'R' - User forced a module unload.
* 'M' - Machine had a machine check experience.
* 'B' - System has hit bad_page.
+ * 'U' - Userspace-defined naughtiness.
*
* The string is overwritten by the next call to print_taint().
*/
@@ -158,13 +159,14 @@
{
static char buf[20];
if (tainted) {
- snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c",
+ snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c",
tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
tainted & TAINT_FORCED_MODULE ? 'F' : ' ',
tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
tainted & TAINT_FORCED_RMMOD ? 'R' : ' ',
tainted & TAINT_MACHINE_CHECK ? 'M' : ' ',
- tainted & TAINT_BAD_PAGE ? 'B' : ' ');
+ tainted & TAINT_BAD_PAGE ? 'B' : ' ',
+ tainted & TAINT_USER ? 'U' : ' ');
}
else
snprintf(buf, sizeof(buf), "Not tainted");
Index: linux-2.6/kernel/sysctl.c
===================================================================
--- linux-2.6.orig/kernel/sysctl.c 2006-03-25 21:26:38.000000000 -0500
+++ linux-2.6/kernel/sysctl.c 2006-05-21 19:00:15.000000000 -0400
@@ -305,8 +305,8 @@
.procname = "tainted",
.data = &tainted,
.maxlen = sizeof(int),
- .mode = 0444,
- .proc_handler = &proc_dointvec,
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_taint,
},
{
.ctl_name = KERN_CAP_BSET,
@@ -1835,6 +1835,23 @@
do_proc_dointvec_bset_conv,&op);
}
+/*
+ * 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;
+ }
+
+ op = OP_OR;
+ return do_proc_dointvec(table,write,filp,buffer,lenp,ppos,
+ do_proc_dointvec_bset_conv,&op);
+}
+
struct do_proc_dointvec_minmax_conv_param {
int *min;
int *max;
"Theodore Ts'o" <[email protected]> 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?
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
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)
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
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....)
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
On Sun, 21 May 2006 19:04:32 -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. :-)
>
> Signed-off-by: "Theodore Ts'o" <[email protected]>
>
>
> Index: linux-2.6/kernel/sysctl.c
> ===================================================================
> --- linux-2.6.orig/kernel/sysctl.c 2006-03-25 21:26:38.000000000 -0500
> +++ linux-2.6/kernel/sysctl.c 2006-05-21 19:00:15.000000000 -0400
> @@ -1835,6 +1835,23 @@
> do_proc_dointvec_bset_conv,&op);
> }
>
> +/*
> + * 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;
> + }
no braces.
> +
> + op = OP_OR;
> + return do_proc_dointvec(table,write,filp,buffer,lenp,ppos,
> + do_proc_dointvec_bset_conv,&op);
find/use that spacebar (after commas).
> +}
> +
> struct do_proc_dointvec_minmax_conv_param {
> int *min;
> int *max;
---
~Randy
>> > 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
--
On Mon, May 22, 2006 at 03:36:44AM -0700, Andrew Morton wrote:
> "Theodore Ts'o" <[email protected]> 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 protected]>
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();
Theodore Tso wrote:
>
>+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;
>+}
>
This won't work because struct page could easily be a free page.
I think /dev/mem should be able to remap physical memory now that
PG_reserved is gone.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
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
On Sun, May 21, 2006 at 07:04:32PM -0400, Theodore Ts'o wrote:
> --- linux-2.6.orig/kernel/panic.c 2006-04-28 21:16:55.000000000 -0400
> +++ linux-2.6/kernel/panic.c 2006-05-21 19:00:15.000000000 -0400
> @@ -150,6 +150,7 @@
> * 'R' - User forced a module unload.
> * 'M' - Machine had a machine check experience.
> * 'B' - System has hit bad_page.
> + * 'U' - Userspace-defined naughtiness.
Just a note, some other distros already use the 'U' flag in taint
messages to show an "unsupported" module has been loaded. I know it's
out-of-the-tree and will never go into mainline, just FYI if you happen
to see some 'U' flags in the wild today...
Oh, and I like this feature, makes sense to me to have this.
thanks,
greg k-h
On Tue, May 23, 2006 at 11:45:06AM -0700, Greg KH wrote:
> On Sun, May 21, 2006 at 07:04:32PM -0400, Theodore Ts'o wrote:
> > --- linux-2.6.orig/kernel/panic.c 2006-04-28 21:16:55.000000000 -0400
> > +++ linux-2.6/kernel/panic.c 2006-05-21 19:00:15.000000000 -0400
> > @@ -150,6 +150,7 @@
> > * 'R' - User forced a module unload.
> > * 'M' - Machine had a machine check experience.
> > * 'B' - System has hit bad_page.
> > + * 'U' - Userspace-defined naughtiness.
>
> Just a note, some other distros already use the 'U' flag in taint
> messages to show an "unsupported" module has been loaded. I know it's
> out-of-the-tree and will never go into mainline, just FYI if you happen
> to see some 'U' flags in the wild today...
>
> Oh, and I like this feature, makes sense to me to have this.
Should we worry about collisions with what distributions are using?
That could cause confusion in the future....
- Ted
On Mon, May 22, 2006 at 03:36:44AM -0700, Andrew Morton wrote:
> "Theodore Ts'o" <[email protected]> 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
On Wed, May 24, 2006 at 09:39:16AM -0400, Theodore Tso wrote:
> On Tue, May 23, 2006 at 11:45:06AM -0700, Greg KH wrote:
> > On Sun, May 21, 2006 at 07:04:32PM -0400, Theodore Ts'o wrote:
> > > --- linux-2.6.orig/kernel/panic.c 2006-04-28 21:16:55.000000000 -0400
> > > +++ linux-2.6/kernel/panic.c 2006-05-21 19:00:15.000000000 -0400
> > > @@ -150,6 +150,7 @@
> > > * 'R' - User forced a module unload.
> > > * 'M' - Machine had a machine check experience.
> > > * 'B' - System has hit bad_page.
> > > + * 'U' - Userspace-defined naughtiness.
> >
> > Just a note, some other distros already use the 'U' flag in taint
> > messages to show an "unsupported" module has been loaded. I know it's
> > out-of-the-tree and will never go into mainline, just FYI if you happen
> > to see some 'U' flags in the wild today...
> >
> > Oh, and I like this feature, makes sense to me to have this.
>
> Should we worry about collisions with what distributions are using?
> That could cause confusion in the future....
We use it in Fedora/RHEL if a module is loaded that hasn't been gpg signed.
It's been handy to spot things like 3rd parties replacing jbd.ko with
their own variant in bug-reports.
The signed modules stuff went over like a lead balloon when that was posted
last time. Pushing the bit of the patch that describes the taint flag
may make sense though to make sure there aren't collisions like this.
I agree there is scope for confusion here, and imo kernel.org should be
the canonical place where these flags are defined, even if the kernel.org
tree doesn't actually use them all.
Dave
--
http://www.codemonkey.org.uk
On Wed, May 24, 2006 at 09:55:33AM -0400, Dave Jones wrote:
> On Wed, May 24, 2006 at 09:39:16AM -0400, Theodore Tso wrote:
> > On Tue, May 23, 2006 at 11:45:06AM -0700, Greg KH wrote:
> > > On Sun, May 21, 2006 at 07:04:32PM -0400, Theodore Ts'o wrote:
> > > > --- linux-2.6.orig/kernel/panic.c 2006-04-28 21:16:55.000000000 -0400
> > > > +++ linux-2.6/kernel/panic.c 2006-05-21 19:00:15.000000000 -0400
> > > > @@ -150,6 +150,7 @@
> > > > * 'R' - User forced a module unload.
> > > > * 'M' - Machine had a machine check experience.
> > > > * 'B' - System has hit bad_page.
> > > > + * 'U' - Userspace-defined naughtiness.
> > >
> > > Just a note, some other distros already use the 'U' flag in taint
> > > messages to show an "unsupported" module has been loaded. I know it's
> > > out-of-the-tree and will never go into mainline, just FYI if you happen
> > > to see some 'U' flags in the wild today...
> > >
> > > Oh, and I like this feature, makes sense to me to have this.
> >
> > Should we worry about collisions with what distributions are using?
> > That could cause confusion in the future....
>
> We use it in Fedora/RHEL if a module is loaded that hasn't been gpg signed.
> It's been handy to spot things like 3rd parties replacing jbd.ko with
> their own variant in bug-reports.
Brainfart on my part. We mark such modules as (U) in the module list in oopses,
but we don't actually taint.
Meh, too early for davej's.
Dave
--
http://www.codemonkey.org.uk
On Wed, May 24, 2006 at 09:39:16AM -0400, Theodore Tso wrote:
> On Tue, May 23, 2006 at 11:45:06AM -0700, Greg KH wrote:
> > On Sun, May 21, 2006 at 07:04:32PM -0400, Theodore Ts'o wrote:
> > > --- linux-2.6.orig/kernel/panic.c 2006-04-28 21:16:55.000000000 -0400
> > > +++ linux-2.6/kernel/panic.c 2006-05-21 19:00:15.000000000 -0400
> > > @@ -150,6 +150,7 @@
> > > * 'R' - User forced a module unload.
> > > * 'M' - Machine had a machine check experience.
> > > * 'B' - System has hit bad_page.
> > > + * 'U' - Userspace-defined naughtiness.
> >
> > Just a note, some other distros already use the 'U' flag in taint
> > messages to show an "unsupported" module has been loaded. I know it's
> > out-of-the-tree and will never go into mainline, just FYI if you happen
> > to see some 'U' flags in the wild today...
> >
> > Oh, and I like this feature, makes sense to me to have this.
>
> Should we worry about collisions with what distributions are using?
I wouldn't. It's their responsibility to handle things like this when
merging to new kernel versions. They can just change the character,
like they handle new sysrq values.
thanks,
greg k-h