From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 7/7] x86/mm: Prevent 32bit PV guests using out-of-range linear addresses
Date: Tue, 12 Sep 2017 17:04:56 +0100 [thread overview]
Message-ID: <31181793-caa2-2002-bf0f-7cb2fb5823b0@citrix.com> (raw)
In-Reply-To: <59B81E67020000780017A511@prv-mh.provo.novell.com>
On 12/09/17 16:50, Jan Beulich wrote:
>>>> On 12.09.17 at 14:14, <andrew.cooper3@citrix.com> wrote:
>> The grant ABI uses 64 bit values, and allows a PV guest to specify linear
>> addresses. There is nothing interesting a 32bit PV guest can reference which
>> will pass an __addr_ok() check, but it should still get an error for trying.
> While I'm all for tightening checks, I'm not sure we reasonably can:
> Existing guests may (perhaps inadvertently) rely on this behavior,
> and hence may break with the change. I think a prereq to this is to
> have a command line option (or even a per-guest one) to control
> strict vs relaxed argument checking behavior, and tie the extra
> checks to that option being true.
At the moment, any attempt to use this behaviour will still cause a
general error, because we cant locate an L1e mapping the out-of-range
linear address. Therefore, the guest wouldn't have had the grant
operation succeed before.
The problem is that its a latent security bug if we ever chose to reuse
these ranges for other purposes.
E.g. One idea I've had for a while is to move the XLAT translation logic
into guest mode, accessed via a modification to the hypercall page.
This would mitigate security issues such as infinite loops or boundary
overflows, both of which we've had in the XLAT logic in the past.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-09-12 16:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 12:14 [PATCH 0/7] x86/mm: Post XSA-234 cleanup Andrew Cooper
2017-09-12 12:14 ` [PATCH 1/7] x86/mm: Improvements to PV l1e mapping helpers Andrew Cooper
2017-09-12 12:29 ` Wei Liu
2017-09-12 15:22 ` Jan Beulich
2017-09-12 12:14 ` [PATCH 2/7] x86/mm: Factor out the grant flags to pte flags conversion logic Andrew Cooper
2017-09-12 13:28 ` Wei Liu
2017-09-12 15:25 ` Jan Beulich
2017-09-12 12:14 ` [PATCH 3/7] x86/mm: Misc cleanup to {create, replace}_grant_host_mapping() Andrew Cooper
2017-09-12 13:40 ` Wei Liu
2017-09-12 15:25 ` Jan Beulich
2017-09-12 12:14 ` [PATCH 4/7] x86/mm: Combine create_grant_{pte, va}_mapping() Andrew Cooper
2017-09-12 14:04 ` Wei Liu
2017-09-12 15:31 ` Jan Beulich
2017-09-12 12:14 ` [PATCH 5/7] x86/mm: Carve steal_linear_address() out of replace_grant_host_mapping() Andrew Cooper
2017-09-12 14:19 ` Wei Liu
2017-09-12 15:41 ` Jan Beulich
2017-09-12 12:14 ` [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping() Andrew Cooper
2017-09-12 14:58 ` Wei Liu
2017-09-12 16:30 ` Andrew Cooper
2017-09-12 16:32 ` Wei Liu
2017-09-12 16:36 ` Andrew Cooper
2017-09-12 16:37 ` Wei Liu
2017-09-12 15:46 ` Jan Beulich
2017-09-12 12:14 ` [PATCH 7/7] x86/mm: Prevent 32bit PV guests using out-of-range linear addresses Andrew Cooper
2017-09-12 15:50 ` Jan Beulich
2017-09-12 16:04 ` Andrew Cooper [this message]
2017-09-13 8:28 ` Jan Beulich
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=31181793-caa2-2002-bf0f-7cb2fb5823b0@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--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 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.