.. while it used to be <= 100kB. Seems like this "regression" happened between coreutils-8.23-{8,9}.fc22.x86_64.rpm. Because that rel.9 build is about 79d651a2d90f80aed880ef226633cb2ec8afd081 commit, I doubt change in coreutils itself caused this (but still, starting with coreutils bug).
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.