From: holler@ahsoftware.de (Alexander Holler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: don't allow CONFIG_DEBUG_SET_MODULE_RONX if CONFIG_JUMP_LABEL is enabled
Date: Tue, 01 Apr 2014 20:53:31 +0200 [thread overview]
Message-ID: <533B0B2B.5070402@ahsoftware.de> (raw)
In-Reply-To: <CAGXu5jKMF9n9svQBhyQFvCoUe86QhLycDTt-fWyiRfySbn=Fug@mail.gmail.com>
Am 01.04.2014 20:36, schrieb Kees Cook:
> On Tue, Apr 1, 2014 at 11:03 AM, Laura Abbott <lauraa@codeaurora.org> wrote:
>> On 4/1/2014 3:04 AM, Alexander Holler wrote:
>>> CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
>>> things might fail late (and unexpected) if module code is set to read-only
>>> while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).
>
> Isn't this a ordering problem? I thought jump labels got set up once,
> and then after that, the memory could be made RO?
I basically just run into that and looked up what happened. But the
problem appears e.g. in netfiler/core.c function nf_register_hook()
which calls static_key_slow_inc(). So you would have to make sure
nf_register_hook() will be called before the code is set ro. Something
that doesn't look easy to do.
I would have to look up when that might be called, but I assume there
are many ways to register and unregister hooks in netfilter and some of
them might happen outside any init, probe or whatever one might set the
code read-only afterwards. You would have to set the code rw too, before
nf_unregister_hook() happens.
Maybe it's possible to mark some modules to not become ro at all, I
don't know. And doing so would make them a prefered target for exploits.
So I'm not sure if it would make sense.
Regards,
Alexander Holler
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Holler <holler@ahsoftware.de>
To: Kees Cook <keescook@chromium.org>, Laura Abbott <lauraa@codeaurora.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>
Subject: Re: [PATCH] arm: don't allow CONFIG_DEBUG_SET_MODULE_RONX if CONFIG_JUMP_LABEL is enabled
Date: Tue, 01 Apr 2014 20:53:31 +0200 [thread overview]
Message-ID: <533B0B2B.5070402@ahsoftware.de> (raw)
In-Reply-To: <CAGXu5jKMF9n9svQBhyQFvCoUe86QhLycDTt-fWyiRfySbn=Fug@mail.gmail.com>
Am 01.04.2014 20:36, schrieb Kees Cook:
> On Tue, Apr 1, 2014 at 11:03 AM, Laura Abbott <lauraa@codeaurora.org> wrote:
>> On 4/1/2014 3:04 AM, Alexander Holler wrote:
>>> CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
>>> things might fail late (and unexpected) if module code is set to read-only
>>> while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).
>
> Isn't this a ordering problem? I thought jump labels got set up once,
> and then after that, the memory could be made RO?
I basically just run into that and looked up what happened. But the
problem appears e.g. in netfiler/core.c function nf_register_hook()
which calls static_key_slow_inc(). So you would have to make sure
nf_register_hook() will be called before the code is set ro. Something
that doesn't look easy to do.
I would have to look up when that might be called, but I assume there
are many ways to register and unregister hooks in netfilter and some of
them might happen outside any init, probe or whatever one might set the
code read-only afterwards. You would have to set the code rw too, before
nf_unregister_hook() happens.
Maybe it's possible to mark some modules to not become ro at all, I
don't know. And doing so would make them a prefered target for exploits.
So I'm not sure if it would make sense.
Regards,
Alexander Holler
next prev parent reply other threads:[~2014-04-01 18:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 10:04 [PATCH] arm: don't allow CONFIG_DEBUG_SET_MODULE_RONX if CONFIG_JUMP_LABEL is enabled Alexander Holler
2014-04-01 10:04 ` Alexander Holler
2014-04-01 18:03 ` Laura Abbott
2014-04-01 18:03 ` Laura Abbott
2014-04-01 18:36 ` Kees Cook
2014-04-01 18:36 ` Kees Cook
2014-04-01 18:53 ` Alexander Holler [this message]
2014-04-01 18:53 ` Alexander Holler
2014-04-01 23:08 ` Rabin Vincent
2014-04-01 23:08 ` Rabin Vincent
2014-04-01 23:28 ` Alexander Holler
2014-04-01 23:28 ` Alexander Holler
2014-04-03 23:14 ` Kees Cook
2014-04-03 23:14 ` Kees Cook
2014-04-03 23:48 ` Rabin Vincent
2014-04-03 23:48 ` Rabin Vincent
2014-04-04 0:52 ` Kees Cook
2014-04-04 0:52 ` Kees Cook
2014-04-01 23:21 ` Rabin Vincent
2014-04-01 23:21 ` Rabin Vincent
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=533B0B2B.5070402@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=linux-arm-kernel@lists.infradead.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.