From: Ben Hutchings <ben@decadent.org.uk>
To: kernel-hardening@lists.openwall.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [kernel-hardening] 2015 kernel CVEs
Date: Thu, 21 Jan 2016 18:46:48 +0000 [thread overview]
Message-ID: <1453402008.3734.94.camel@decadent.org.uk> (raw)
In-Reply-To: <20160120180447.GA31532@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
On Wed, 2016-01-20 at 10:04 -0800, Greg KH wrote:
> On Wed, Jan 20, 2016 at 05:05:39PM +0000, Ben Hutchings wrote:
> > On Tue, 2016-01-19 at 09:54 -0800, Greg KH wrote:
> > > On Tue, Jan 19, 2016 at 04:32:08PM +0000, Ben Hutchings wrote:
> > > > As for USB descriptors, I'm somewhat more hopeful about hardening. At
> > > > the same time, it seems like it should be practical to put more low-
> > > > performance USB drivers into userspace.
> > >
> > > What drivers do we currently have in the kernel that should/could be
> > > done in userspace instead? I'll gladly drop them from the tree.
> >
> > An obvious example would be HID drivers. (I'll grant you that putting
> > those in user-space would complicate the boot process when a disk
> > encryption passphrase is needed.)
>
> That and for userspace that expects to get an input device stream,
> combining serial, ps2, bluetooth, and USB devices all at the same time.
> So while it might be possible, keeping input devices and HID support in
> the kernel makes sense.
[...]
I was thinking that the HID drivers would feed events back into the
kernel through an enhanced version of evdev_write(). The userland
consumers of input events wouldn't need to change at all.
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
next prev parent reply other threads:[~2016-01-21 18:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160119124917.6058019b@pc1>
2016-01-19 11:28 ` Dan Carpenter
2016-01-19 14:56 ` One Thousand Gnomes
2016-01-19 16:32 ` [kernel-hardening] " Ben Hutchings
2016-01-19 17:54 ` Greg KH
2016-01-20 17:05 ` Ben Hutchings
2016-01-20 18:04 ` Greg KH
2016-01-21 15:18 ` Jiri Kosina
2016-01-21 18:46 ` Ben Hutchings [this message]
2016-01-19 16:57 ` Peter Hurley
2016-01-19 17:00 ` Josh Boyer
2016-01-19 17:51 ` Greg KH
2016-01-20 7:12 ` [kernel-hardening] " Marcus Meissner
2016-01-19 17:57 ` [kernel-hardening] " Theodore Ts'o
2016-01-19 18:00 ` Al Viro
2016-01-19 22:41 ` [kernel-hardening] " Eric W. Biederman
2016-01-19 22:47 ` [kernel-hardening] " Eric W. Biederman
2016-01-20 20:11 ` Jann Horn
2016-01-20 21:26 ` One Thousand Gnomes
2016-01-19 23:35 ` Kees Cook
2016-01-20 9:57 ` Miroslav Benes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453402008.3734.94.camel@decadent.org.uk \
--to=ben@decadent.org.uk \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome