All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Johnson <quic_jjohnson@quicinc.com>
To: Kees Cook <kees@kernel.org>
Cc: Nikolay Borisov <nik.borisov@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, <linux-kernel@vger.kernel.org>,
	<linux-hardening@vger.kernel.org>,
	<kernel-janitors@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH] x86/boot: add prototype for __fortify_panic()
Date: Fri, 31 May 2024 11:28:58 -0700	[thread overview]
Message-ID: <c19aa2df-adaa-463e-b3a4-843f04538a2b@quicinc.com> (raw)
In-Reply-To: <202405310923.78257B2B3@keescook>

On 5/31/2024 9:28 AM, Kees Cook wrote:
> On Thu, May 30, 2024 at 09:23:36AM -0700, Jeff Johnson wrote:
>> On 5/30/2024 8:42 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 29.05.24 г. 21:09 ч., Jeff Johnson wrote:
>>>> As discussed in [1] add a prototype for __fortify_panic() to fix the
>>>> 'make W=1 C=1' warning:
>>>>
>>>> arch/x86/boot/compressed/misc.c:535:6: warning: symbol '__fortify_panic' was not declared. Should it be static?
>>>
>>> Actually doesn't it make sense to have this defined under ../string.h ? 
>>> Actually given that we don't have any string fortification under the 
>>> boot/  why have the fortify _* functions at all ?
>>
>> I'll let Kees answer these questions since I just took guidance from him :)
> 
> Ah-ha, I see what's happening. When not built with
> CONFIG_FORTIFY_SOURCE, fortify-string.h isn't included. But since misc.c
> has the function definition, we get a warning that the function
> declaration was never seen. This is likely the better solution:
> 
> 
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index b70e4a21c15f..3f21a5e218f8 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -532,7 +532,9 @@ asmlinkage __visible void *extract_kernel(void *rmode, unsigned char *output)
>  	return output + entry_offset;
>  }
>  
> +#ifdef CONFIG_FORTIFY_SOURCE
>  void __fortify_panic(const u8 reason, size_t avail, size_t size)
>  {
>  	error("detected buffer overflow");
>  }
> +#endif
> 
> 
> Jeff, can you test this? (I still haven't been able to reproduce the
> warning.)

Adding Dan since this comes during:
  CHECK   arch/x86/boot/compressed/misc.c

What version of smatch are you using? I'm using v0.5.0-8639-gff1cc4d453ff

In the build where I'm seeing this issue I have:
CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
CONFIG_FORTIFY_SOURCE=y
CONFIG_FORTIFY_KUNIT_TEST=m

So that conditional compilation won't make a difference.

Also note that misc.c doesn't include the standard include/linux/string.h but
instead includes the stripped down arch/x86/boot/string.h, so fortify-string.h
isn't included.

This seems to come back around to the question that Nikolay asked, which part
of the boot code actually needs this?

/jeff


  reply	other threads:[~2024-05-31 18:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29 18:09 [PATCH] x86/boot: add prototype for __fortify_panic() Jeff Johnson
2024-05-30 15:42 ` Nikolay Borisov
2024-05-30 16:23   ` Jeff Johnson
2024-05-30 16:46     ` Borislav Petkov
2024-05-31 16:53       ` Kees Cook
2024-05-31 19:08         ` Borislav Petkov
2024-05-31 20:46           ` Kees Cook
2024-05-31 20:49             ` Borislav Petkov
2024-05-31 21:06               ` Kees Cook
2024-05-31 21:20                 ` Borislav Petkov
2024-05-31 21:34                   ` Kees Cook
2024-05-31 21:45                     ` Borislav Petkov
2024-05-31 22:20                       ` Jeff Johnson
2024-05-31 16:28     ` Kees Cook
2024-05-31 18:28       ` Jeff Johnson [this message]
2024-05-31 18:34         ` Dan Carpenter
2024-06-01  7:27       ` Nikolay Borisov
2024-06-10  7:08         ` Nikolay Borisov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c19aa2df-adaa-463e-b3a4-843f04538a2b@quicinc.com \
    --to=quic_jjohnson@quicinc.com \
    --cc=bp@alien8.de \
    --cc=dan.carpenter@linaro.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kees@kernel.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.