linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hajime Tazaki <thehajime@gmail.com>
To: ebiederm@xmission.com
Cc: linux-um@lists.infradead.org, ricarkol@google.com,
	Liam.Howlett@oracle.com, kees@kernel.org,
	viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic
Date: Fri, 13 Dec 2024 16:19:46 +0900	[thread overview]
Message-ID: <m2r06c59t9.wl-thehajime@gmail.com> (raw)
In-Reply-To: <87r06d0ymg.fsf@email.froward.int.ebiederm.org>


Hello Eric,

thanks for the feedback.

On Thu, 12 Dec 2024 23:22:47 +0900,
Eric W. Biederman wrote:
> 
> Hajime Tazaki <thehajime@gmail.com> writes:
> 
> > As UML supports CONFIG_MMU=n case, it has to use an alternate ELF
> > loader, FDPIC ELF loader.  In this commit, we added necessary
> > definitions in the arch, as UML has not been used so far.  It also
> > updates Kconfig file to use BINFMT_ELF_FDPIC under !MMU environment.
> 
> Why does the no mmu case need an alternative elf loader?

I was simply following the way how other nommu architectures (riscv,
etc) did.

> Last time I looked the regular binfmt_elf works just fine
> without an mmu.  I looked again and at a quick skim the
> regular elf loader still looks like it will work without
> an MMU.

I'm wondering how you looked at it and how you see that it works
without MMU.

> You would need ET_DYN binaries just so they will load and run
> in a position independent way.  But even that seems a common
> configuration even with a MMU these days.

Yes, our perquisite for this nommu port is to use PIE binaries so,
ET_DYN assumption works fine for the moment.

> There are some funny things in elf_fdpic where it departs
> from the ELF standard and is no fun to support unless it
> is necessary.  So I am not excited to see more architectures
> supporting ELF_FDPIC.

I understand.

I also wish to use the regular binfmt_elf, but it doesn't allow me to
compile with !CONFIG_MMU right now.

I've played a little bit with touching binfmt_elf.c, but not finished
yet with a trivial attempt.

sorry, i'm not familiar with this part but wish to fix it for
nommu+ET_EYN if possible with a right background information.

-- Hajime


  reply	other threads:[~2024-12-13  7:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1733998168.git.thehajime@gmail.com>
2024-12-12 10:12 ` Hajime Tazaki
2024-12-12 14:22   ` Eric W. Biederman
2024-12-13  7:19     ` Hajime Tazaki [this message]
2024-12-13 20:01       ` Eric W. Biederman
2024-12-13 21:23         ` Hajime Tazaki
2024-12-13 21:53           ` Eric W. Biederman
2024-12-13 22:21             ` Hajime Tazaki
2024-12-18  5:13   ` 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=m2r06c59t9.wl-thehajime@gmail.com \
    --to=thehajime@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=jack@suse.cz \
    --cc=kees@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-um@lists.infradead.org \
    --cc=ricarkol@google.com \
    --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