The generic ABI says:
Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in descsz.
Our parsing code currently aligns n_namesz. Fix the bug by aligning the start
offset of the descriptor instead. This issue has been benign because the primary
uses of sh_addralign=8 notes are .note.gnu.property, where
sizeof(Elf_Nhdr) + sizeof("GNU") = 16 (already aligned by 8).
In practice, many 64-bit systems incorrectly use sh_addralign=4 notes.
We can use sh_addralign (= p_align) to decide the descriptor padding.
Treat an alignment of 0 and 1 as 4. This approach matches modern GNU readelf
(since 2018).
We have a few tests incorrectly using sh_addralign=0. We may make our behavior
stricter after fixing these tests.
Linux kernel dumped core files use p_align=0 notes, so we need to support the
case for compatibility.
This will permit p_align values of 2 and 3, and treat them as 4. Should we instead reject those too? The error message also is not techincally accurate ("is not 4 or 8"), since it could be 0 (or 1/2/3) and be handled by this code. I'm okay with that not changing if we are excluding other values, for convenience of wording though.