All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Greg Ungerer <gerg@kernel.org>
Cc: linux-riscv@lists.infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, palmer@dabbelt.com,
	viro@zeniv.linux.org.uk, ebiederm@xmission.com,
	brauner@kernel.org
Subject: Re: [PATCH v2 1/2] binfmt_elf_fdpic: support 64-bit systems
Date: Tue, 11 Jul 2023 08:51:38 -0700	[thread overview]
Message-ID: <202307110851.7F2EB003@keescook> (raw)
In-Reply-To: <20230711130754.481209-2-gerg@kernel.org>

On Tue, Jul 11, 2023 at 11:07:53PM +1000, Greg Ungerer wrote:
> The binfmt_flat_fdpic code has a number of 32-bit specific data
> structures associated with it. Extend it to be able to support and
> be used on 64-bit systems as well.
> 
> The new code defines a number of key 64-bit variants of the core
> elf-fdpic data structures - along side the existing 32-bit sized ones.
> A common set of generic named structures are defined to be either
> the 32-bit or 64-bit ones as required at compile time. This is a
> similar technique to that used in the ELF binfmt loader.
> 
> For example:
> 
>   elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg
>   elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap
> 
> the choice based on ELFCLASS32 or ELFCLASS64.
> 
> Signed-off-by: Greg Ungerer <gerg@kernel.org>

This looks good an is consistent with what the regular ELF loader does
with the sized types.

Acked-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Greg Ungerer <gerg@kernel.org>
Cc: linux-riscv@lists.infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, palmer@dabbelt.com,
	viro@zeniv.linux.org.uk, ebiederm@xmission.com,
	brauner@kernel.org
Subject: Re: [PATCH v2 1/2] binfmt_elf_fdpic: support 64-bit systems
Date: Tue, 11 Jul 2023 08:51:38 -0700	[thread overview]
Message-ID: <202307110851.7F2EB003@keescook> (raw)
In-Reply-To: <20230711130754.481209-2-gerg@kernel.org>

On Tue, Jul 11, 2023 at 11:07:53PM +1000, Greg Ungerer wrote:
> The binfmt_flat_fdpic code has a number of 32-bit specific data
> structures associated with it. Extend it to be able to support and
> be used on 64-bit systems as well.
> 
> The new code defines a number of key 64-bit variants of the core
> elf-fdpic data structures - along side the existing 32-bit sized ones.
> A common set of generic named structures are defined to be either
> the 32-bit or 64-bit ones as required at compile time. This is a
> similar technique to that used in the ELF binfmt loader.
> 
> For example:
> 
>   elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg
>   elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap
> 
> the choice based on ELFCLASS32 or ELFCLASS64.
> 
> Signed-off-by: Greg Ungerer <gerg@kernel.org>

This looks good an is consistent with what the regular ELF loader does
with the sized types.

Acked-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook


  reply	other threads:[~2023-07-11 15:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 13:07 [PATCH v2 0/2] riscv: support ELF format binaries in nommu mode Greg Ungerer
2023-07-11 13:07 ` Greg Ungerer
2023-07-11 13:07 ` [PATCH v2 1/2] binfmt_elf_fdpic: support 64-bit systems Greg Ungerer
2023-07-11 13:07   ` Greg Ungerer
2023-07-11 15:51   ` Kees Cook [this message]
2023-07-11 15:51     ` Kees Cook
2023-07-11 13:07 ` [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader Greg Ungerer
2023-07-11 13:07   ` Greg Ungerer
2023-07-11 15:53   ` Kees Cook
2023-07-11 15:53     ` Kees Cook
2023-07-12  1:42     ` Greg Ungerer
2023-07-12  1:42       ` Greg Ungerer
2023-07-12 15:12   ` Stefan O'Rear
2023-07-12 15:12     ` Stefan O'Rear
2023-07-13 13:17     ` Greg Ungerer
2023-07-13 13:17       ` Greg Ungerer
2023-07-13 14:26       ` Stefan O'Rear
2023-07-13 14:26         ` Stefan O'Rear
2023-07-14 13:51         ` Greg Ungerer
2023-07-14 13:51           ` Greg Ungerer
2023-07-14 16:40           ` Stefan O'Rear
2023-07-14 16:40             ` Stefan O'Rear
2023-08-30 13:20 ` [PATCH v2 0/2] riscv: support ELF format binaries in nommu mode patchwork-bot+linux-riscv
2023-08-30 13:20   ` patchwork-bot+linux-riscv

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=202307110851.7F2EB003@keescook \
    --to=keescook@chromium.org \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=gerg@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.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 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.