From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>
Cc: "security@kernel.org" <security@kernel.org>,
X86 ML <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
Sasha Levin <sasha.levin@oracle.com>,
linux-kernel@vger.kernel.org,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
stable@vger.kernel.org, Jan Beulich <jbeulich@suse.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
Date: Wed, 22 Jul 2015 00:38:59 +0100 [thread overview]
Message-ID: <55AED813.5020603@citrix.com> (raw)
In-Reply-To: <55AEBF76.4040501@oracle.com>
On 21/07/2015 22:53, Boris Ostrovsky wrote:
> On 07/21/2015 03:59 PM, Andy Lutomirski wrote:
>> --- a/arch/x86/include/asm/mmu_context.h
>> +++ b/arch/x86/include/asm/mmu_context.h
>> @@ -34,6 +34,44 @@ static inline void load_mm_cr4(struct mm_struct
>> *mm) {}
>> #endif
>> /*
>> + * ldt_structs can be allocated, used, and freed, but they are never
>> + * modified while live.
>> + */
>> +struct ldt_struct {
>> + int size;
>> + int __pad; /* keep the descriptors naturally aligned. */
>> + struct desc_struct entries[];
>> +};
>
>
>
> This breaks Xen which expects LDT to be page-aligned. Not sure why.
>
> Jan, Andrew?
PV guests are not permitted to have writeable mappings to the frames
making up the GDT and LDT, so it cannot make unaudited changes to
loadable descriptors. In particular, for a 32bit PV guest, it is only
the segment limit which protects Xen from the ring1 guest kernel.
A lot of this code hasn't been touched in years, and it certainly
predates me. The alignment requirement appears to come from the virtual
region Xen uses to map the guests GDT and LDT. Strict alignment is
required for the GDT so Xen's descriptors starting at 0xe0xx are
correct, but the LDT alignment seems to be a side effect of similar
codepaths.
For an LDT smaller than 8192 entries, I can't see any specific reason
for enforcing alignment, other than "that's the way it has always been".
However, the guest would still have to relinquish write access to all
frames which make up the LDT, which looks to be a bit of an issue given
the snippet above.
I think I have a solution, but I doubt it is going to be very popular.
* Make a new paravirt hook for allocation of ldt_struct, so the paravirt
backend can choose an alignment if needed
* Make absolutely certain that __pad has the value 0 (so size and __pad
combined don't look like a present descriptor)
* Never hand selector 0x0008 to unsuspecting users.
This will allow ldt_struct itself to be page aligned, and for the size
field to sit across the base/limit field of what would logically be
selector 0x0008 There would be some issues accessing size. To load
frames as an LDT, a guest must drop all refs to the page so that its
type may be changed from writeable to segdesc. After that, an
update_descriptor hypercall can be used to change size, and I believe
the guest may subsequently recreate read-only mappings to the frames in
question (although frankly it is getting late so you will want to double
check all of this).
Anyhow, this looks like an issue which should be fixed up with slightly
more PVOps, rather than enforcing a Xen view of the world on native Linux.
~Andrew
next prev parent reply other threads:[~2015-07-21 23:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1437508485.git.luto@kernel.org>
2015-07-21 19:59 ` [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous Andy Lutomirski
2015-07-21 21:53 ` Boris Ostrovsky
2015-07-21 23:38 ` Andrew Cooper [this message]
2015-07-22 0:07 ` Andy Lutomirski
2015-07-22 0:21 ` Andrew Cooper
2015-07-22 0:28 ` Andy Lutomirski
2015-07-22 0:49 ` Andrew Cooper
2015-07-22 1:06 ` Andy Lutomirski
2015-07-22 2:04 ` [Xen-devel] " Boris Ostrovsky
2015-07-22 2:13 ` Andy Lutomirski
2015-07-22 2:01 ` Brian Gerst
2015-07-22 2:12 ` Andy Lutomirski
2015-07-22 2:53 ` Brian Gerst
2015-07-22 4:22 ` Andy Lutomirski
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=55AED813.5020603@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=jbeulich@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sasha.levin@oracle.com \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xen.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 NNTP newsgroup(s).