From: "Jan Beulich" <JBeulich@suse.com>
To: Martin Pohlack <mpohlack@amazon.com>,
Martin Pohlack <mpohlack@amazon.de>
Cc: elena.ufimtseva@oracle.com, jeremy@goop.org,
hanweidong@huawei.com, john.liuqiming@huawei.com,
paul.voccio@rackspace.com,
Konrad Rzeszutek Wilk <konrad@kernel.org>,
daniel.kiper@oracle.com, major.hayden@rackspace.com,
liuyingdong@huawei.com, aliguori@amazon.com,
xiantao.zxt@alibaba-inc.com, steven.wilson@rackspace.com,
peter.huangpeng@huawei.com, msw@amazon.com,
xen-devel@lists.xenproject.org, rick.harris@rackspace.com,
josh.kearney@rackspace.com, jinsong.liu@alibaba-inc.com,
amesserl@rackspace.com, dslutz@verizon.com,
fanhenglong@huawei.com, Bjoern Doebel <doebel@amazon.de>
Subject: Re: [PATCH] xsplice: Use ld-embedded build-ids
Date: Fri, 14 Aug 2015 07:54:49 -0600 [thread overview]
Message-ID: <55CE0F49020000780009B127@prv-mh.provo.novell.com> (raw)
In-Reply-To: <55CDE61A.3060502@amazon.com>
>>> On 14.08.15 at 14:59, <mpohlack@amazon.com> wrote:
> On 11.08.2015 16:12, Jan Beulich wrote:
>>>>> On 05.08.15 at 16:09, <mpohlack@amazon.de> wrote:
>>> Todo:
>>> * Should be moved to sysctl to only allow Dom0 access
>>
>> Because of?
>
> The discussion in this thread:
>
> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
>
> was:
> ----------------------------------------------------------------------
>>> Martin Pohlack:
>>> We should not expose the build_id to normal guests, but only to Dom0.
>>>
>>> A build_id uniquely identifies a specific build and I don't see how that
>>> information would be required from DomU. It might actually help an
>>> attacker to build his return-oriented programming exploit against a
>>> specific build.
>>>
>>> The normal version numbers should be enough to know about capabilities
>>> and API.
>>
>> Andrew Cooper:
>>
>> It will need its own XSM hook, but need not be strictly limited to just
>> dom0.
> ----------------------------------------------------------------------
So I'm confused - I asked "why Dom0 only" and then you point me to
Andrew saying it doesn't need to be Dom0 only?
>>> @@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
>>> case XENVER_build_id:
>>> {
>>> - xen_build_id_t build_id;
>>> + xen_build_id_t ascii_id;
>>> + Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
>>> + char * binary_id;
>>> + int i;
>>> +
>>> + memset(ascii_id, 0, sizeof(ascii_id));
>>> +
>>> + /* check if we really have a build-id */
>>> + if ( NT_GNU_BUILD_ID != n->type )
>>> + return 0;
>>
>> This needs to signal an error.
>
> Yes, ENOSYS, (or ENOENT, ENODATA)?
Definitely not ENOSYS. ENODATA or EOPNOTSUPP.
Jan
next prev parent reply other threads:[~2015-08-14 13:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 19:20 [RFC PATCH v3.1] xSplice design Konrad Rzeszutek Wilk
2015-07-27 19:20 ` [RFC PATCH v3.1 1/2] xsplice: rfc.v3.1 Konrad Rzeszutek Wilk
2015-07-30 16:47 ` Johannes Erdfelt
2015-07-31 15:46 ` Konrad Rzeszutek Wilk
2015-08-11 14:17 ` Jan Beulich
2015-07-27 19:20 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Konrad Rzeszutek Wilk
2015-07-28 15:51 ` Andrew Cooper
2015-07-28 16:35 ` Konrad Rzeszutek Wilk
2015-08-05 8:50 ` Martin Pohlack
2015-08-05 8:58 ` Andrew Cooper
2015-08-05 13:27 ` Martin Pohlack
2015-08-05 14:06 ` (no subject) Martin Pohlack
2015-08-05 14:09 ` [PATCH] xsplice: Use ld-embedded build-ids Martin Pohlack
2015-08-11 14:12 ` Jan Beulich
2015-08-14 12:59 ` Martin Pohlack
2015-08-14 13:54 ` Jan Beulich [this message]
2015-08-14 13:57 ` Martin Pohlack
2015-09-15 18:38 ` Konrad Rzeszutek Wilk
2015-08-11 14:02 ` [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Jan Beulich
2015-08-05 8:55 ` Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Martin Pohlack
2015-08-05 13:25 ` Hotpatch construction and __LINE__ Andrew Cooper
2015-08-12 8:09 ` Jan Beulich
2015-08-12 9:55 ` Andrew Cooper
2015-11-03 18:21 ` Ross Lagerwall
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=55CE0F49020000780009B127@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=aliguori@amazon.com \
--cc=amesserl@rackspace.com \
--cc=daniel.kiper@oracle.com \
--cc=doebel@amazon.de \
--cc=dslutz@verizon.com \
--cc=elena.ufimtseva@oracle.com \
--cc=fanhenglong@huawei.com \
--cc=hanweidong@huawei.com \
--cc=jeremy@goop.org \
--cc=jinsong.liu@alibaba-inc.com \
--cc=john.liuqiming@huawei.com \
--cc=josh.kearney@rackspace.com \
--cc=konrad@kernel.org \
--cc=liuyingdong@huawei.com \
--cc=major.hayden@rackspace.com \
--cc=mpohlack@amazon.com \
--cc=mpohlack@amazon.de \
--cc=msw@amazon.com \
--cc=paul.voccio@rackspace.com \
--cc=peter.huangpeng@huawei.com \
--cc=rick.harris@rackspace.com \
--cc=steven.wilson@rackspace.com \
--cc=xen-devel@lists.xenproject.org \
--cc=xiantao.zxt@alibaba-inc.com \
/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).