linux-kernel - implicit dependency in x86/page_64.h:task_size

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 8 Sep 2021 17:05:41 +0200
From:   Ulrich Drepper <drepper@...hat.com>
To:     linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        bp@...en8.de
Subject: implicit dependency in x86/page_64.h:task_size_max

I don't have a 5.14 kernel installed, yet, but from the looks of it
this problem still persists.

Out-of-tree modules were broken by commit
025768a966a3dde8455de46d1f121a51bacb6a77 which introduced a dependency
on a CPU feature macro in the task_size_max implementation
(X86_FEATURE_LA57) without making sure the macro is defined.  The
result is that the compiler generates an object file with an reference
to a symbol with this name.  The resulting modpost invocation catches
this.

An example for the problem exists with the blackmagic-io module. I
name it here so people can perhaps find this post.

The "solution" so far is to include <asm/cpufeatures.h> before
task_size_max is defined.

In userlevel headers we had the convention that any header should
#include all the other headers to satisfy its dependencies.  If
arch/x86/asm/page_64.h would include <asm/cpufeatures.h> first there
would be no problem with the module above but I haven't checked
whether this creates other problems.  And as I mentioned, I don't know
what the convention is.

Someone will know and perhaps we could get a patch installed with
either the missing #include added or

#ifndef X86_FEATURE_LA57
# error "you need to include <asm/cpufeatures.h> first"
#endif

Thanks.