All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: kernel-hardening@lists.openwall.com
Cc: Kees Cook <keescook@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Hoeun Ryu <hoeun.ryu@gmail.com>, PaX Team <pageexec@freemail.hu>,
	Emese Revfy <re.emese@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	x86@kernel.org
Subject: [kernel-hardening] [RFC] Introduce rare_write() infrastructure
Date: Mon, 27 Feb 2017 12:42:58 -0800	[thread overview]
Message-ID: <1488228186-110679-1-git-send-email-keescook@chromium.org> (raw)

This is an RFC series to demonstrate a possible infrastructure for the
"write rarely" memory storage type in the kernel (patch 1). The intent
is to further reduce the internal attack surface of the kernel by making
more variables read-only while "at rest". This is strongly based on the
"__read_only" portion of the KERNEXEC infrastructure from PaX/grsecurity,
though I tried to adjust it to be more in line with ideas Mark Rutland had
about how it might work upstream.

Also included is the PaX/grsecurity constify plugin (patch 7) which will
automatically make all instances of certain structures read-only, to help
demonstrate more complex cases of "write rarely" targets. (The plugin in
this series is altered to only operate on marked structures, rather than
the full automatic constification.)

As part of the series I've included both x86 support (patch 4), exactly
as done in PaX, and ARM support (patch 5), similar to what is done in
grsecurity but without support for earlier ARM CPUs. Both are lightly
tested by me, but have lived through 0-day build testing over the weekend.

I've added an lkdtm test (patch 2), though it needs to be reorganized
since its failure case is inverted from what would normally be expected
for lkdtm. It does, however, serve as a stand-alone example of the new
infrastructure.

Included are two example "conversions" to the rare_write()-style of
variable manipulation: a simple one, which switches the inet diag handler
table to write-rarely during register/unregister calls (patch 3), and
a more complex one: cgroup types (patch 8), which is made read-only via
the constify plugin. The latter uses rare-write linked lists (patch 6)
and multi-field updates. Both examples are refactorings of what already
appears in PaX/grsecurity.

It may make sense to also return to PaX's original interface (using
assignments instead of a function-like macro), to avoid false positives
from coccinelle[1], and to allow for assignment operators instead of
longer-form assignments ("rare_write(thing->field, thing->field | FLAG)"
is ugly compared to "const_cast(thing->field) |= FLAG").

The patches are:

	[PATCH 1/8] Introduce rare_write() infrastructure
	[PATCH 2/8] lkdtm: add test for rare_write() infrastructure
	[PATCH 3/8] net: switch sock_diag handlers to rare_write()
	[PATCH 4/8] x86: Implement __arch_rare_write_map/unmap()
	[PATCH 5/8] ARM: Implement __arch_rare_write_map/unmap()
	[PATCH 6/8] list: add rare_write() list helpers
	[PATCH 7/8] gcc-plugins: Add constify plugin
	[PATCH 8/8] cgroups: force all struct cftype const

Let's hammer out the issues...

-Kees

[1] https://lists.01.org/pipermail/kbuild-all/2017-February/031316.html

             reply	other threads:[~2017-02-27 20:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 20:42 Kees Cook [this message]
2017-02-27 20:42 ` [kernel-hardening] [RFC][PATCH 1/8] Introduce rare_write() infrastructure Kees Cook
2017-02-28  8:22   ` [kernel-hardening] " Hoeun Ryu
2017-02-28 15:05     ` Kees Cook
2017-03-01 10:43       ` Mark Rutland
2017-03-01 20:13         ` Kees Cook
2017-03-01 20:31           ` Kees Cook
2017-03-01 21:00           ` Andy Lutomirski
2017-03-01 23:14             ` Kees Cook
2017-03-02 11:19             ` Mark Rutland
2017-03-02 16:33               ` Andy Lutomirski
2017-03-02 19:48                 ` Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 2/8] lkdtm: add test for " Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 3/8] net: switch sock_diag handlers to rare_write() Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 4/8] x86: Implement __arch_rare_write_map/unmap() Kees Cook
2017-02-28 19:33   ` [kernel-hardening] " Andy Lutomirski
2017-02-28 21:35     ` Kees Cook
2017-02-28 22:54       ` Andy Lutomirski
2017-02-28 23:52         ` Kees Cook
2017-03-01 11:24           ` Mark Rutland
2017-03-01 20:25             ` Kees Cook
2017-03-02 11:20               ` Mark Rutland
2017-03-03  0:59             ` Hoeun Ryu
2017-03-01 10:59       ` Mark Rutland
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 5/8] ARM: " Kees Cook
2017-03-01  1:04   ` [kernel-hardening] " Russell King - ARM Linux
2017-03-01  5:41     ` Kees Cook
2017-03-01 11:30       ` Russell King - ARM Linux
2017-03-02  0:08         ` Kees Cook
2017-03-01 11:50       ` Mark Rutland
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 6/8] list: add rare_write() list helpers Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 7/8] gcc-plugins: Add constify plugin Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 8/8] cgroups: force all struct cftype const Kees Cook

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=1488228186-110679-1-git-send-email-keescook@chromium.org \
    --to=keescook@chromium.org \
    --cc=hoeun.ryu@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux@armlinux.org.uk \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pageexec@freemail.hu \
    --cc=re.emese@gmail.com \
    --cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.