From: Borislav Petkov <bp@alien8.de>
To: Gary R Hook <ghook@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"Hook, Gary" <Gary.Hook@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"x86@kernel.org" <x86@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH] x86/mm/mem_encrypt: Disable all instrumentation for SME early boot code
Date: Mon, 8 Apr 2019 21:08:00 +0200 [thread overview]
Message-ID: <20190408190800.GL15689@zn.tnic> (raw)
In-Reply-To: <8a14050e-2516-5c0f-195d-611c6959b94b@amd.com>
On Mon, Apr 08, 2019 at 06:41:30PM +0000, Gary R Hook wrote:
> Again, not arguing. I completely understand. However, to be fair, this
> isn't about SME having trouble with those facilities, this is about
> using certain features (e.g. command line option processing) early in
> the boot. Any complex feature could have had that requirement, don't you
> think?
Sure, but then why do we need that patch at all then? Why do we need to
disable instrumentation for SME early code and not for other early code?
I mean, if you grep around the tree you can see a bunch of
KASAN_SANITIZE but in lib/ we only have
lib/Makefile:210:KASAN_SANITIZE_stackdepot.o := n
which is special. But the rest of the generic code in lib/ or
arch/x86/lib/ isn't.
Now, there's this:
arch/x86/boot/Makefile:12:KASAN_SANITIZE := n
arch/x86/boot/compressed/Makefile:20:KASAN_SANITIZE := n
which disables KASAN for all boot code.
And this is what you mean - all early boot code should not be sanitized.
Which also gives the right solution, IMO:
cmdline.o should not be sanitized only when used in the boot code. But
that is already the case.
So why do you need to disable KASAN for arch/x86/lib/cmdline.c?
Because for those two:
arch/x86/boot/cmdline.c
arch/x86/boot/compressed/cmdline.c
that should already be the case due to the Makefile defines above.
> Right. My goal was to get a conversation started, because folks are
> running into this problem when KASAN is enabled.
You say KASAN. Why is there KCOV_INSTRUMENT_cmdline.o too?
> N.B. Here's another facet of this problem: cmdline.c doesn't (today)
> contain anything that would trigger the stack protector. However, it's
> possible to enable the stack protector globally when building, right? In
> which case, a boot would fail, so we have the same issue: early boot
> code has special requirements / restrictions.
How so?
This .config boots here in a vm just fine.
$ grep STACKPROT .config
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2019-04-08 19:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 20:26 [PATCH] x86/mm/mem_encrypt: Disable all instrumentation for SME early boot code Hook, Gary
2019-04-04 20:42 ` Thomas Gleixner
2019-04-08 16:46 ` Gary R Hook
2019-04-08 16:58 ` Borislav Petkov
2019-04-08 18:41 ` Gary R Hook
2019-04-08 19:08 ` Borislav Petkov [this message]
2019-04-09 13:47 ` Lendacky, Thomas
2019-04-26 15:11 ` Gary R Hook
2019-04-26 16:24 ` Borislav Petkov
2019-04-29 20:16 ` Gary R Hook
2019-04-29 20:51 ` Borislav Petkov
2019-04-29 21:22 ` Gary R Hook
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=20190408190800.GL15689@zn.tnic \
--to=bp@alien8.de \
--cc=Gary.Hook@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=ghook@amd.com \
--cc=glider@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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.