On Fri, 2 Oct 2020 at 23:00, Richard Henderson
<richard.hender...@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.hender...@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
