From: Dave Hansen <dave.hansen@intel.com>
To: Keno Fischer <keno@juliacomputing.com>, linux-kernel@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andi Kleen <andi@firstfloor.org>, Kyle Huey <khuey@kylehuey.com>,
Robert O'Callahan <robert@ocallahan.org>
Subject: Re: [RFC PATCH v2] x86/arch_prctl: Add ARCH_SET_XCR0 to set XCR0 per-thread
Date: Tue, 7 Apr 2020 06:14:33 -0700 [thread overview]
Message-ID: <8f95e8b4-415f-1652-bb02-0a7c631c72ac@intel.com> (raw)
In-Reply-To: <20200407011259.GA72735@juliacomputing.com>
I didn't review the first attempt at this, but this looks like a really
bad idea to me. I don't 100% buy the arguments that this shouldn't be
done in a VM. The x86 virtualization architecture was literally
designed to hide hardware details like this.
I can't imagine ever merging this until using VMs or at least the KVM
API has been completely ruled out.
I don't doubt that this approach works in a controlled environment.
But, I can't imagine that we could ever wrap sane semantics around such
a beast.
For instance, what would ARCH_SET_XCR0 do in a signal handler? The
components are mostly in their init states so xstate_is_initial() will
pass. But the kernel's XRSTOR might #GP because it might try to restore
states that are not enabled in XCR0 now.
Also, this has to be done before XCR0's state is observed by userspace,
which the kernel can't easily do once the program is off and running.
This tells me that it really needs to be done at execve() time, even
before the first program instruction runs.
These are usually the kinds of things that you figure out when you try
to go write a manpage for one of these suckers.
How does this work with things like xstateregs_[gs]et() where the format
of the kernel buffer and thus the kernel XCR0 is exposed as part of our
ABI? With this patch, wouldn't a debugger app see a state buffer that
looks invalid?
Where else in our ABI is the format of the XSAVE buffer exposed?
I'm extra wary of a v2 that's missing the CodingStyle and changelog
basics as well.
> +static int xcr0_is_legal(unsigned long xcr0)
> +{
> + /* Conservatively disallow anything above bit 9,
> + * to avoid accidentally allowing the disabling of
> + * new features without updating these checks
> + */
> + if (xcr0 & ~((1 << 10) - 1))
> + return 0;
Yay, magic numbers!
This would be much better as a BUILD_BUG_ON().
> + if (!(xcr0 & XFEATURE_MASK_FP))
> + return 0;
> + if ((xcr0 & XFEATURE_MASK_YMM) && !(xcr0 & XFEATURE_MASK_SSE))
> + return 0;
> + if ((!(xcr0 & XFEATURE_MASK_BNDREGS)) !=
> + (!(xcr0 & XFEATURE_MASK_BNDCSR)))
> + return 0;
> + if (xcr0 & XFEATURE_MASK_AVX512) {
> + if (!(xcr0 & XFEATURE_MASK_YMM))
> + return 0;
> + if ((xcr0 & XFEATURE_MASK_AVX512) != XFEATURE_MASK_AVX512)
> + return 0;
> + }
> + return 1;
> +}
This appears to copy (instead of refactoring) code from __kvm_set_xcr(),
yet manages to get the indentation different and wrong.
next prev parent reply other threads:[~2020-04-07 13:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 1:12 Keno Fischer
2020-04-07 3:57 ` Andy Lutomirski
2020-04-07 4:44 ` Keno Fischer
2020-04-07 4:53 ` Kyle Huey
2020-04-07 12:33 ` Peter Zijlstra
2020-04-07 13:52 ` Keno Fischer
2020-04-07 12:21 ` Peter Zijlstra
2020-04-07 14:06 ` Dave Hansen
2020-04-07 14:16 ` Andy Lutomirski
2020-04-07 18:30 ` Keno Fischer
2020-04-14 23:20 ` Andy Lutomirski
2020-04-15 0:09 ` Keno Fischer
2020-04-16 1:07 ` Andy Lutomirski
2020-04-16 1:14 ` Keno Fischer
2020-04-16 1:16 ` Keno Fischer
2020-04-16 1:22 ` Andy Lutomirski
2020-04-07 16:29 ` Kyle Huey
2020-04-07 13:14 ` Dave Hansen [this message]
[not found] ` <CABV8kRw1TQsqs+z43bSfZ5isctuFGMB4g_ztDYihiiXHcy4nVA@mail.gmail.com>
2020-04-07 16:27 ` Dave Hansen
2020-04-07 17:55 ` Keno Fischer
2020-04-07 20:21 ` Dave Hansen
2020-04-07 21:42 ` Andy Lutomirski
2020-04-07 22:15 ` Keno Fischer
2020-04-14 19:55 ` Keno Fischer
2020-04-07 14:20 ` Andi Kleen
2020-04-07 18:06 ` Keno Fischer
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=8f95e8b4-415f-1652-bb02-0a7c631c72ac@intel.com \
--to=dave.hansen@intel.com \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=keno@juliacomputing.com \
--cc=khuey@kylehuey.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=robert@ocallahan.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 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®