From: Dave Hansen <dave.hansen@intel.com>
To: Adam Dunlap <acdunlap@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
David Hildenbrand <david@redhat.com>,
Mike Rapoport <rppt@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Nikunj A Dadhania <nikunj@amd.com>,
Dionna Glaze <dionnaglaze@google.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Joerg Roedel <jroedel@suse.de>, Jacob Xu <jacobhxu@google.com>
Subject: Re: [PATCH] x86/sev-es: Do not use copy_from_kernel_nofault in early #VC handler
Date: Thu, 7 Sep 2023 10:04:16 -0700 [thread overview]
Message-ID: <cb958f57-6a3a-d626-da51-53ad0e61870c@intel.com> (raw)
In-Reply-To: <CAMBK9=b9V6WxYZNrVPNV5vzBZ-mT_noBAxod=ijqrV3bUXAUyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On 9/6/23 16:25, Adam Dunlap wrote:
>> Usually, we'll add some gunk in arch/x86/boot/compressed/misc.h to
>> override the troublesome implementation. In this case, it would make a
>> lot of sense to somehow avoid touching boot_cpu_data.x86_virt_bits in
>> the first place.
> Thanks for the comment. I realize this patch is doing something a bit misleading
> here. In this case, "early" does not refer to the compressed kernel, but
> actually the regular kernel but in the stage with this early #VC handler
> vc_boot_ghcb (instead of the usual vc_raw_handle_exception). This #VC handler
> triggers for the first time on a cpuid instruction in secondary_startup_64, but
> boot_cpu_data.x86_virt_bits is not initialized until setup_arch inside of
> start_kernel, which is at the end of secondary_startup_64.
How about something like the attached patch?
It avoids passing around 'is_early' everywhere, which I'm sure we'll get
wrong at some point. If we get it wrong, we lose *ALL* the checking
that copy_from_kernel*() does in addition to the canonical checks.
The attached patch at least preserves the userspace address checks.
This also makes me wonder how much other code is called via the early
exception handlers that's subtly broken. I scanned a function or two
deep and the instruction decoding was the most guilty looking thing.
But a closer look would be appreciated.
Also, what's the root cause here? What's causing the early exception?
It is some silly CPUID leaf? Should we be more careful to just avoid
these exceptions?
[-- Attachment #2: xvb.patch --]
[-- Type: text/x-patch, Size: 1175 bytes --]
diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c
index 5a53c2cc169c..4f76c34d70a2 100644
--- a/arch/x86/mm/maccess.c
+++ b/arch/x86/mm/maccess.c
@@ -7,14 +7,24 @@
bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
{
unsigned long vaddr = (unsigned long)unsafe_src;
+ bool ret;
/*
- * Range covering the highest possible canonical userspace address
- * as well as non-canonical address range. For the canonical range
- * we also need to include the userspace guard page.
+ * Do not allow userspace addresses. This disallows
+ * normal userspace and the userspace guard page:
*/
- return vaddr >= TASK_SIZE_MAX + PAGE_SIZE &&
- __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits);
+ if (vaddr < TASK_SIZE_MAX + PAGE_SIZE)
+ return false;
+
+ /*
+ * Allow everything during early boot before 'x86_virt_bits'
+ * is initialized. Needed for instruction decoding in early
+ * exception handlers.
+ */
+ if (!boot_cpu_data.x86_virt_bits)
+ return true;
+
+ return __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits);
}
#else
bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
next prev parent reply other threads:[~2023-09-07 17:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 22:45 Adam Dunlap
2023-09-06 23:01 ` Dave Hansen
2023-09-06 23:25 ` Adam Dunlap
2023-09-07 17:04 ` Dave Hansen [this message]
2023-09-07 18:03 ` Adam Dunlap
2023-09-07 19:12 ` Dave Hansen
2023-09-07 22:30 ` Adam Dunlap
2023-09-07 22:45 ` Dave Hansen
2023-09-08 13:13 ` Tom Lendacky
2023-09-08 14:48 ` Dave Hansen
2023-09-08 15:13 ` Peter Zijlstra
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=cb958f57-6a3a-d626-da51-53ad0e61870c@intel.com \
--to=dave.hansen@intel.com \
--cc=acdunlap@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dionnaglaze@google.com \
--cc=hpa@zytor.com \
--cc=jacobhxu@google.com \
--cc=jroedel@suse.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®