From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
mpohlack@amazon.de, xen-devel@lists.xenproject.org,
dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.
Date: Wed, 6 Jan 2016 12:41:38 -0500 [thread overview]
Message-ID: <20160106174138.GB8633@char.us.oracle.com> (raw)
In-Reply-To: <5641F13F02000078000B35D3@prv-mh.provo.novell.com>
On Tue, Nov 10, 2015 at 05:29:35AM -0700, Jan Beulich wrote:
> >>> On 06.11.15 at 20:36, <konrad.wilk@oracle.com> wrote:
> > All of XENVER_* have now an XSM check.
> >
> > The subops for XENVER_[compile_info|changeset|commandline|
> > extraversion] are now priviliged operations. To not break
> > guests we still return an string - but it is just '<denied>'.
>
> And I continue to question at least the extraversion part.
How about I remove the extraversion part from this patch and we can
discuss putting 'extraversion' in the blacklist around another patch.
>
> > The rest: XENVER_[version|capabilities|
> > parameters|get_features|page_size|guest_handle] behave
> > as before - allowed by default for all guests.
> >
> > This is with the XSM default policy and with the dummy ones.
>
> And with a non-default policy you now ignore one of the latter
> ops to also get denied.
No, but that is due to the 'deny' being only checked for certain subops.
I think what you are saying is that for XENVER_[version|capabilities|
parameters|get_features|page_size|guest_handle] we should not have any
XSM checks as they serve no purpose (which is what I had in the earlier
versions of this patch). However Andrew mentioned that he would
like _ALL_ of the sub-ops to be checked for.
It feels like I am back to square one :-)
My feeling is that those subops I mentioned should have no XSM checks
at all so nobody can mess that up (thought it was fun messing that up).
However Andrew did not like that, but you seem to imply you like that.
Could you two hash out which way you would like this?
>
> > @@ -354,10 +356,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> > return 0;
> >
> > case XENVER_commandline:
> > - if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> > + {
> > + size_t len = ARRAY_SIZE(saved_cmdline);
> > +
> > + if ( deny )
> > + len = strlen(xen_deny());
>
> +1 (or else you fail to nul-terminate the output).
Nice spotting!
Perhaps modifying xen_deny() to be:
const char *xen_deny(void)
{
return "<denied>\0";
}
Would be better?
As this 'len' +1 would lead me to copy one byte extra from the .rodata
section where "<denied>" resides leaking to some information leak.
> Jan
>
next prev parent reply other threads:[~2016-01-06 17:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-06 19:36 [PATCH v2] Add build-id to XENVER hypercall Konrad Rzeszutek Wilk
2015-11-06 19:36 ` [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall Konrad Rzeszutek Wilk
2015-11-10 12:29 ` Jan Beulich
2016-01-06 17:41 ` Konrad Rzeszutek Wilk [this message]
2016-01-07 7:35 ` Jan Beulich
2016-01-08 17:31 ` Konrad Rzeszutek Wilk
2016-01-11 9:02 ` Jan Beulich
2016-01-11 16:01 ` Konrad Rzeszutek Wilk
2016-01-11 16:17 ` Jan Beulich
2016-01-12 16:37 ` Konrad Rzeszutek Wilk
2016-01-12 16:42 ` Jan Beulich
2015-11-10 19:51 ` Daniel De Graaf
2015-11-16 19:02 ` Konrad Rzeszutek Wilk
2016-01-06 17:49 ` Konrad Rzeszutek Wilk
2015-11-06 19:36 ` [PATCH v2 2/3] XENVER_build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
2015-11-09 17:26 ` Ross Lagerwall
2015-11-10 16:49 ` Jan Beulich
2016-01-06 17:27 ` Konrad Rzeszutek Wilk
2016-01-07 7:42 ` Jan Beulich
2015-11-06 19:36 ` [PATCH v2 3/3] libxl: info: Display build_id of the hypervisor Konrad Rzeszutek Wilk
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=20160106174138.GB8633@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=mpohlack@amazon.de \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).