All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.