All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Laurent Vivier" <laurent@vivier.eu>
Subject: Re: [PATCH v10 7/8] linux-user/elfload: Parse NT_GNU_PROPERTY_TYPE_0 notes
Date: Thu, 8 Oct 2020 15:02:13 +0100	[thread overview]
Message-ID: <CAFEAcA8jBAKe_tWAKzAXq4LFO5vk1H8AZN+s+3oWsLfoRugQdQ@mail.gmail.com> (raw)
In-Reply-To: <20201002215955.254866-8-richard.henderson@linaro.org>

On Fri, 2 Oct 2020 at 23:00, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> For aarch64, this includes the GNU_PROPERTY_AARCH64_FEATURE_1_BTI bit,
> which indicates that the image should be mapped with guarded pages.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> v9: Only map the startup executable with BTI; anything else must be
>     handled by the interpreter.
> v10: Split out preparatory patches (pmm).

> @@ -2467,6 +2467,50 @@ static void load_elf_image(const char *image_name, int image_fd,
>                  goto exit_errmsg;
>              }
>              *pinterp_name = interp_name;
> +        } else if (eppnt->p_type == PT_GNU_PROPERTY) {
> +            /* Process NT_GNU_PROPERTY_TYPE_0. */
> +            const uint32_t gnu0_magic = const_le32('G' | 'N' << 8 | 'U' << 16);
> +            uint32_t note[7];
> +
> +            /*
> +             * The note contents are 7 words, but depending on LP64 vs ILP32
> +             * there may be an 8th padding word at the end.  Check for and
> +             * read the minimum size.  Further checks below will validate
> +             * that the sizes of everything involved are as we expect.
> +             */
> +            if (eppnt->p_filesz < sizeof(note)) {
> +                continue;
> +            }
> +            if (eppnt->p_offset + eppnt->p_filesz <= BPRM_BUF_SIZE) {
> +                memcpy(note, bprm_buf + eppnt->p_offset, sizeof(note));
> +            } else {
> +                retval = pread(image_fd, note, sizeof(note), eppnt->p_offset);
> +                if (retval != sizeof(note)) {
> +                    goto exit_perror;
> +                }
> +            }
> +#ifdef BSWAP_NEEDED
> +            for (i = 0; i < ARRAY_SIZE(note); ++i) {
> +                bswap32s(note + i);
> +            }
> +#endif
> +            /*
> +             * Check that this is a NT_GNU_PROPERTY_TYPE_0 note.
> +             * Again, descsz includes padding.  Full size validation
> +             * awaits checking the final payload.
> +             */
> +            if (note[0] != 4 ||                       /* namesz */
> +                note[1] < 12 ||                       /* descsz */
> +                note[2] != NT_GNU_PROPERTY_TYPE_0 ||  /* type */
> +                note[3] != gnu0_magic) {              /* name */

note[2] and note[3] are both basically magic numbers, AIUI.
Why do we have a #define for one but we assemble the other
with a const_le32() expression ?

> +                continue;
> +            }
> +#ifdef TARGET_AARCH64
> +            if (note[4] == GNU_PROPERTY_AARCH64_FEATURE_1_AND &&
> +                note[5] == 4) {
> +                info->note_flags = note[6];
> +            }

The spec for the .note.gnu.property section (which AIUI is
https://raw.githubusercontent.com/wiki/hjl-tools/linux-abi/linux-abi-draft.pdf
) says that the n_desc (words 4 and up) is an array of program
properties. There doesn't seem to be any guarantee that there
is only one entry or that the FEATURE_1_AND entry is the first
in the list. Don't we need to iterate through the array to find
matches? This seems to be how the kernel does it:
 https://elixir.bootlin.com/linux/latest/source/fs/binfmt_elf.c#L786

(Is it worth adding the infrastructure to parse notes generically
the way the kernel has? I dunno if we think it's likely we'll
want to do this for more note types and/or other architectures
in future, so it might just be pointless complexity.)

thanks
-- PMM


  reply	other threads:[~2020-10-08 14:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 21:59 [PATCH v10 0/8] linux-user: User support for AArch64 BTI Richard Henderson
2020-10-02 21:59 ` [PATCH v10 1/8] linux-user/aarch64: Reset btype for signals Richard Henderson
2020-10-02 21:59 ` [PATCH v10 2/8] linux-user: Set PAGE_TARGET_1 for TARGET_PROT_BTI Richard Henderson
2020-10-02 21:59 ` [PATCH v10 3/8] include/elf: Add defines related to GNU property notes for AArch64 Richard Henderson
2020-10-02 21:59 ` [PATCH v10 4/8] linux-user/elfload: Fix coding style in load_elf_image Richard Henderson
2020-10-03 17:34   ` Philippe Mathieu-Daudé
2020-10-08 13:03   ` Peter Maydell
2020-10-02 21:59 ` [PATCH v10 5/8] linux-user/elfload: Adjust iteration over phdr Richard Henderson
2020-10-03 17:51   ` Philippe Mathieu-Daudé
2020-10-08 13:03   ` Peter Maydell
2020-10-02 21:59 ` [PATCH v10 6/8] linux-user/elfload: Move PT_INTERP detection to first loop Richard Henderson
2020-10-03 17:38   ` Philippe Mathieu-Daudé
2020-10-03 18:05     ` Philippe Mathieu-Daudé
2020-10-02 21:59 ` [PATCH v10 7/8] linux-user/elfload: Parse NT_GNU_PROPERTY_TYPE_0 notes Richard Henderson
2020-10-08 14:02   ` Peter Maydell [this message]
2020-10-08 17:13     ` Richard Henderson
2020-10-02 21:59 ` [PATCH v10 8/8] tests/tcg/aarch64: Add bti smoke test Richard Henderson
2020-10-04  1:34 ` [PATCH v10 0/8] linux-user: User support for AArch64 BTI no-reply

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=CAFEAcA8jBAKe_tWAKzAXq4LFO5vk1H8AZN+s+3oWsLfoRugQdQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=laurent@vivier.eu \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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.