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]
Message-ID: <0891f17ff638cb5755a1b0d3ba7ebda6b02d9d51.camel@physik.fu-berlin.de>
Date:   Thu, 02 Nov 2023 21:32:16 +0100
From:   John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>, linux-sh@...r.kernel.org
Subject: Re: arch/sh/boot/compressed/misc.c:118:6: warning: no previous
 prototype for 'arch_ftrace_ops_list_func'

Hi Steven!

On Thu, 2023-11-02 at 16:28 -0400, Steven Rostedt wrote:
> 
> I'm not sure it really needs to be fixed. But I won't complain if you do.
> 
> Anyway, the issue is that arch/sh/boot/compressed/misc.c is not part of the
> kernel. It's the code that decompresses the vmlinuz (or whatever sh calls
> it). That is, the build will build the kernel (vmlinux) then compress it
> and add a program to decompress it (vmlinuz). At least this is what is done
> on x86, and I'm assuming it's the same for sh.
> 
> The vmlinuz is stored on disk, the boot loader loads it into memory and
> executes it. The vmlinuz has the code to decompress the attached vmlinux
> into memory and jump to that when its done.
> 
> Thus, you have two executables. The kernel and this wrapper program that
> decompresses the kernel at start up (and is freed right afterward). This
> wrapper code exists in arch/sh/boot (and in arch/x86/boot for x86).
> 
> As this code needs to be built just like the kernel, it uses the same
> linker script as the kernel (vmlinux.lds.h), which has some references to
> vmlinux code. Those include (from the warnings in this "bug"):
> 
>    arch/sh/boot/compressed/misc.c:115:6: warning: no previous prototype for 'ftrace_stub' [-Wmissing-prototypes]
>      115 | void ftrace_stub(void)
>          |      ^~~~~~~~~~~
> > > arch/sh/boot/compressed/misc.c:118:6: warning: no previous prototype for 'arch_ftrace_ops_list_func' [-Wmissing-prototypes]
>      118 | void arch_ftrace_ops_list_func(void)
>          |      ^~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Which are referenced by include/asm-generic/vmlinux.lds.h, and if you do
> not include them, then linking will fail as these will be undefined
> references.
> 
> Note, that bug also has:
> 
>    arch/sh/boot/compressed/misc.c:109:6: warning: no previous prototype for '__stack_chk_fail' [-Wmissing-prototypes]
>      109 | void __stack_chk_fail(void)
>          |      ^~~~~~~~~~~~~~~~
> 
> Which has a reference added by the compiler for stack protection options.
> 
>    arch/sh/boot/compressed/misc.c:128:6: warning: no previous prototype for 'decompress_kernel' [-Wmissing-prototypes]
>      128 | void decompress_kernel(void)
> 
> Which is called by arch/sh/boot/compressed/head_*.S, which is assembly.
> 
> None of these really need prototypes, as there's nothing that would use the
> prototypes. The two ftrace function stubs do not even add parameters to
> match the vmlinux prototype, because they are never called. The other two
> functions are either for gcc internal usage or called from assembly, both
> which do not care about seeing a prototype either.
> 
> If you want to quiet gcc, you can add in arch/sh/boot/compressed, a header
> file called "stubs.h" that just has:
> 
> #ifndef _STUBS_H
> #define _STUBS_H
> 
> /* Quiet gcc complaining about these prototypes */
> 
> void __stack_chk_fail(void);
> void decompress_kernel(void);
> void ftrace_stub(void);
> void arch_ftrace_ops_list_func(void);
> 
> #endif
> 
> and include that header.

Thank you for the very detailed explanation. I will look into fixing this for v6.7.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ