[bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir.

[Efraim Flashner]

On Fri, Sep 25, 2020 at 03:36:46PM +0200, Danny Milosavljevic wrote:
> > >Why is this not an issue with i686 on x86_64 kernels?  
> > 
> > I'm not sure.  I'll check.
> 
> $ cat a00.c
> #include <stdio.h>
> #if defined( __ILP32__ )
> #warning ILP32
> #endif
> int main() {
>         return sizeof(off_t);
> }
> $ LC_ALL=C guix environment -s i686-linux gcc-toolchain -- gcc -o a00 a00.c
> a00.c:3:2: warning: #warning ILP32 [-Wcpp]
>     3 | #warning ILP32
>       |  ^~~~~~~
> $ ./a00
> $ echo $?
> 4
> 
> That means they are using the Linux kernel's X86_32 ABI.
> It has its own getdents64 system call that returns another value for d_off.
> 
> $ LC_ALL=C guix environment -s i686-linux gcc-toolchain -- gcc -o a00 
> -D_FILE_OFFSET_BITS=64 a00.c
> a00.c:3:2: warning: #warning ILP32 [-Wcpp]
>     3 | #warning ILP32
>       |  ^~~~~~~
> $ ./a00
> $ echo $?
> 8
> 
> That is why __i686__ is not affected--at the cost of the kernel lying to us
> about the file system.
> 
> Note that I also tried printing the actual d_off values[1]--on ILP32, even 
> with
> _FILE_OFFSET_BITS=64, the VALUES are still 32 bits, and the same values as
> without _FILE_OFFSET_BITS.  The d_off SLOT gets bigger on 
> _FILE_OFFSET_BITS=64.
> 
> (I also tried printing the actual d_off values[1] on x86_64 without any guix
> environment -s, I get entirely different d_off values!!)
> 
> I also tried the former on native ARMHF--you get 32 bits d_off values.  And 
> d_off
> is always the same size as off_t.
> 
> off_t size changes depending on _FILE_OFFSET_BITS.
> 
> I do not have access to a real aarch64 machine--so no idea how it is there.
> That would be the most interesting case, because those don't have X86_32,
> so ILP32 is either not present or implemented differently.
> 
> ppc64 would also be interesting...
> 
> Test result of [1]:
> 
> system _FILE_OFFSET_BITS off_t   d_off-sizeof   d_off-values
> -------------------------------------------------------------
> x86_64 -                 8 Byte  8 Byte         8 Byte
> i686   -                 4 Byte  4 Byte         4 Byte
> i686   64                8 Byte  8 Byte         4 Byte
> i686   32                4 Byte  4 Byte         4 Byte
> i686   7                 4 Byte  4 Byte         4 Byte
> armhf  -                 4 Byte  4 Byte         4 Byte
> armhf  64                8 Byte  8 Byte         4 Byte
> armhf  32                4 Byte  4 Byte         4 Byte
> armhf  7                 4 Byte  4 Byte         4 Byte
> 
> This is all without qemu--in order to simplify the test case.
> 
> So I take it ext4 has some special compilation mode for 32 bits...
> 
> Could someone please test [1] on (real!) aarch64 and ppc64 and ppc32
> machines?
> 
> [1] $ cat a00.c 
> #include <stdio.h>
> #include <errno.h>
> #include <assert.h>
> #include <dirent.h>
> #if defined( __ILP32__ )
> #warning ILP32
> #endif
> 
> int main() {
>         DIR* d;
>         struct dirent* ent;
>         d = opendir("/tmp");
>         errno = 0;
>         assert(sizeof(ent->d_off) == sizeof(off_t));
>         while ((ent = readdir(d)) != NULL) {
>                 printf("%llu\n", (unsigned long long) ent->d_off);
>         }
>         if (errno)
>                 perror("readdir");
>         return sizeof(off_t);
missing } at the end

tested on my ibook G4:
(I believe for powerpc the 32-bit is defined as __powerpc__)

(ins)efraim@g4:~$ gcc -o a00 a00.c
(ins)efraim@g4:~$ ./a00
404218588
473424804
681064434
708508942
805784207
980330722
1080794671
1734802884
1909818320
1923689764
2019671154
2125602108
2147483647
(ins)efraim@g4:~$ echo $?
4
(ins)efraim@g4:~$ rm a00
(ins)efraim@g4:~$ gcc -o a00 -D_FILE_OFFSET_BITS=64 a00.c
(ins)efraim@g4:~$ ./a00
404218588
473424804
681064434
708508942
805784207
980330722
1080794671
1734802884
1909818320
1923689764
2019671154
2125602108
2147483647
(ins)efraim@g4:~$ echo $?
8



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature