linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Eric Biederman <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Greg Ungerer <gerg@linux-m68k.org>,
	Mike Frysinger <vapier@gentoo.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v2] binfmt_flat: do not stop relocating GOT entries prematurely on riscv
Date: Fri, 15 Apr 2022 02:11:39 +0000	[thread overview]
Message-ID: <YljUWpq42t1gQFRf@x1-carbon> (raw)
In-Reply-To: <9a9a4dcf-0ea1-01ac-d599-16c10b547beb@opensource.wdc.com>

On Fri, Apr 15, 2022 at 10:13:31AM +0900, Damien Le Moal wrote:
> On 4/15/22 10:08, Niklas Cassel wrote:
> > On Fri, Apr 15, 2022 at 09:56:38AM +0900, Damien Le Moal wrote:
> >> On 4/15/22 09:30, Niklas Cassel wrote:
> >>> On Fri, Apr 15, 2022 at 08:51:27AM +0900, Damien Le Moal wrote:
> >>>> On 4/14/22 18:10, Niklas Cassel wrote:
> > 
> > (snip)
> > 
> >> So if we are sure that we can just skip the first 16B/8B for riscv, I
> >> would not bother checking the header content. But as mentioned, the
> >> current code is fine too.
> > 
> > That was my point, I'm not sure that we can be sure that we can always
> > skip it in the future. E.g. if the elf2flt linker script decides to swap
> > the order of .got and .got.plt for some random reason in the future,
> > we would skip data that really should have been relocated.
> 
> Good point. Your current patch is indeed better then. BUT that would also
> mean that the skip header function needs to be called inside the loop
> then, no ? If the section orders are reversed, we would still need to skip
> that header in the middle of the relocation loop...

So this is theoretical, but if the sections were swapped in the linker
script, and we have the patch in $subject applied, we will not skip data
that needs to be relocated. But after relocating all the entries in the
.got section we will still break too early, if we actually had any
.got.plt entries after the .got.plt header. The .got.plt entries would
not get relocated.

However, the elf2flt maintainer explicitly asked ut to fix the kernel or
binutils, so that they can continue using the exact same linker script
that it has been using forever. (And we shouldn't need to change binutils
just for the bFLT format.)

So the chance that the linker script changes in practice is really small.
(This .got.plt vs .got hasn't changed in 19 years.)

But if it does, we will just have one problem instead of two :)
However, I think that applying this patch is sufficient for now,
since it makes the code work with the existing elf2flt linker script.

Adapting the code to also handle this theoretical layout of the linker
script would just complicate things even more. I'm not even sure if we
would be able to handle this case, since the information about the .got
and .got.plt section sizes is lost once the ELF has been converted to
bFLT.


Kind regards,
Niklas

  reply	other threads:[~2022-04-15  2:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14  9:10 Niklas Cassel
2022-04-14 23:05 ` Kees Cook
2022-04-15  1:24   ` Niklas Cassel
2022-04-14 23:27 ` Kees Cook
2022-04-14 23:41   ` Damien Le Moal
2022-04-15  1:26   ` Konstantin Ryabitsev
2022-04-16  0:14     ` Kees Cook
2022-04-14 23:51 ` Damien Le Moal
2022-04-15  0:30   ` Niklas Cassel
2022-04-15  0:56     ` Damien Le Moal
2022-04-15  1:08       ` Niklas Cassel
2022-04-15  1:13         ` Damien Le Moal
2022-04-15  2:11           ` Niklas Cassel [this message]
2022-04-15  2:14             ` Damien Le Moal
2022-04-20  4:04     ` Greg Ungerer
2022-04-20 14:58       ` [PATCH] binfmt_flat: Remove shared library support Eric W. Biederman
2022-04-20 16:17         ` Palmer Dabbelt
2022-04-20 16:59           ` Rich Felker
2022-04-20 17:47             ` Kees Cook
2022-04-20 20:04               ` Arnd Bergmann
2022-04-20 20:23                 ` Rich Felker
2022-04-20 23:00                   ` Damien Le Moal
2022-04-25  3:38               ` Rob Landley
2022-04-25  7:40                 ` Greg Ungerer
2022-04-20 23:36         ` Damien Le Moal
2022-04-20 23:53         ` Greg Ungerer
2022-04-21  6:52           ` Geert Uytterhoeven
2022-04-21  7:12             ` Arnd Bergmann
2022-04-22 10:26               ` Vladimir Murzin
2022-04-22 15:18               ` Patrice CHOTARD
2022-04-21 12:43             ` Rich Felker
2022-04-25  3:50               ` Rob Landley
2022-04-21  0:05         ` (subset) " Kees Cook
2022-04-16  4:25 ` [PATCH v2] binfmt_flat: do not stop relocating GOT entries prematurely on riscv Kees Cook

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=YljUWpq42t1gQFRf@x1-carbon \
    --to=niklas.cassel@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=ebiederm@xmission.com \
    --cc=gerg@linux-m68k.org \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=stable@vger.kernel.org \
    --cc=vapier@gentoo.org \
    --cc=viro@zeniv.linux.org.uk \
    /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