From: Kees Cook <kees@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Jeff Johnson <quic_jjohnson@quicinc.com>,
Nikolay Borisov <nik.borisov@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
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: Fri, 31 May 2024 13:46:37 -0700 [thread overview]
Message-ID: <202405311345.D91BF6E9@keescook> (raw)
In-Reply-To: <20240531190816.GLZlogIGgpc5maOeLN@fat_crate.local>
On Fri, May 31, 2024 at 09:08:16PM +0200, Borislav Petkov wrote:
> On Fri, May 31, 2024 at 09:53:28AM -0700, Kees Cook wrote:
> > Under CONFIG_FORTIFY_SOURCE, the boot code *does* still uses
> > fortify-string.h. It lets us both catch mistakes we can discover at
> > compile and will catch egregious runtime mistakes, though the reporting
> > is much simpler in the boot code.
>
> From where I'm standing, we're not catching anything in the
> decompressor:
>
> $ objdump -D arch/x86/boot/compressed/vmlinux | grep __fortify_panic
> 0000000001bec250 <__fortify_panic>:
> $
>
> Sure, in vmlinux proper (allmodconfig) we do:
>
> objdump -D vmlinux | grep __fortify_panic | wc -l
> 1417
>
> but not in the decompressor which is special anyway.
>
> So we can just as well disable CONFIG_FORTIFY_SOURCE in the decompressor
> and not do silly prototypes.
Please do not do this. It still benefits from compile-time sanity
checking.
--
Kees Cook
next prev parent reply other threads:[~2024-05-31 20:46 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 [this message]
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
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=202405311345.D91BF6E9@keescook \
--to=kees@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--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=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.