All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	Jessica Yu <jeyu@kernel.org>
Cc: "Nicholas Piggin" <npiggin@gmail.com>,
	"Michal Suchánek" <msuchanek@suse.de>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] module: add elf_check_module_arch for module specific elf arch checks
Date: Wed, 16 Jun 2021 12:39:30 +1000	[thread overview]
Message-ID: <87sg1isfbx.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20210615143038.GH5077@gate.crashing.org>

Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Tue, Jun 15, 2021 at 03:41:00PM +0200, Jessica Yu wrote:
>> +++ Segher Boessenkool [15/06/21 07:50 -0500]:
>> >On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote:
>> >>+int __weak elf_check_module_arch(Elf_Ehdr *hdr)
>> >>+{
>> >>+       return 1;
>> >>+}
>> >
>> >But is this a good idea?  It isn't useful to be able to attempt to load
>> >a module not compiled for your architecture, and it increases the attack
>> >surface tremendously.  These checks are one of the few things that can
>> >*not* be weak symbols, imo.
>> 
>> Hm, could you please elaborate a bit more? This patchset is adding
>> extra Elf header checks specifically for powerpc, and the module
>> loader usually provides arch-specific hooks via weak symbols. We are
>> just providing an new hook here, which should act as a no-op if it
>> isn't used.
>> 
>> So if an architecture wants to provide extra header checks, it can do
>> so by overriding the new weak symbol. Otherwise, the weak function acts as
>> a noop. We also already have the existing elf_check_arch() check for each
>> arch and that is *not* a weak symbol.
>
> The way I read your patch the default elf_check_module_arch does not
> call elf_check_arch?  Is that clearly called elsewhere and I'm just
> dumb again?  Sorry for the distraction in that case :-/

Yeah elf_check_arch() is already called from elf_validity_check(), and
that call would remain.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	Jessica Yu <jeyu@kernel.org>
Cc: "Michal Suchánek" <msuchanek@suse.de>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	"Nicholas Piggin" <npiggin@gmail.com>
Subject: Re: [PATCH v4 1/2] module: add elf_check_module_arch for module specific elf arch checks
Date: Wed, 16 Jun 2021 12:39:30 +1000	[thread overview]
Message-ID: <87sg1isfbx.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20210615143038.GH5077@gate.crashing.org>

Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Tue, Jun 15, 2021 at 03:41:00PM +0200, Jessica Yu wrote:
>> +++ Segher Boessenkool [15/06/21 07:50 -0500]:
>> >On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote:
>> >>+int __weak elf_check_module_arch(Elf_Ehdr *hdr)
>> >>+{
>> >>+       return 1;
>> >>+}
>> >
>> >But is this a good idea?  It isn't useful to be able to attempt to load
>> >a module not compiled for your architecture, and it increases the attack
>> >surface tremendously.  These checks are one of the few things that can
>> >*not* be weak symbols, imo.
>> 
>> Hm, could you please elaborate a bit more? This patchset is adding
>> extra Elf header checks specifically for powerpc, and the module
>> loader usually provides arch-specific hooks via weak symbols. We are
>> just providing an new hook here, which should act as a no-op if it
>> isn't used.
>> 
>> So if an architecture wants to provide extra header checks, it can do
>> so by overriding the new weak symbol. Otherwise, the weak function acts as
>> a noop. We also already have the existing elf_check_arch() check for each
>> arch and that is *not* a weak symbol.
>
> The way I read your patch the default elf_check_module_arch does not
> call elf_check_arch?  Is that clearly called elsewhere and I'm just
> dumb again?  Sorry for the distraction in that case :-/

Yeah elf_check_arch() is already called from elf_validity_check(), and
that call would remain.

cheers

  reply	other threads:[~2021-06-16  2:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11  9:39 [PATCH v4 0/2] powerpc/64: Option to use ELF V2 ABI for big-endian Nicholas Piggin
2021-06-11  9:39 ` Nicholas Piggin
2021-06-11  9:39 ` [PATCH v4 1/2] module: add elf_check_module_arch for module specific elf arch checks Nicholas Piggin
2021-06-11  9:39   ` Nicholas Piggin
2021-06-14 12:06   ` Jessica Yu
2021-06-14 12:06     ` Jessica Yu
2021-06-15  2:05     ` Nicholas Piggin
2021-06-15  2:05       ` Nicholas Piggin
2021-06-15 12:17       ` Jessica Yu
2021-06-15 12:17         ` Jessica Yu
2021-06-15 12:50         ` Segher Boessenkool
2021-06-15 12:50           ` Segher Boessenkool
2021-06-15 13:41           ` Jessica Yu
2021-06-15 13:41             ` Jessica Yu
2021-06-15 14:30             ` Segher Boessenkool
2021-06-15 14:30               ` Segher Boessenkool
2021-06-16  2:39               ` Michael Ellerman [this message]
2021-06-16  2:39                 ` Michael Ellerman
2021-06-16  1:18         ` Nicholas Piggin
2021-06-16  1:18           ` Nicholas Piggin
2021-06-16 12:54           ` Jessica Yu
2021-06-16 12:54             ` Jessica Yu
2021-06-17  5:21             ` Nicholas Piggin
2021-06-17  5:21               ` Nicholas Piggin
2021-06-16  2:37         ` Michael Ellerman
2021-06-16  2:37           ` Michael Ellerman
2021-06-16 13:49           ` Jessica Yu
2021-06-16 13:49             ` Jessica Yu
2021-06-11  9:39 ` [PATCH v4 2/2] powerpc/64: Option to use ELF V2 ABI for big-endian kernels Nicholas Piggin
2021-06-11  9:39   ` Nicholas Piggin
2021-06-11  9:58   ` Michal Suchánek
2021-06-11  9:58     ` Michal Suchánek
2021-06-11 10:20     ` Michal Suchánek

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=87sg1isfbx.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=msuchanek@suse.de \
    --cc=npiggin@gmail.com \
    --cc=segher@kernel.crashing.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.