linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: peterz@infradead.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kees Cook <keescook@chromium.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Miroslav Benes <mbenes@suse.cz>,
	Mark Rutland <mark.rutland@arm.com>,
	binutils@sourceware.org
Subject: Re: [PATCH v2] module: Harden STRICT_MODULE_RWX
Date: Wed, 12 Aug 2020 13:41:27 +0200	[thread overview]
Message-ID: <20200812114127.GA10824@linux-8ccs.fritz.box> (raw)
In-Reply-To: <20200812104005.GN2674@hirez.programming.kicks-ass.net>

+++ peterz@infradead.org [12/08/20 12:40 +0200]:
>On Wed, Aug 12, 2020 at 10:56:56AM +0200, Ard Biesheuvel wrote:
>> The module .lds has BYTE(0) in the section contents to prevent the
>> linker from pruning them entirely. The (NOLOAD) is there to ensure
>> that this byte does not end up in the .ko, which is more a matter of
>> principle than anything else, so we can happily drop that if it helps.
>>
>> However, this should only affect the PROGBITS vs NOBITS designation,
>> and so I am not sure whether it makes a difference.
>>
>> Depending on where the w^x check occurs, we might simply override the
>> permissions of these sections, and strip the writable permission if it
>> is set in the PLT handling init code, which manipulates the metadata
>> of all these 3 sections before the module space is vmalloc'ed.
>
>What's curious is that this seems the result of some recent binutils
>change. Every build with binutils-2.34 (or older) does not seem to
>generate these as WAX, but has the much more sensible WA.
>
>I suppose we can change the kernel check and 'allow' W^X for 0 sized
>sections, but I think we should still figure out why binutils-2.35 is
>now generating WAX sections all of a sudden, it might come bite us
>elsewhere.

I have just tested with binutils-2.35 and am observing the same
behavior. Both .plt and .text.ftrace_trampoline end up with
SHT_PROGBITS and are marked 'WAX'. With binutils-2.34 they keep the
NOBITS designation.

I had thought NOLOAD implies NOBITS, but that doesn't seem to be the
case anymore? I tinkered with module.lds a bit and noticed that the
name of the section seems to matters. So this:

  SECTIONS {
      .plt (NOLOAD) : { BYTE(0) }
      .init.plt (NOLOAD) : { BYTE(0) }
      .text.ftrace_trampoline (NOLOAD) : { BYTE(0) }
+     .test (NOLOAD) : { BYTE(0) }
+     .text.test (NOLOAD) : { BYTE(0) }
+     .plt.test (NOLOAD) : { BYTE(0) }
  }

Yielded the following:

  [22] .plt              PROGBITS        0000000000000340 000e40 000001 00 WAX  0   0  1
  [23] .init.plt         NOBITS          0000000000000341 000e41 000001 00  WA  0   0  1
  [24] .text.ftrace_trampoline PROGBITS        0000000000000342 000e41 000001 00 WAX  0   0  1
  [25] .test             NOBITS          0000000000000343 000e42 000001 00  WA  0   0  1
  [26] .text.test        PROGBITS        0000000000000344 000e42 000001 00 WAX  0   0  1
  [27] .plt.test         NOBITS          0000000000000345 000e43 000001 00  WA  0   0  1

So ".plt" and any section starting with ".text" were automatically
designated as SHT_PROGBITS and given the executable flag. It appears
the NOLOAD directive has been ignored or overridden in the case of
these sections. I am not sure if this is a bug in binutils or if this
behavior is intentional.

I tried to grok the changelog between 2.34 and 2.35 but could not find
anything glaringly obvious that would cause this change. CC'ing the
binutils mailing list, hopefully that's the right place to ask.

Jessica

  reply	other threads:[~2020-08-12 11:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 17:13 [PATCH v2] module: Harden STRICT_MODULE_RWX Peter Zijlstra
2020-04-03 20:31 ` Kees Cook
2020-04-08 15:32 ` Jessica Yu
2020-04-08 15:43   ` [PATCH] module: break nested ARCH_HAS_STRICT_MODULE_RWX and STRICT_MODULE_RWX #ifdefs Jessica Yu
2020-04-08 15:57   ` [PATCH v2] module: Harden STRICT_MODULE_RWX Peter Zijlstra
2020-04-08 16:20     ` Jessica Yu
2020-08-08  8:12 ` Mauro Carvalho Chehab
2020-08-10  9:25   ` Jessica Yu
2020-08-10 15:06     ` Jessica Yu
2020-08-11 14:34       ` Mauro Carvalho Chehab
2020-08-11 14:55         ` peterz
2020-08-11 15:27           ` Mauro Carvalho Chehab
2020-08-11 16:01             ` Jessica Yu
2020-08-11 16:57               ` Will Deacon
2020-08-11 17:59               ` peterz
2020-08-11 21:29                 ` Peter Zijlstra
2020-08-12  8:56               ` Ard Biesheuvel
2020-08-12 10:40                 ` peterz
2020-08-12 11:41                   ` Jessica Yu [this message]
2020-08-12 13:14                     ` H.J. Lu
2020-08-12 12:56                   ` Will Deacon
2020-08-12 14:15                     ` Szabolcs Nagy
2020-08-12 16:00                       ` Jessica Yu
2020-08-12 16:37                         ` Ard Biesheuvel
2020-08-12 16:42                           ` Szabolcs Nagy
2020-08-13  9:00                             ` Will Deacon
2020-08-12 20:00                           ` Peter Zijlstra
2020-08-13  8:36                             ` Ard Biesheuvel
2020-08-13 13:04                               ` Jessica Yu
2020-08-13 13:07                                 ` Ard Biesheuvel
2020-08-21 12:20                                   ` Will Deacon
2020-08-21 12:27                                     ` Ard Biesheuvel
2020-08-21 12:30                                       ` Will Deacon
2020-08-22 13:47                                         ` Ard Biesheuvel
2020-08-24 15:24                                           ` Jessica Yu
2020-08-25  1:54                                             ` Masahiro Yamada
2020-08-31  9:46                                         ` Jessica Yu
2020-08-31 10:42                                           ` Masahiro Yamada
2020-08-31 13:25                                             ` Ard Biesheuvel
2020-08-31 15:31                                               ` Jessica Yu
2020-08-31 15:46                                               ` Masahiro Yamada
2020-09-03 12:37                                             ` Jessica Yu
2020-09-01 12:51                                           ` Will Deacon

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=20200812114127.GA10824@linux-8ccs.fritz.box \
    --to=jeyu@kernel.org \
    --cc=ardb@kernel.org \
    --cc=binutils@sourceware.org \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mbenes@suse.cz \
    --cc=mchehab+huawei@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).