From: James Morris <jmorris@namei.org>
To: ksummit-discuss@lists.linuxfoundation.org
Cc: Emily Ratliff <eratliff@linuxfoundation.org>
Subject: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening
Date: Mon, 24 Aug 2015 14:20:01 +1000 (AEST) [thread overview]
Message-ID: <alpine.LRH.2.20.1508241335370.1294@namei.org> (raw)
I'd like to propose a security topic, "Kernel Hardening" (or "Kernel Self
Protection"), to discuss how we can better mitigate vulnerabilities
arising from kernel bugs.
We have some measures in place, although we are really not doing
everything we can, as demonstrated from time to time when vulnerabilities
arise which are mitigated by protections in grsecurity (for example), but
not by mainline. Much of the necessary work has already been done in that
project, and as many will know, there have been significant challenges
involved in past efforts to bring these techniques into mainline. In some
cases, the performance hit has been too high for maintainers to accept,
and I wonder if we can re-visit some of these cases, with new approaches
or perspectives on cost/benefit.
There are also potentially promising approaches to mitigation with other
technologies such as KASan and gcc plugins, as well as evolving hardware
features.
The aim of this session would be to bring relevant core kernel maintainers
together with representatives of the research community and figure out a
way to work together to improve hardening and mitigation in the Linux
kernel. We'd discuss what gaps we currently have, and what code or
techniques already exist that can be incorporated into mainline to close
them. We'd identify issues that maintainers may have and try and find
ways to address those issues. From this, I'd hope that we'd develop an
overall picture of what needs to be done and a practical idea of how to
move forward. We may not necessarily resolve all issues in this session,
but we can at least characterize them and go away and think more about
them.
We could also talk to the Core Infrastructure Initiative folk if we
discover potentially useful tasks with no owners -- they may be able to
fund developers for them. It would likely be useful to provide CII with a
status report after the session in any case.
I'd recommend Kees Cook be involved, due to his existing efforts in kernel
hardening. I think it would be good to invite one or two expert security
researchers in this area -- Kees would know who. In terms of core kernel
folk, I'd suggest Ingo and akpm, as a starting point.
Comments?
--
James Morris
<jmorris@namei.org>
next reply other threads:[~2015-08-24 4:20 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 4:20 James Morris [this message]
2015-08-24 11:46 ` Jiri Kosina
2015-08-24 11:56 ` James Morris
2015-08-24 17:17 ` Kees Cook
2015-08-24 17:28 ` Andy Lutomirski
2015-08-24 17:39 ` Julia Lawall
2015-08-24 18:01 ` Kees Cook
2015-08-24 18:19 ` Andy Lutomirski
2015-08-24 18:57 ` Kees Cook
2015-08-24 18:52 ` Thomas Gleixner
2015-08-24 18:59 ` Thomas Gleixner
2015-08-24 19:00 ` Kees Cook
2015-08-24 22:05 ` Greg KH
2015-08-25 0:51 ` Rafael J. Wysocki
2015-08-31 20:10 ` Eric W. Biederman
2015-08-31 20:22 ` josh
2015-08-26 20:51 ` Kees Cook
2015-08-26 21:10 ` Matthew Garrett
2015-08-30 0:41 ` [Ksummit-discuss] Self nomination Matthew Garrett
2015-08-24 11:48 ` [Ksummit-discuss] [TECH TOPIC] Kernel Hardening Jiri Kosina
2015-08-24 12:29 ` Linus Walleij
2015-08-24 12:51 ` Jason Cooper
2015-08-24 16:35 ` Kees Cook
2015-08-24 20:09 ` James Bottomley
2015-08-24 20:17 ` James Morris
2015-08-24 20:46 ` Thomas Gleixner
2015-08-24 22:22 ` James Morris
2015-08-24 23:20 ` Kees Cook
2015-08-24 23:54 ` Theodore Ts'o
2015-08-25 0:06 ` James Morris
2015-08-25 0:06 ` Kees Cook
2015-08-27 22:08 ` [Ksummit-discuss] grsecurity and kernel hardening Stephen Hemminger
2015-08-27 22:49 ` James Bottomley
2015-08-27 23:03 ` Stephen Hemminger
2015-08-24 23:04 ` [Ksummit-discuss] [TECH TOPIC] Kernel Hardening Kees Cook
2015-08-25 16:45 ` Luis R. Rodriguez
2015-08-24 22:57 ` Kees Cook
2015-08-24 23:25 ` Kees Cook
2015-08-24 20:28 ` josh
2015-08-24 22:55 ` Kees Cook
2015-08-24 23:13 ` Andy Lutomirski
2015-08-31 20:58 ` Eric W. Biederman
2015-09-01 9:03 ` Jiri Kosina
2015-09-01 16:52 ` Kees Cook
2015-09-01 16:50 ` Kees Cook
2015-08-25 15:15 ` Shuah Khan
2015-08-25 16:15 ` Kees Cook
2015-08-25 16:30 ` Mark Brown
2015-08-25 16:33 ` Kees Cook
2015-08-25 16:58 ` Shuah Khan
2015-09-22 12:24 ` Dan Carpenter
2015-09-22 12:55 ` Yves-Alexis Perez
2015-09-22 12:59 ` Julia Lawall
2015-09-22 18:02 ` Andy Lutomirski
2015-08-24 16:20 ` Aneesh Kumar K.V
2015-08-24 17:19 ` Kees Cook
2015-08-24 18:50 ` James Morris
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=alpine.LRH.2.20.1508241335370.1294@namei.org \
--to=jmorris@namei.org \
--cc=eratliff@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.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