From: Hoeun Ryu <hoeun.ryu@gmail.com>
To: Kees Cook <keescook@chromium.org>, kernel-hardening@lists.openwall.com
Cc: Mark Rutland <mark.rutland@arm.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
Subject: [kernel-hardening] Re: [RFC][PATCH 1/8] Introduce rare_write() infrastructure
Date: Tue, 28 Feb 2017 17:22:54 +0900 [thread overview]
Message-ID: <1488270174.1747.11.camel@gmail.com> (raw)
In-Reply-To: <1488228186-110679-2-git-send-email-keescook@chromium.org>
On Mon, 2017-02-27 at 12:42 -0800, Kees Cook wrote:
> Several types of data storage exist in the kernel: read-write data
> (.data,
> .bss), read-only data (.rodata), and RO-after-init. This introduces
> the
> infrastructure for another type: write-rarely, which intended for
> data
> that is either only rarely modified or especially security-sensitive.
> The
> intent is to further reduce the internal attack surface of the kernel
> by
> making this storage read-only when "at rest". This makes it much
> harder
> to be subverted by attackers who have a kernel-write flaw, since they
> cannot directly change the memory contents.
>
> Variables declared __wr_rare will be made const when an architecture
> supports HAVE_ARCH_WRITE_RARE. To change these variables, either the
> rare_write() macro can be used, or multiple uses of __rare_write(),
> wrapped in rare_write_enable()/rare_write_disable() macros. These
> macros
> are handled by the arch-specific functions that perform the actions
> needed
> to write to otherwise read-only memory.
>
> The arch-specific helpers must be not allow non-current CPUs to write
> the memory area, run non-preemptible to avoid accidentally leaving
> memory writable, and defined as inline to avoid making them desirable
> ROP targets for attackers.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/Kconfig | 15 +++++++++++++++
> include/linux/compiler.h | 38 ++++++++++++++++++++++++++++++++++++++
> include/linux/preempt.h | 6 ++++--
> 3 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 99839c23d453..2446de19f66d 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -781,4 +781,19 @@ config VMAP_STACK
> the stack to map directly to the KASAN shadow map using a
> formula
> that is incorrect if the stack is in vmalloc space.
>
> +config HAVE_ARCH_RARE_WRITE
> + def_bool n
> + help
> + An arch should select this option if it has defined the
> functions
> + __arch_rare_write_map() and __arch_rare_write_unmap() to
> + respectively enable and disable writing to read-only
> memory.The
> + routines must meet the following requirements:
> + - read-only memory writing must only be available on the
> current
> + CPU (to make sure other CPUs can't race to make changes
> too).
> + - the routines must be declared inline (to discourage ROP
> use).
> + - the routines must not be preemptible (likely they will
> call
> + preempt_disable() and preempt_enable_no_resched()
> respectively).
> + - the routines must validate expected state (e.g. when
> enabling
> + writes, BUG() if writes are already be enabled).
> +
> source "kernel/gcov/Kconfig"
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index cf0fa5d86059..f95603a8ee72 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -325,6 +325,44 @@ static __always_inline void
> __write_once_size(volatile void *p, void *res, int s
> __u.__val; \
> })
>
> +/*
> + * 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
[1] https://lkml.org/lkml/2017/2/22/254
> +# define __rare_write(__var, __val) ({ \
> + __rare_write_type(__var) *__rw_var; \
> + \
> + __rw_var = __rare_write_ptr(__var); \
> + *__rw_var = (__val); \
> + __var; \
> +})
> +# define rare_write_enable() __arch_rare_write_map()
> +# define rare_write_disable() __arch_rare_write_unmap()
> +#endif
> +
> +#define rare_write(__var, __val) ({ \
> + rare_write_enable(); \
> + __rare_write(__var, __val); \
> + rare_write_disable(); \
> + __var; \
> +})
> +
> #endif /* __KERNEL__ */
>
> #endif /* __ASSEMBLY__ */
> diff --git a/include/linux/preempt.h b/include/linux/preempt.h
> index 7eeceac52dea..183c1d7a8594 100644
> --- a/include/linux/preempt.h
> +++ b/include/linux/preempt.h
> @@ -237,10 +237,12 @@ do { \
> /*
> * Modules have no business playing preemption tricks.
> */
> -#undef sched_preempt_enable_no_resched
> -#undef preempt_enable_no_resched
> #undef preempt_enable_no_resched_notrace
> #undef preempt_check_resched
> +#ifndef CONFIG_HAVE_ARCH_RARE_WRITE
> +#undef sched_preempt_enable_no_resched
> +#undef preempt_enable_no_resched
> +#endif
> #endif
>
> #define preempt_set_need_resched() \
next prev parent reply other threads:[~2017-02-28 8:22 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 ` Hoeun Ryu [this message]
2017-02-28 15:05 ` [kernel-hardening] " 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=1488270174.1747.11.camel@gmail.com \
--to=hoeun.ryu@gmail.com \
--cc=keescook@chromium.org \
--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.