From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Pohlack Subject: Re: [PATCH] xsplice: Use ld-embedded build-ids Date: Fri, 14 Aug 2015 15:57:56 +0200 Message-ID: <55CDF3E4.3060405@amazon.com> References: <55C20F57.8@amazon.com> <1438783749-6252-1-git-send-email-mpohlack@amazon.de> <55CA1EE802000078000999CE@prv-mh.provo.novell.com> <55CDE61A.3060502@amazon.com> <55CE0F49020000780009B127@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZQFVM-0005gw-Qk for xen-devel@lists.xenproject.org; Fri, 14 Aug 2015 13:58:45 +0000 In-Reply-To: <55CE0F49020000780009B127@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Martin Pohlack Cc: elena.ufimtseva@oracle.com, jeremy@goop.org, hanweidong@huawei.com, john.liuqiming@huawei.com, paul.voccio@rackspace.com, Konrad Rzeszutek Wilk , 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 List-Id: xen-devel@lists.xenproject.org On 14.08.2015 15:54, Jan Beulich wrote: >>>> On 14.08.15 at 14:59, wrote: >> On 11.08.2015 16:12, Jan Beulich wrote: >>>>>> On 05.08.15 at 16:09, 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? Sorry about that, my (not expressed) thinking was that we should restrict that to Dom0 for the XSM-disabled case. >>>> @@ -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 > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B