All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nik.borisov@suse.com>
To: Kees Cook <kees@kernel.org>, Jeff Johnson <quic_jjohnson@quicinc.com>
Cc: 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
Subject: Re: [PATCH] x86/boot: add prototype for __fortify_panic()
Date: Sat, 1 Jun 2024 10:27:28 +0300	[thread overview]
Message-ID: <a54db95c-e22a-4e13-ae4b-6a5a67d1c49b@suse.com> (raw)
In-Reply-To: <202405310923.78257B2B3@keescook>



On 31.05.24 г. 19:28 ч., 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:

fortify-strings.h is used in include/linux/string.h. However all the 
files in the decompressor are using a local copy of string.h and not the 
kernel-wide. When pre-processing misc.c with FORTIFY_SOURCE enabled 
here's the status:

$ grep -i fortify  arch/x86/boot/compressed/misc.i
void __fortify_panic(const u8 reason, size_t avail, size_t size)

It seems the decompressor is not using fortify-string at all because 
it's not using the global string.h ?



> 
> 
> 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.)
> 

  parent reply	other threads:[~2024-06-01  7:27 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
2024-05-31 18:34         ` Dan Carpenter
2024-06-01  7:27       ` Nikolay Borisov [this message]
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=a54db95c-e22a-4e13-ae4b-6a5a67d1c49b@suse.com \
    --to=nik.borisov@suse.com \
    --cc=bp@alien8.de \
    --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=quic_jjohnson@quicinc.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.