All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Hoeun Ryu <hoeun.ryu@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	kernel-hardening@lists.openwall.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Laura Abbott <labbott@redhat.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [kernel-hardening] Re: [RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section
Date: Mon, 20 Feb 2017 12:45:32 +0000	[thread overview]
Message-ID: <20170220124531.GH9003@leverpostej> (raw)
In-Reply-To: <CAKv+Gu9umycZm_UP99ZUifLUBb8MuOZHXgU9nB6XioVMa4eeVw@mail.gmail.com>

On Sun, Feb 19, 2017 at 11:35:51AM +0000, Ard Biesheuvel wrote:
> On 19 February 2017 at 10:04, Hoeun Ryu <hoeun.ryu@gmail.com> wrote:
> > Map rodata sections seperately for the new __ro_mostly_after_init section.
> > Attribute of memory for __ro_mostly_after_init section can be changed later
> > so we need a dedicated vmalloced region for set_memory_rw/ro api.

> While it is correct that you are splitting this into three separate
> segments (otherwise we would not be able to change the permissions
> later without risking splitting to occur), I think this leads to
> unnecessary fragmentation.
> 
> If there is demand for this feature (but you still need to make the
> argument for that), I wonder if it wouldn't be sufficient, and much
> more straightforward, to redefine the __ro_after_init semantics to
> include the kind of subsystem registration and module init context you
> are targeting, and implement some hooks to temporarily lift the
> __ro_after_init r/o permission restrictions in a controlled manner.

>From a look over the series, I think this is just __write_rarely in
disguise. I personally think that we should keep __write_rarely and
__ro_after_init separate, the later being a strictly one-shot affair.

I had some ideas [1] as to how we could implement __write_rarely without
carving up the kernel mapping further (and keeping the RW permissions
local to the thread needing it), but I have not had the time to look
into that further.

Thanks,
Mark.

[1] http://www.openwall.com/lists/kernel-hardening/2016/11/18/3

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section
Date: Mon, 20 Feb 2017 12:45:32 +0000	[thread overview]
Message-ID: <20170220124531.GH9003@leverpostej> (raw)
In-Reply-To: <CAKv+Gu9umycZm_UP99ZUifLUBb8MuOZHXgU9nB6XioVMa4eeVw@mail.gmail.com>

On Sun, Feb 19, 2017 at 11:35:51AM +0000, Ard Biesheuvel wrote:
> On 19 February 2017 at 10:04, Hoeun Ryu <hoeun.ryu@gmail.com> wrote:
> > Map rodata sections seperately for the new __ro_mostly_after_init section.
> > Attribute of memory for __ro_mostly_after_init section can be changed later
> > so we need a dedicated vmalloced region for set_memory_rw/ro api.

> While it is correct that you are splitting this into three separate
> segments (otherwise we would not be able to change the permissions
> later without risking splitting to occur), I think this leads to
> unnecessary fragmentation.
> 
> If there is demand for this feature (but you still need to make the
> argument for that), I wonder if it wouldn't be sufficient, and much
> more straightforward, to redefine the __ro_after_init semantics to
> include the kind of subsystem registration and module init context you
> are targeting, and implement some hooks to temporarily lift the
> __ro_after_init r/o permission restrictions in a controlled manner.

>From a look over the series, I think this is just __write_rarely in
disguise. I personally think that we should keep __write_rarely and
__ro_after_init separate, the later being a strictly one-shot affair.

I had some ideas [1] as to how we could implement __write_rarely without
carving up the kernel mapping further (and keeping the RW permissions
local to the thread needing it), but I have not had the time to look
into that further.

Thanks,
Mark.

[1] http://www.openwall.com/lists/kernel-hardening/2016/11/18/3

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Hoeun Ryu <hoeun.ryu@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	kernel-hardening@lists.openwall.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Laura Abbott <labbott@redhat.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section
Date: Mon, 20 Feb 2017 12:45:32 +0000	[thread overview]
Message-ID: <20170220124531.GH9003@leverpostej> (raw)
In-Reply-To: <CAKv+Gu9umycZm_UP99ZUifLUBb8MuOZHXgU9nB6XioVMa4eeVw@mail.gmail.com>

On Sun, Feb 19, 2017 at 11:35:51AM +0000, Ard Biesheuvel wrote:
> On 19 February 2017 at 10:04, Hoeun Ryu <hoeun.ryu@gmail.com> wrote:
> > Map rodata sections seperately for the new __ro_mostly_after_init section.
> > Attribute of memory for __ro_mostly_after_init section can be changed later
> > so we need a dedicated vmalloced region for set_memory_rw/ro api.

> While it is correct that you are splitting this into three separate
> segments (otherwise we would not be able to change the permissions
> later without risking splitting to occur), I think this leads to
> unnecessary fragmentation.
> 
> If there is demand for this feature (but you still need to make the
> argument for that), I wonder if it wouldn't be sufficient, and much
> more straightforward, to redefine the __ro_after_init semantics to
> include the kind of subsystem registration and module init context you
> are targeting, and implement some hooks to temporarily lift the
> __ro_after_init r/o permission restrictions in a controlled manner.

>From a look over the series, I think this is just __write_rarely in
disguise. I personally think that we should keep __write_rarely and
__ro_after_init separate, the later being a strictly one-shot affair.

I had some ideas [1] as to how we could implement __write_rarely without
carving up the kernel mapping further (and keeping the RW permissions
local to the thread needing it), but I have not had the time to look
into that further.

Thanks,
Mark.

[1] http://www.openwall.com/lists/kernel-hardening/2016/11/18/3

  reply	other threads:[~2017-02-20 12:45 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-19 10:04 [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker Hoeun Ryu
2017-02-19 10:04 ` Hoeun Ryu
2017-02-19 10:04 ` [kernel-hardening] [RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-20 10:22   ` [kernel-hardening] " Mark Rutland
2017-02-21  6:33     ` Ho-Eun Ryu
2017-02-19 10:04 ` [kernel-hardening] [RFC 3/7] module: modify memory attrs for __ro_mostly_after_init during module_init/exit Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-20 10:30   ` [kernel-hardening] " Mark Rutland
2017-02-21 13:36     ` Ho-Eun Ryu
2017-02-21 13:58       ` Mark Rutland
2017-02-22 13:45         ` Hoeun Ryu
2017-02-19 10:04 ` [kernel-hardening] [RFC 4/7] selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-21 10:35   ` Tetsuo Handa
2017-02-19 10:04 ` [kernel-hardening] [RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-20  8:20   ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-02-20  8:20     ` Sebastian Andrzej Siewior
2017-02-21  5:47     ` [kernel-hardening] " Ho-Eun Ryu
2017-02-21  5:47       ` Ho-Eun Ryu
2017-02-19 10:04 ` [kernel-hardening] [RFC 6/7] arm64: add __map_kernel_segment to accept additional vm flags Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-19 11:21   ` [kernel-hardening] " Ard Biesheuvel
2017-02-19 11:21     ` Ard Biesheuvel
2017-02-19 11:21     ` Ard Biesheuvel
2017-02-19 10:04 ` [kernel-hardening] [RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-19 10:04   ` Hoeun Ryu
2017-02-19 11:35   ` [kernel-hardening] " Ard Biesheuvel
2017-02-19 11:35     ` Ard Biesheuvel
2017-02-19 11:35     ` Ard Biesheuvel
2017-02-20 12:45     ` Mark Rutland [this message]
2017-02-20 12:45       ` Mark Rutland
2017-02-20 12:45       ` Mark Rutland
2017-02-21 20:38       ` [kernel-hardening] " Kees Cook
2017-02-21 20:38         ` Kees Cook
2017-02-21 20:38         ` Kees Cook
2017-02-19 11:24 ` [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker Ard Biesheuvel
2017-02-19 11:24   ` Ard Biesheuvel
2017-02-21  6:29   ` [kernel-hardening] " Ho-Eun Ryu
2017-02-21  6:29     ` Ho-Eun Ryu

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=20170220124531.GH9003@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=hoeun.ryu@gmail.com \
    --cc=jeremy.linton@arm.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will.deacon@arm.com \
    /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.