linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: peterz@infradead.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	keescook@chromium.org, Josh Poimboeuf <jpoimboe@redhat.com>,
	Miroslav Benes <mbenes@suse.cz>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2] module: Harden STRICT_MODULE_RWX
Date: Tue, 11 Aug 2020 18:01:35 +0200	[thread overview]
Message-ID: <20200811160134.GA13652@linux-8ccs> (raw)
In-Reply-To: <20200811172738.2d632a09@coco.lan>

+++ Mauro Carvalho Chehab [11/08/20 17:27 +0200]:
>Em Tue, 11 Aug 2020 16:55:24 +0200
>peterz@infradead.org escreveu:
>
>> On Tue, Aug 11, 2020 at 04:34:27PM +0200, Mauro Carvalho Chehab wrote:
>> >   [33] .plt              PROGBITS         0000000000000340  00035c80
>> >        0000000000000001  0000000000000000 WAX       0     0     1
>> >   [34] .init.plt         NOBITS           0000000000000341  00035c81
>> >        0000000000000001  0000000000000000  WA       0     0     1
>> >   [35] .text.ftrace[...] PROGBITS         0000000000000342  00035c81
>> >        0000000000000001  0000000000000000 WAX       0     0     1
>>
>> .plt and .text.ftrace_tramplines are buggered.
>>
>> arch/arm64/kernel/module.lds even marks then as NOLOAD.
>
>Hmm... Shouldn't the code at module_enforce_rwx_sections() or at
>load_module() ignore such sections instead of just rejecting probing
>all modules?
>
>I mean, if the existing toolchain is not capable of excluding
>those sections, either the STRICT_MODULE_RWX hardening should be
>disabled, if a broken toolchain is detected or some runtime code
>should handle such sections on a different way.

Hi Mauro, thanks for providing the readelf output. The sections marked 'WAX'
are indeed the reason why the module loader is rejecting them.

Interesting, my cross-compiled modules do not have the executable flag -

  [38] .plt              NOBITS           0000000000000340  00038fc0
       0000000000000001  0000000000000000  WA       0     0     1
  [39] .init.plt         NOBITS           0000000000000341  00038fc0
       0000000000000001  0000000000000000  WA       0     0     1
  [40] .text.ftrace_tram NOBITS           0000000000000342  00038fc0
       0000000000000001  0000000000000000  WA       0     0     1

ld version:

    GNU ld (GNU Binutils) 2.34
    Copyright (C) 2020 Free Software Foundation, Inc.
    This program is free software; you may redistribute it under the terms of
    the GNU General Public License version 3 or (at your option) a later version.

And gcc:

    aarch64-linux-gcc (GCC) 9.3.0
    Copyright (C) 2019 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm a bit confused about what NOLOAD actually implies in this context. From the
ld documentation - "The `(NOLOAD)' directive will mark a section to not be
loaded at run time." But these sections are marked SHF_ALLOC and are referenced
to in the module plt code. Or does it just tell the linker to not initialize it?

Adding Ard to CC, I'm sure he'd know more about the section flag specifics.

Jessica

  reply	other threads:[~2020-08-11 16:01 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 [this message]
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
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=20200811160134.GA13652@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=ardb@kernel.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).