[Toybox] [PATCH] file: don't be confused by BSS sections.

[enh]

On Wed, Mar 16, 2022 at 4:43 AM Rob Landley <rob at landley.net> wrote:

> On 3/15/22 9:30 PM, enh via Toybox wrote:
> > BSS sections are *expected* to claim a larger size than is actually
> > present in the file. Unlike program headers which have two different
> > size fields for the memory and file sizes, sections headers only have
> > one size field, so we're using the right field; we just need to ignore
> > it for our overflow checking purposes.
>
> Applied, but do you have a test for the old behavior?
>
> $ ./toybox file toybox
> toybox: ELF shared object, 64-bit LSB x86-64, dynamic
> (/lib64/ld-linux-x86-64.so.2)
>
> Didn't complain?


yeah, funny you should mention that... i woke up this morning thinking "i
should send another patch so we have better diagnostics in future", and
then seeing your mail convinced me even further. you can tell you're seeing
the bug there because it _neither_ says "stripped" nor "not stripped", and
it should always say one or the other for an ELF file. and that's exactly
why we didn't spot this bug for years --- the bad output looks fine :-(

i've sent you another patch anyway, and in addition to explicitly calling
any time we choke on an ELF file, i've added a perror_msg() for the case
where the mmap() fails... perror_exit() seemed too harsh, but perror_msg()
seemed to meet your "don't give up on _future_ files" that i assume was the
reason not to just call xmmap() and my "we should always say _something_ if
something's gone wrong".


> How about...
>
> $ cat hello.c
> int is_potato[10000000];
>
> int main(int argc, char *argv[])
> {
>   is_potato[9999999] = 42;
>
>   return is_potato[9999999];
> }
> $ gcc hello.c
> $ ./toybox file a.out
> a.out: ELF shared object, 64-bit LSB x86-64, dynamic
> (/lib64/ld-linux-x86-64.so.2),
> BuildID=de3b2aca1f5e99bad5746ca0dd9754a6a6104050
> $ echo $?
> 0
> $ readelf -a ./a.out | grep bss -A 1 | head -n 2
>   [24] .bss              NOBITS           0000000000004040  00003028
>        0000000002625a20  0000000000000000  WA       0     0     32
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220316/081ab4de/attachment.html>