From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] xsplice: Use ld-embedded build-ids Date: Fri, 14 Aug 2015 07:54:49 -0600 Message-ID: <55CE0F49020000780009B127@prv-mh.provo.novell.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> 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 1ZQFRf-00057N-SM for xen-devel@lists.xenproject.org; Fri, 14 Aug 2015 13:54:55 +0000 In-Reply-To: <55CDE61A.3060502@amazon.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Martin Pohlack , 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.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? >>> @@ -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