linux-kernel - Re: [kees:for-next/kspp 21/25] drivers/misc/lkdtm/stackleak.c:17:39: error: call to undeclared function 'stackleak_task_low_bound'; ISO C99 and later do not support implicit function declarations

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:   Thu, 5 May 2022 09:25:39 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
        kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org
Subject: Re: [kees:for-next/kspp 21/25] drivers/misc/lkdtm/stackleak.c:17:39:
 error: call to undeclared function 'stackleak_task_low_bound'; ISO C99 and
 later do not support implicit function declarations

On Thu, May 05, 2022 at 01:45:37PM +0100, Mark Rutland wrote:
> Hi Kees,
> 
> I hadn't realised the LKDTM STACKLEAK test could be built with
> CONFIG_STACKLEAK=n, and my rework of that depends upon helpers that only exist
> when CONFIG_STACKLEAK=y.
> 
> IMO the test is nonsensical for CONFIG_STACKLEAK=n, and I reckon we should
> either:
> 
> a) Not build the stackleak test at all when CONFIG_STACKLEAK=n
> 
> b) Have a small stub that just logs that CONFIG_STACKLEAK=n and the test is
>    being skipped.
> 
> Do you have any preference between the two?

Since it's looking for a specific poison, it doesn't make sense to look
for this property as magically appearing (where as this kind of thing
sometimes exists for other tests: did the hypervisor block it instead of
the kernel, etc)

So, yeah, I'd wrap it in an ifdef with an else: XFAIL.

-- 
Kees Cook