Over the weekend my server was acting funny. The display wasn't working
well, and I assumed that a driver was going bad. I went to look at the
kernel dmesg, but the buffer only had the following over and over:
[226062.401405] systemd-logind[3511]: Removed session 4168.
[226063.381051] systemd-logind[3511]: Removed session 4169.
[226232.279412] systemd-logind[3511]: New session 4172 of user rostedt.
[226295.639223] systemd-logind[3511]: Removed session 4172.
[227867.920584] systemd-logind[3511]: New session 4204 of user rostedt.
[227869.016023] systemd-logind[3511]: New session 4205 of user rostedt.
[227927.094215] systemd-logind[3511]: Removed session 4204.
[227927.905655] systemd-logind[3511]: Removed session 4205.
[229740.942811] systemd-logind[3511]: New session 4237 of user rostedt.
[229741.505884] systemd-logind[3511]: New session 4238 of user rostedt.
[229799.710123] systemd-logind[3511]: Removed session 4237.
[229800.668171] systemd-logind[3511]: Removed session 4238.
[229835.378869] systemd-logind[3511]: New session 4240 of user rostedt.
[229898.433560] systemd-logind[3511]: Removed session 4240.
[231429.405715] systemd-logind[3511]: New session 4272 of user rostedt.
[231429.964865] systemd-logind[3511]: New session 4273 of user rostedt.
[231487.908190] systemd-logind[3511]: Removed session 4272.
[231488.861240] systemd-logind[3511]: Removed session 4273.
[233280.032816] systemd-logind[3511]: New session 4306 of user rostedt.
[233280.505022] systemd-logind[3511]: New session 4307 of user rostedt.
[233338.761804] systemd-logind[3511]: Removed session 4306.
[233339.749970] systemd-logind[3511]: Removed session 4307.
[233438.696027] systemd-logind[3511]: New session 4309 of user rostedt.
[233499.959512] systemd-logind[3511]: Removed session 4309.
The kernel buffer was completely overridden by useless spewing from
user space. I know that people consider this a "feature" but to me it's
quite annoying that I constantly have to fight to get kernel messages.
I personally believe that only the kernel should have the right to
write into the kernel log buffers, as user space can easily blow away
any useful kernel information with useless logging.
I simply propose a way to let us kernel developers keep user space from
interfering, by adding a new kernel command line parameter that will
disable writing to /dev/kmsg. Any attempt to open the file in write
mode will return a -EPERM error.
This should have no affect on distros that want to keep the feature of
writing to /dev/kmsg, as it requires a kernel command line to disable.
Signed-off-by: Steven Rostedt <[email protected]>
---
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0b3de80ec8f6..5edae5573b2e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -921,6 +921,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Disable Dynamic DMA Window support. Use this if
to workaround buggy firmware.
+ disable_devkmsg_write
+ Disable writing to /dev/kmsg. This prevents user space
+ tools from writing into the kernel printk buffers.
+ When set, opening /dev/kmsg for write mode will return
+ -EPERM.
+
disable_ipv6= [IPV6]
See Documentation/networking/ipv6.txt.
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index bfbf284e4218..b704b48415a0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -85,6 +85,15 @@ static struct lockdep_map console_lock_dep_map = {
};
#endif
+static bool devkmsg_disabled;
+static int __init disable_devkmsg(char *str)
+{
+ devkmsg_disabled = true;
+ return 0;
+}
+__setup("disable_devkmsg_write", disable_devkmsg);
+
+
/*
* Number of registered extended console drivers.
*
@@ -799,6 +808,10 @@ static int devkmsg_open(struct inode *inode, struct file *file)
struct devkmsg_user *user;
int err;
+ /* When devkmsg_disabled is set, fail all write access */
+ if (devkmsg_disabled && (file->f_flags & O_ACCMODE))
+ return -EPERM;
+
/* write-only does not need any file context */
if ((file->f_flags & O_ACCMODE) == O_WRONLY)
return 0;
[ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which
may make this fail filters. ]
Over the weekend my server was acting funny. The display wasn't working
well, and I assumed that a driver was going bad. I went to look at the
kernel dmesg, but the buffer only had the following over and over:
[226062.401405] systemd-logind[3511]: Removed session 4168.
[226063.381051] systemd-logind[3511]: Removed session 4169.
[226232.279412] systemd-logind[3511]: New session 4172 of user rostedt.
[226295.639223] systemd-logind[3511]: Removed session 4172.
[227867.920584] systemd-logind[3511]: New session 4204 of user rostedt.
[227869.016023] systemd-logind[3511]: New session 4205 of user rostedt.
[227927.094215] systemd-logind[3511]: Removed session 4204.
[227927.905655] systemd-logind[3511]: Removed session 4205.
[229740.942811] systemd-logind[3511]: New session 4237 of user rostedt.
[229741.505884] systemd-logind[3511]: New session 4238 of user rostedt.
[229799.710123] systemd-logind[3511]: Removed session 4237.
[229800.668171] systemd-logind[3511]: Removed session 4238.
[229835.378869] systemd-logind[3511]: New session 4240 of user rostedt.
[229898.433560] systemd-logind[3511]: Removed session 4240.
[231429.405715] systemd-logind[3511]: New session 4272 of user rostedt.
[231429.964865] systemd-logind[3511]: New session 4273 of user rostedt.
[231487.908190] systemd-logind[3511]: Removed session 4272.
[231488.861240] systemd-logind[3511]: Removed session 4273.
[233280.032816] systemd-logind[3511]: New session 4306 of user rostedt.
[233280.505022] systemd-logind[3511]: New session 4307 of user rostedt.
[233338.761804] systemd-logind[3511]: Removed session 4306.
[233339.749970] systemd-logind[3511]: Removed session 4307.
[233438.696027] systemd-logind[3511]: New session 4309 of user rostedt.
[233499.959512] systemd-logind[3511]: Removed session 4309.
The kernel buffer was completely overridden by useless spewing from
user space. I know that people consider this a "feature" but to me it's
quite annoying that I constantly have to fight to get kernel messages.
I personally believe that only the kernel should have the right to
write into the kernel log buffers, as user space can easily blow away
any useful kernel information with useless logging.
I simply propose a way to let us kernel developers keep user space from
interfering, by adding a new kernel command line parameter that will
disable writing to /dev/kmsg. Any attempt to open the file in write
mode will return a -EPERM error.
This should have no affect on distros that want to keep the feature of
writing to /dev/kmsg, as it requires a kernel command line to disable.
Signed-off-by: Steven Rostedt <[email protected]>
---
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0b3de80ec8f6..5edae5573b2e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -921,6 +921,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Disable Dynamic DMA Window support. Use this if
to workaround buggy firmware.
+ disable_devkmsg_write
+ Disable writing to /dev/kmsg. This prevents user space
+ tools from writing into the kernel printk buffers.
+ When set, opening /dev/kmsg for write mode will return
+ -EPERM.
+
disable_ipv6= [IPV6]
See Documentation/networking/ipv6.txt.
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index bfbf284e4218..b704b48415a0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -85,6 +85,15 @@ static struct lockdep_map console_lock_dep_map = {
};
#endif
+static bool devkmsg_disabled;
+static int __init disable_devkmsg(char *str)
+{
+ devkmsg_disabled = true;
+ return 0;
+}
+__setup("disable_devkmsg_write", disable_devkmsg);
+
+
/*
* Number of registered extended console drivers.
*
@@ -799,6 +808,10 @@ static int devkmsg_open(struct inode *inode, struct file *file)
struct devkmsg_user *user;
int err;
+ /* When devkmsg_disabled is set, fail all write access */
+ if (devkmsg_disabled && (file->f_flags & O_ACCMODE))
+ return -EPERM;
+
/* write-only does not need any file context */
if ((file->f_flags & O_ACCMODE) == O_WRONLY)
return 0;
On Mon, Apr 25, 2016 at 01:08:53PM -0400, Steven Rostedt wrote:
> [ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which
> may make this fail filters. ]
>
> Over the weekend my server was acting funny. The display wasn't working
> well, and I assumed that a driver was going bad. I went to look at the
> kernel dmesg, but the buffer only had the following over and over:
...
> + disable_devkmsg_write
> + Disable writing to /dev/kmsg. This prevents user space
> + tools from writing into the kernel printk buffers.
> + When set, opening /dev/kmsg for write mode will return
> + -EPERM.
I like the general idea.
Perhaps can call that param "printk.disable_devkmsg" or so with the
proper namespace and in light of printk.always_kmsg_dump=...
Anyway, just my 2¢.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On Mon, 25 Apr 2016 20:32:50 +0200
Borislav Petkov <[email protected]> wrote:
> On Mon, Apr 25, 2016 at 01:08:53PM -0400, Steven Rostedt wrote:
> > [ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which
> > may make this fail filters. ]
> >
> > Over the weekend my server was acting funny. The display wasn't working
> > well, and I assumed that a driver was going bad. I went to look at the
> > kernel dmesg, but the buffer only had the following over and over:
>
> ...
>
> > + disable_devkmsg_write
> > + Disable writing to /dev/kmsg. This prevents user space
> > + tools from writing into the kernel printk buffers.
> > + When set, opening /dev/kmsg for write mode will return
> > + -EPERM.
>
> I like the general idea.
>
> Perhaps can call that param "printk.disable_devkmsg" or so with the
> proper namespace and in light of printk.always_kmsg_dump=...
>
I agree. And Uwe Kleine-König suggested to make it read_mostly.
I'll send a v2.
-- Steve
On Mon, Apr 25, 2016 at 01:06:29PM -0400, Steven Rostedt wrote:
> Over the weekend my server was acting funny. The display wasn't working
> well, and I assumed that a driver was going bad. I went to look at the
> kernel dmesg, but the buffer only had the following over and over:
>
> [226062.401405] systemd-logind[3511]: Removed session 4168.
> [226063.381051] systemd-logind[3511]: Removed session 4169.
> The kernel buffer was completely overridden by useless spewing from
Yes it does this. I usually fix this with: apt-get install sysvinit
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index bfbf284e4218..b704b48415a0 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -85,6 +85,15 @@ static struct lockdep_map console_lock_dep_map = {
> };
> #endif
>
> +static bool devkmsg_disabled;
> +static int __init disable_devkmsg(char *str)
> +{
> + devkmsg_disabled = true;
> + return 0;
> +}
> +__setup("disable_devkmsg_write", disable_devkmsg);
> +
Can't we default enable this? Or at the very least make this easier to
type? I'll never remember how exactly this thing will be called.
On Mon 2016-04-25 13:06:29, Steven Rostedt wrote:
> Over the weekend my server was acting funny. The display wasn't working
> well, and I assumed that a driver was going bad. I went to look at the
> kernel dmesg, but the buffer only had the following over and over:
>
> [226062.401405] systemd-logind[3511]: Removed session 4168.
> [226063.381051] systemd-logind[3511]: Removed session 4169.
systemd has root. I'm not sure additional parameter to fight it is
good idea. What's next? systemd evolves a way to override kernel
parameters? :-)
> I simply propose a way to let us kernel developers keep user space from
> interfering, by adding a new kernel command line parameter that will
> disable writing to /dev/kmsg. Any attempt to open the file in write
> mode will return a -EPERM error.
chmod 400 /dev/kmsg? With udev, it should be possible to make it persistent...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 26 Apr 2016 20:44:58 +0200
Pavel Machek <[email protected]> wrote:
> > I simply propose a way to let us kernel developers keep user space from
> > interfering, by adding a new kernel command line parameter that will
> > disable writing to /dev/kmsg. Any attempt to open the file in write
> > mode will return a -EPERM error.
>
> chmod 400 /dev/kmsg? With udev, it should be possible to make it persistent...
But this opened while initramdisk is used. I'm thinking this wont work,
or does udev run before main root is mounted?
-- Steve
On 2016-04-26 15:47, Steven Rostedt wrote:
> On Tue, 26 Apr 2016 20:44:58 +0200
> Pavel Machek <[email protected]> wrote:
>
>>> I simply propose a way to let us kernel developers keep user space from
>>> interfering, by adding a new kernel command line parameter that will
>>> disable writing to /dev/kmsg. Any attempt to open the file in write
>>> mode will return a -EPERM error.
>>
>> chmod 400 /dev/kmsg? With udev, it should be possible to make it persistent...
>
> But this opened while initramdisk is used. I'm thinking this wont work,
> or does udev run before main root is mounted?
>
It does, but I don't think it runs before journald on systemd systems...
So it probably still wouldn't work.