From: Kees Cook <keescook@chromium.org>
To: Fangrui Song <maskray@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Eric Biederman <ebiederm@xmission.com>,
Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coredump, vmcore: Set p_align to 4 for PT_NOTE
Date: Fri, 12 May 2023 11:27:35 -0700 [thread overview]
Message-ID: <202305121126.E5AD334AA3@keescook> (raw)
In-Reply-To: <20230512022528.3430327-1-maskray@google.com>
On Fri, May 12, 2023 at 02:25:28AM +0000, Fangrui Song wrote:
> Tools like readelf/llvm-readelf use p_align to parse a PT_NOTE program
> header as an array of 4-byte entries or 8-byte entries. Currently, there
> are workarounds[1] in place for Linux to treat p_align==0 as 4. However,
> it would be more appropriate to set the correct alignment so that tools
> do not have to rely on guesswork. FreeBSD coredumps set p_align to 4 as
> well.
>
> [1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=82ed9683ec099d8205dc499ac84febc975235af6
The interesting bit from here is:
/* NB: Some note sections may have alignment value of 0 or 1. gABI
specifies that notes should be aligned to 4 bytes in 32-bit
objects and to 8 bytes in 64-bit objects. As a Linux extension,
we also support 4 byte alignment in 64-bit objects. If section
alignment is less than 4, we treate alignment as 4 bytes. */
if (align < 4)
align = 4;
else if (align != 4 && align != 8)
{
warn (_("Corrupt note: alignment %ld, expecting 4 or 8\n"),
(long) align);
return FALSE;
}
Should Linux use 8 for 64-bit processes to avoid the other special case?
(And do we need to make some changes to make sure we are actually
aligned?)
-Kees
--
Kees Cook
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Fangrui Song <maskray@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Eric Biederman <ebiederm@xmission.com>,
Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coredump, vmcore: Set p_align to 4 for PT_NOTE
Date: Fri, 12 May 2023 11:27:35 -0700 [thread overview]
Message-ID: <202305121126.E5AD334AA3@keescook> (raw)
In-Reply-To: <20230512022528.3430327-1-maskray@google.com>
On Fri, May 12, 2023 at 02:25:28AM +0000, Fangrui Song wrote:
> Tools like readelf/llvm-readelf use p_align to parse a PT_NOTE program
> header as an array of 4-byte entries or 8-byte entries. Currently, there
> are workarounds[1] in place for Linux to treat p_align==0 as 4. However,
> it would be more appropriate to set the correct alignment so that tools
> do not have to rely on guesswork. FreeBSD coredumps set p_align to 4 as
> well.
>
> [1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=82ed9683ec099d8205dc499ac84febc975235af6
The interesting bit from here is:
/* NB: Some note sections may have alignment value of 0 or 1. gABI
specifies that notes should be aligned to 4 bytes in 32-bit
objects and to 8 bytes in 64-bit objects. As a Linux extension,
we also support 4 byte alignment in 64-bit objects. If section
alignment is less than 4, we treate alignment as 4 bytes. */
if (align < 4)
align = 4;
else if (align != 4 && align != 8)
{
warn (_("Corrupt note: alignment %ld, expecting 4 or 8\n"),
(long) align);
return FALSE;
}
Should Linux use 8 for 64-bit processes to avoid the other special case?
(And do we need to make some changes to make sure we are actually
aligned?)
-Kees
--
Kees Cook
next prev parent reply other threads:[~2023-05-12 18:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 2:25 [PATCH] coredump, vmcore: Set p_align to 4 for PT_NOTE Fangrui Song
2023-05-12 2:25 ` Fangrui Song
2023-05-12 18:27 ` Kees Cook [this message]
2023-05-12 18:27 ` Kees Cook
2023-05-12 18:39 ` Fangrui Song
2023-05-12 18:39 ` Fangrui Song
2023-05-16 21:32 ` Kees Cook
2023-05-16 21:32 ` 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=202305121126.E5AD334AA3@keescook \
--to=keescook@chromium.org \
--cc=bhe@redhat.com \
--cc=brauner@kernel.org \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maskray@google.com \
--cc=vgoyal@redhat.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.