lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 24 May 2023 16:15:23 +0200
From: Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 netdev@...r.kernel.org, pabeni@...hat.com, shuah@...nel.org
Subject: Re: [BUG] selftests: af_unix: unix:diag.c does not compile on
 AlmaLinux 8.7

Hi,

On 5/22/23 20:26, Kuniyuki Iwashima wrote:
>>>
>>> I launched AlmaLinux/RockyLinux 8.7 and 9.2 with images listed in the pages
>>> below.
>>>
>>>     https://wiki.almalinux.org/cloud/AWS.html#community-amis
>>>     https://rockylinux.org/cloud-images/
>>>
>>> The kernel versions in each image were :
>>>
>>>     8.7:
>>>     Alma  : 4.18.0-425.3.1.el8.x86_64
>>>     Rocky : 4.18.0-425.10.1.el8_7.x86_64
>>>
>>>     9.2:
>>>     Alma  : 5.14.0-284.11.1.el9_2.x86_64
>>>     Rocky : 5.14.0-284.11.1.el9_2.x86_64
>>>
>>> So, this is not a bug.  It's just because v4.18 does not support
>>> UNIX_DIAG_UID, which was introduced in v5.3.
>>>
>>> You should install 5.3+ kernel if you want to build the test.
>>>
>>> Thanks,
>>> Kuniyuki
>>
>> Hi, Kuniyuki,
>>
>> Good point. However, newer kernel won't save me from old /usr/include
>> headers, will it?
> 
> Sorry, I meant kernel and kernel-headers package that should be
> updated along with kernel.
> 
> You should use proper header files that match to the actual kernel
> version running on the machine.
> 
> 
>> I was actually testing the 6.4-rc3 on AlmaLinux 8.7, as it is my only
>> RHEL-based box ...
>>
>> What would then be the right action?
> 
> make headers_install ?

I would rather not to. For the installation to remain manageable,
preferably I'd have a kernel-devel RPM built.

>> If it was a #define instead of enum, I'd probably work around and
>> exclude the test that doesn't fit the kernel, or the system call
>> would return -EINVAL?
>>
>> Including from the includes that came with the kernel might be
>> a solution:
>>
>> ../../../../../include/uapi/linux/unix_diag.h:44:	UNIX_DIAG_UID,
>>
>> Alas, when I try to include, I get these ugly errors:
>>
>> [marvin@...mtodorov af_unix]$ gcc -I ../../../../../include/ diag_uid.c
>> In file included from ../../../../../include/linux/build_bug.h:5,
>>                    from ../../../../../include/linux/bits.h:21,
>>                    from ../../../../../include/linux/capability.h:18,
>>                    from ../../../../../include/linux/netlink.h:6,
>>                    from diag_uid.c:8:
>> ../../../../../include/linux/compiler.h:246:10: fatal error:
>> asm/rwonce.h: No such file or directory
>>    #include <asm/rwonce.h>
>>             ^~~~~~~~~~~~~~
> 
> FWIW, this is provided by kernel-devel package.

Actually, what is provided is essentially the same as before:

[root@...mtodorov kernel]# rpm -q --fileprovide kernel-devel-6.3.3 | grep rwonce.h
/usr/src/kernels/6.3.3-100.fc37.x86_64/arch/x86/include/generated/asm/rwonce.h	
/usr/src/kernels/6.3.3-100.fc37.x86_64/include/asm-generic/rwonce.h	
[root@...mtodorov kernel]#

>> compilation terminated.
>> [marvin@...mtodorov af_unix]$ vi +246
>> ../../../../../include/linux/compiler.h
>> [marvin@...mtodorov af_unix]$ find ../../../../../include -name rwonce.h
>> ../../../../../include/asm-generic/rwonce.h
>> [marvin@...mtodorov af_unix]$
>>
>> Minimum reproducer is:
>>
>> [marvin@...mtodorov af_unix]$ gcc -I ../../../../../include/ reproducer.c
>> In file included from ../../../../../include/linux/build_bug.h:5,
>>                    from ../../../../../include/linux/bits.h:21,
>>                    from ../../../../../include/linux/capability.h:18,
>>                    from ../../../../../include/linux/netlink.h:6,
>>                    from reproducer.c:5:
>> ../../../../../include/linux/compiler.h:246:10: fatal error:
>> asm/rwonce.h: No such file or directory
>>    #include <asm/rwonce.h>
>>             ^~~~~~~~~~~~~~
>> compilation terminated.
>> [marvin@...mtodorov af_unix]$
>>
>> [marvin@...mtodorov af_unix]$ nl reproducer.c
>>
>>        1	#define _GNU_SOURCE
>>        2	#include <linux/netlink.h>
>>
>> [marvin@...mtodorov af_unix]$
>>
>> Am I doing something very stupid right now, for actually I see
>>
>> #include <asm/rwonce.h>
>>
>> in "include/linux/compiler.h" 248L, 7843C
>>
>> while actual rwonce.h is in <asm-generic/rwonce.h>
>>
>> [marvin@...mtodorov af_unix]$ find ../../../../../include -name rwonce.h
>> ../../../../../include/asm-generic/rwonce.h
>> [marvin@...mtodorov af_unix]$
>>
>> I must be doing something wrong, for I see that the kernel compiled
>> despite not having include/asm ?
>>
>> When looking at the invocations of rwonce.h in the kernel, they seem to
>> be equally spread between <asm-generic/rwonce.h> and <asm/rwonce.h> :
>>
>> [marvin@...mtodorov af_unix]$ grep --include="*.[ch]" -n -w rwonce.h -r ../../../../.. 2> /dev/null | less
>> ../../../../../arch/alpha/include/asm/rwonce.h:33:#include <asm-generic/rwonce.h>
>> ../../../../../arch/arm64/include/asm/rwonce.h:71:#include <asm-generic/rwonce.h>
>> ../../../../../arch/arm64/kvm/hyp/include/nvhe/spinlock.h:18:#include <asm/rwonce.h>
>> ../../../../../arch/s390/include/asm/rwonce.h:29:#include <asm-generic/rwonce.h>
>> ../../../../../arch/x86/include/generated/asm/rwonce.h:1:#include <asm-generic/rwonce.h>
>> ../../../../../include/asm-generic/barrier.h:18:#include <asm/rwonce.h>
>> ../../../../../include/kunit/test.h:29:#include <asm/rwonce.h>
>> ../../../../../include/linux/compiler.h:246:#include <asm/rwonce.h>
>>
>> I figured out I must be doing something wrong or the kernel otherwise
>> would not build for me.
>>
>> Eventually, the UNIX_DIAG_UID enum is used in only one place:
>>
>>           ASSERT_EQ(attr->rta_type, UNIX_DIAG_UID);
>>
>> That particular test should fail in case of kernel older than 5.3.
> 
> We don't expect it to be run on older kernels in the first place.

Certainly.

>> However, I fell into a terrible mess where one thing breaks the other.
>>
>> I can't seem to make this work.
>>
>> Thanks,
>> Mirsad

-- 
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu

System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ