Bug 1267979
Summary: | /usr/bin/mkdir is unreasonably large binary >= 2MB | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pavel Raiskup <praiskup> |
Component: | binutils | Assignee: | Nick Clifton <nickc> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | admiller, jakub, kdudka, kzak, nickc, ovasik, p, podvody, ttomecek, twaugh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 18:05:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pavel Raiskup
2015-10-01 14:01:12 UTC
Eek, also /usr/bin/{shred,sum,who} are around 2MB in the previous rpm (rel.8) while mkdir is Ok there ! I notice the i686 rpms are fine in both cases. In fact the issue is only with coreutils-8.23-{8,9}.fc22.x86_64.rpm The discrepancy seems to be a 2*1024*1024 block of NULs. `objdump -x` says this starts between: - 16 .eh_frame 00002094 000000000040fc10 000000000040fc10 0000fc10 2**3 + 16 .eh_frame 00002094 000000000040fbf0 000000000040fbf0 0000fbf0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA - 17 .init_array 00000008 0000000000612c80 0000000000612c80 00012c80 2**3 + 17 .init_array 00000008 0000000000611c80 0000000000611c80 00211c80 2**3 Later builds seem fine, so looks likes an issue already fixed? I don't see anything wrong on that. Unlike i?86, x86_64 has the ELF page size 2MB, and thus has to arrange for all binaries/libraries to be mappable even when using 2MB pages. Depending on the sizes of the RX PT_LOAD, RW PT_LOAD and the RELRO region it is sometimes needed to insert padding in between the segments, up to, but not including, the ELF page size. Fair enough, though something seems off, or at least may have been incorrect for a while, given the small size of the binaries, and the "normal" sized binaries in recent builds This is still reproducible on my up2date Fedora 22. If I build coreutils-8.23-11.fc22, the resulting mkdir binary has size 2.4M. If I build coreutils-8.24-4.fc23, the resulting mkdir binary has size 374K. The actual contents of mkdir.{c,o} has no impact on the resulting size of mkdir executable. If I take libcoreutils.a from from f22 and link it with mkdir.o, selinux.o and prog-fprintf.o from f23, it results in huge mkdir, but not vice versa. Note that building the same source code on el7 does not result in such a huge binary, which makes me suspect that a 2 MiB padding is not actually needed by x86_64 ELF for mkdir. (In reply to Jakub Jelinek from comment #2) > I don't see anything wrong on that. Unlike i?86, x86_64 has the ELF page > size 2MB, and thus has to arrange for all binaries/libraries to be mappable > even when using 2MB pages. Depending on the sizes of the RX PT_LOAD, RW > PT_LOAD and the RELRO region it is sometimes needed to insert padding in > between the segments, up to, but not including, the ELF page size. Where's this documented btw? Looking at binfmt_elf [0], I see that the default page size 4096 (1 << 12) is being used; on the other hand 2MB is (1 << 21), might be a typo? [0]: http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L69 Supposedly psABI? x86-64 uses: #define ELF_MAXPAGESIZE 0x200000 #define ELF_MINPAGESIZE 0x1000 #define ELF_COMMONPAGESIZE 0x1000 which means that the ELF files support 4KB, 64KB as well as 2MB pagesize, and if page size is 4KB, relro is fully functional, otherwise only a portion of the region (or none) might be protected. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |