From: Mark Rutland <mark.rutland@arm.com>
To: Kees Cook <keescook@chromium.org>
Cc: Hoeun Ryu <hoeun.ryu@gmail.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Andy Lutomirski <luto@kernel.org>,
PaX Team <pageexec@freemail.hu>, Emese Revfy <re.emese@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"x86@kernel.org" <x86@kernel.org>
Subject: [kernel-hardening] Re: [RFC][PATCH 1/8] Introduce rare_write() infrastructure
Date: Wed, 1 Mar 2017 10:43:38 +0000 [thread overview]
Message-ID: <20170301104337.GA28874@leverpostej> (raw)
In-Reply-To: <CAGXu5jKvY1VRxBk_F9omixEBhaSTE18tfRWNcPUKhFk303v6iw@mail.gmail.com>
Hi,
On Tue, Feb 28, 2017 at 07:05:32AM -0800, Kees Cook wrote:
> On Tue, Feb 28, 2017 at 12:22 AM, Hoeun Ryu <hoeun.ryu@gmail.com> wrote:
> > On Mon, 2017-02-27 at 12:42 -0800, Kees Cook wrote:
> >> +/*
> >> + * Build "write rarely" infrastructure for flipping memory r/w
> >> + * on a per-CPU basis.
> >> + */
> >> +#ifndef CONFIG_HAVE_ARCH_RARE_WRITE
> >> +# define __wr_rare
> >> +# define __wr_rare_type
> >> +# define __rare_write_type(v) typeof(v)
> >> +# define __rare_write_ptr(v) (&(v))
> >> +# define __rare_write(__var, __val) ({ \
> >> + __var = __val; \
> >> + __var; \
> >> +})
> >> +# define rare_write_enable() do { } while (0)
> >> +# define rare_write_disable() do { } while (0)
> >> +#else
> >> +# define __wr_rare __ro_after_init
> >> +# define __wr_rare_type const
> >> +# define __rare_write_type(v) typeof((typeof(v))0)
> >> +# define __rare_write_ptr(v) ((__rare_write_type(v) *)&(v))
> >
> > Should we make __rare_write_ptr arch-specific so architectures can
> > convert the pointer to rw alias from ro address like this ? [1]
> >
> > #ifndef __arch_rare_write_ptr
> > # define __rare_write_ptr(v) ((__rare_write_type(v) *)&(v))
> > #else
> > # define __rate_write_ptr(v) __arch_rare_write_ptr
> > #endif
>
> I think that was Mark's idea too, but I'm not sure to handle the
> complex cases of doing multiple updates at once (e.g. linked list
> updates, etc).
Assuming there aren't that many places with complex updates, we could
allow code to explicitly do the map/unmap and use __rare_write_ptr
directly. That does mean that the list code has to be specialised for
__wr_rare, which is less than ideal.
That would also depend on what is __rw_rare in those cases, too. i.e.
is it just the list_head for the list itself, the list_head of all
elements, or only some of them?
For the latter mixed case, the __rare_write_ptr() approach probably
doesn't work, and that rules out the mm-based approach, too, I guess. :/
> I think we're better doing a full disabling of RO protection, but
> there had been objections to this idea in the past, which is why I
> included the "complex" example, so I don't see a way around it.
My objection to that was that we can't implement CPU-local full
disabling of RO protection for the kernel page tables on some
architectures and configurations, e.g. arm64, or 32-bit arm with LPAE.
The RW alias write_write(var, val) approach only relies on what arches
already have to implement for userspace to work, so if we can figure out
how to make that work API-wise, we can probably implement that
generically with switch_mm() and {get,put}_user().
The only other way I can think to make this work would be to make a copy
of the whole swapper page tables, with the write-rarely data marked RW.
For arm64 at least, that'll be incredibly painful to keep in-sync with
the usual tables, in addition to being very expensive to switch to/from.
Thanks,
Mark.
next prev parent reply other threads:[~2017-03-01 10:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 20:42 [kernel-hardening] [RFC] Introduce rare_write() infrastructure Kees Cook
2017-02-27 20:42 ` [kernel-hardening] [RFC][PATCH 1/8] " 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 [this message]
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=20170301104337.GA28874@leverpostej \
--to=mark.rutland@arm.com \
--cc=hoeun.ryu@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--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.