From: Sean Christopherson <seanjc@google.com>
To: Len Brown <lenb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>,
David Laight <David.Laight@aculab.com>,
Dave Hansen <dave.hansen@intel.com>,
Greg KH <gregkh@linuxfoundation.org>,
"Bae, Chang Seok" <chang.seok.bae@intel.com>,
X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
libc-alpha <libc-alpha@sourceware.org>,
Florian Weimer <fweimer@redhat.com>,
Rich Felker <dalias@libc.org>, Kyle Huey <me@kylehuey.com>,
Keno Fischer <keno@juliacomputing.com>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
Date: Mon, 12 Apr 2021 17:14:17 +0000 [thread overview]
Message-ID: <YHR/6fnpe/sAASPs@google.com> (raw)
In-Reply-To: <CAJvTdK=RFei+b0W89ZTtqoiiR_M0wAJz_EuBTijgEHpacfZS7Q@mail.gmail.com>
On Sun, Apr 11, 2021, Len Brown wrote:
> On Fri, Apr 9, 2021 at 5:44 PM Andy Lutomirski <luto@kernel.org> wrote:
> >
> > On Fri, Apr 9, 2021 at 1:53 PM Len Brown <lenb@kernel.org> wrote:
> > >
> > > On Wed, Mar 31, 2021 at 6:45 PM Andy Lutomirski <luto@kernel.org> wrote:
> > > >
> > > > On Wed, Mar 31, 2021 at 3:28 PM Len Brown <lenb@kernel.org> wrote:
> > > > > We've also established that when running in a VMM, every update to
> > > > > XCR0 causes a VMEXIT.
> > > >
> > > > This is true, it sucks, and Intel could fix it going forward.
> > >
> > > What hardware fix do you suggest?
> > > If a guest is permitted to set XCR0 bits without notifying the VMM,
> > > what happens when it sets bits that the VMM doesn't know about?
> >
> > The VM could have a mask of allowed XCR0 bits that don't exist.
> >
> > TDX solved this problem *somehow* -- XSETBV doesn't (visibly?) exit on
> > TDX. Surely plain VMX could fix it too.
>
> There are two cases.
>
> 1. Hardware that exists today and in the foreseeable future.
>
> VM modification of XCR0 results in VMEXIT to VMM.
> The VMM sees bits set by the guest, and so it can accept what
> it supports, or send the VM a fault for non-support.
>
> Here it is not possible for the VMM to change XCR0 without the VMM knowing.
>
> 2. Future Hardware that allows guests to write XCR0 w/o VMEXIT.
>
> Not sure I follow your proposal.
>
> Yes, the VM effectively has a mask of what is supported,
> because it can issue CPUID.
>
> The VMM virtualizes CPUID, and needs to know it must not
> expose to the VM any state features it doesn't support.
> Also, the VMM needs to audit XCR0 before it uses XSAVE,
> else the guest could attack or crash the VMM through
> buffer overrun.
The VMM already needs to context switch XCR0 and XSS, so this is a non-issue.
> Is this what you suggest?
Yar. In TDX, XSETBV exits, but only to the TDX module. I.e. TDX solves the
problem in software by letting the VMM tell the TDX module what features the
guest can set in XCR0/XSS via the XFAM (Extended Features Allowed Mask).
But, that software "fix" can also be pushed into ucode, e.g. add an XFAM VMCS
field, the guest can set any XCR0 bits that are '1' in VMCS.XFAM without exiting.
Note, SGX has similar functionality in the form of XFRM (XSAVE-Feature Request
Mask). The enclave author can specify what features will be enabled in XCR0
when the enclave is running. Not that relevant, other than to reinforce that
this is a solvable problem.
> If yes, what do you suggest in the years between now and when
> that future hardware and VMM exist?
Burn some patch space? :-)
next prev parent reply other threads:[~2021-04-12 17:14 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-26 23:12 Candidate Linux ABI for Intel AMX and hypothetical new related features Andy Lutomirski
2021-03-26 23:18 ` Andy Lutomirski
2021-03-27 3:39 ` Len Brown
2021-03-27 9:14 ` Borislav Petkov
2021-03-27 9:58 ` Greg KH
2021-03-29 15:47 ` Len Brown
2021-03-29 16:38 ` Len Brown
2021-03-29 16:48 ` Florian Weimer
2021-03-29 18:14 ` Andy Lutomirski
2021-03-29 18:16 ` Andy Lutomirski
2021-03-29 22:38 ` Len Brown
2021-03-30 5:08 ` Andy Lutomirski
2021-03-30 5:50 ` Noah Goldstein
2021-03-30 17:01 ` Len Brown
2021-03-30 17:05 ` Andy Lutomirski
2021-03-30 17:56 ` Len Brown
2021-03-30 19:12 ` Dave Hansen
2021-03-30 20:20 ` Andy Lutomirski
2021-03-30 20:42 ` Len Brown
2021-03-30 22:01 ` David Laight
2021-03-31 16:31 ` Len Brown
2021-03-31 16:53 ` Andy Lutomirski
2021-03-31 21:42 ` Robert O'Callahan
2021-03-31 22:11 ` Len Brown
2021-03-31 22:28 ` Len Brown
2021-03-31 22:45 ` Andy Lutomirski
2021-04-09 20:52 ` Len Brown
2021-04-09 21:44 ` Andy Lutomirski
2021-04-11 19:07 ` Len Brown
2021-04-12 7:59 ` David Laight
2021-04-12 12:19 ` Borislav Petkov
2021-04-12 17:14 ` Sean Christopherson [this message]
2021-03-31 22:52 ` Borislav Petkov
2021-04-09 20:55 ` Len Brown
2021-03-28 0:53 ` Thomas Gleixner
2021-03-29 7:27 ` Peter Zijlstra
2021-03-29 15:06 ` Dave Hansen
2021-03-31 8:24 ` Borislav Petkov
[not found] ` <87lf9nk2ku.fsf@oldenburg.str.redhat.com>
2021-04-12 14:31 ` Borislav Petkov
2021-04-12 14:38 ` Florian Weimer
2021-04-12 15:08 ` Borislav Petkov
2021-04-12 15:10 ` Andy Lutomirski
2021-04-12 15:21 ` Andy Lutomirski
2021-04-12 23:46 ` Len Brown
2021-04-13 0:17 ` Thomas Gleixner
2021-04-13 1:25 ` Len Brown
2021-04-13 3:43 ` Willy Tarreau
2021-04-13 19:51 ` Len Brown
2021-04-14 9:58 ` Borislav Petkov
2021-04-14 10:06 ` Willy Tarreau
2021-04-14 10:08 ` Borislav Petkov
2021-04-14 21:57 ` Len Brown
2021-04-15 4:43 ` Borislav Petkov
2021-04-15 5:29 ` Willy Tarreau
2021-04-15 5:47 ` Borislav Petkov
2021-04-16 22:05 ` Len Brown
2021-04-19 14:14 ` Borislav Petkov
2021-04-19 18:18 ` Len Brown
2021-04-19 19:15 ` Borislav Petkov
2021-04-19 21:33 ` Len Brown
2021-04-19 21:58 ` Borislav Petkov
2021-04-23 19:35 ` Len Brown
2021-04-23 19:57 ` Borislav Petkov
2021-05-02 15:27 ` Len Brown
2021-05-03 5:18 ` Florian Weimer
2021-05-03 13:43 ` Dave Hansen
2021-05-03 13:47 ` Florian Weimer
2021-05-03 14:14 ` Dave Hansen
2021-05-07 18:44 ` Thomas Gleixner
2021-05-07 18:50 ` Andy Lutomirski
2021-05-07 19:22 ` Thomas Gleixner
2021-05-08 9:45 ` Thomas Gleixner
2021-05-18 20:39 ` Len Brown
2021-05-19 23:29 ` Andy Lutomirski
2021-05-20 19:16 ` Len Brown
2021-05-17 9:45 ` Thomas Gleixner
2021-05-17 9:56 ` Florian Weimer
2021-05-17 10:18 ` Thomas Gleixner
2021-05-21 16:29 ` Len Brown
2021-05-17 13:49 ` Arjan van de Ven
2021-05-20 15:35 ` Len Brown
2021-05-20 20:54 ` Thomas Gleixner
2021-05-20 21:13 ` Dave Hansen
2021-05-20 21:41 ` Len Brown
2021-05-20 22:53 ` Dave Hansen
2021-05-21 9:41 ` Thomas Gleixner
2021-05-21 14:44 ` Florian Weimer
2021-05-21 14:49 ` Peter Zijlstra
2021-06-23 15:06 ` Florian Weimer
2021-06-23 23:11 ` Len Brown
2021-06-28 10:14 ` Enrico Weigelt, metux IT consult
2021-06-28 12:49 ` Florian Weimer
2021-06-30 12:22 ` Enrico Weigelt, metux IT consult
2021-06-30 12:41 ` Willy Tarreau
2021-06-30 13:55 ` Arjan van de Ven
2021-06-30 15:20 ` Len Brown
2021-06-30 15:25 ` Enrico Weigelt, metux IT consult
2021-05-21 16:14 ` Dave Hansen
2021-05-21 16:19 ` Florian Weimer
2021-05-21 16:26 ` Len Brown
2021-05-21 16:28 ` Dave Hansen
2021-05-21 16:31 ` Andy Lutomirski
2021-05-21 19:10 ` Thomas Gleixner
2021-05-21 20:07 ` Andy Lutomirski
2021-05-21 21:43 ` Thomas Gleixner
2021-05-21 22:07 ` Len Brown
2021-05-21 22:46 ` Thomas Gleixner
2021-05-21 23:31 ` Len Brown
2021-05-22 7:16 ` Florian Weimer
2021-05-22 23:55 ` Andy Lutomirski
2021-05-21 23:06 ` Dave Hansen
2021-05-21 23:08 ` Len Brown
2021-05-21 19:05 ` Thomas Gleixner
2021-05-20 21:22 ` Len Brown
2021-05-20 21:41 ` Thomas Gleixner
2021-05-20 21:49 ` Len Brown
2021-05-21 9:26 ` Thomas Gleixner
2021-04-19 23:52 ` Paul Eggert
2021-04-13 20:16 ` Andy Lutomirski
2021-04-13 22:47 ` Len Brown
2021-04-13 22:58 ` Andy Lutomirski
2021-04-14 21:48 ` Len Brown
2021-04-15 16:24 ` Andy Lutomirski
2021-04-15 17:00 ` Dave Hansen
2021-04-15 17:38 ` Andy Lutomirski
2021-04-16 21:54 ` Len Brown
2021-04-16 22:03 ` Andy Lutomirski
2021-04-16 22:10 ` Len Brown
2021-04-16 22:14 ` Andy Lutomirski
2021-04-17 1:57 ` Len Brown
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=YHR/6fnpe/sAASPs@google.com \
--to=seanjc@google.com \
--cc=David.Laight@aculab.com \
--cc=chang.seok.bae@intel.com \
--cc=dalias@libc.org \
--cc=dave.hansen@intel.com \
--cc=fweimer@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=keno@juliacomputing.com \
--cc=lenb@kernel.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=me@kylehuey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).