From patchwork Tue Sep 6 16:51:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konrad Rzeszutek Wilk X-Patchwork-Id: 9317595 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E5FBA601C0 for ; Tue, 6 Sep 2016 16:53:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E001A28DEF for ; Tue, 6 Sep 2016 16:53:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D464F28DF3; Tue, 6 Sep 2016 16:53:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B941528DEF for ; Tue, 6 Sep 2016 16:53:52 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhJaw-00040j-1f; Tue, 06 Sep 2016 16:51:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhJav-00040b-5y for xen-devel@lists.xenproject.org; Tue, 06 Sep 2016 16:51:33 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id 56/51-09160-414FEC75; Tue, 06 Sep 2016 16:51:32 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRWlGSWpSXmKPExsUyZ7p8oK7wl3P hBp0rLCy+b5nM5MDocfjDFZYAxijWzLyk/IoE1owVX1exFTSLVjTsXcrewPiMv4uRk0NIYBKT xJvvdl2MXED2Z0aJxSuXs0MkNjBK3LoYCZHoZpRofv6bBSJRJDFx8kdGEJtFQEVixqlnQA0cH GwCJhJvVjmChEUEdCWeLXjGBmIzC6RJbPs5FcwWFgiXWPrhJ9gYXgEziUWrdjNBzH/JKPGkbS ErREJQ4uTMJywQzVoSN/69ZAKZzywgLbH8HwdImFPATuLhtm9gd4oKKEss7u8Bmy8hYCzR/vY i2wRGoVlIJs1CMmkWwqQFjMyrGDWKU4vKUot0DU30kooy0zNKchMzc3QNDYz1clOLixPTU3MS k4r1kvNzNzECg5kBCHYwrtjueYhRkoNJSZRXLfBcuBBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3 t+fgHKCRanpqRVpmTnAuIJJS3DwKInwHgZJ8xYXJOYWZ6ZDpE4xKkqJ824HSQiAJDJK8+DaYL F8iVFWSpiXEegQIZ6C1KLczBJU+VeM4hyMSsK8F0Cm8GTmlcBNfwW0mAlo8brdp0EWlyQipKQ aGI1lUvVm6KVN9W98XrSurfOCl+oXJSWxJYxng/+5/fYyfq16Zi2f8z+xx9UvmvMrbrZZvZy8 RmRFmsCpnq02IscamU0vRkh9PJfEcvv95I+LvCJ3HUvprso9F3zHacp6rWlnc5rZNuamtv0WU mJO7xHbU3v72PJtDIdffPDv98yavX3CmtlXXymxFGckGmoxFxUnAgAkPJ4Q4AIAAA== X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1473180690!42489403!1 X-Originating-IP: [156.151.31.81] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25719 invoked from network); 6 Sep 2016 16:51:31 -0000 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 6 Sep 2016 16:51:31 -0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u86GpPSJ020871 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Sep 2016 16:51:26 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u86GpPat010931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 16:51:25 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u86GpJfN010743; Tue, 6 Sep 2016 16:51:24 GMT Received: from char.us.oracle.com (/10.137.176.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2016 09:51:19 -0700 Received: by char.us.oracle.com (Postfix, from userid 1000) id 7C5946A0DC6; Tue, 6 Sep 2016 12:51:18 -0400 (EDT) Date: Tue, 6 Sep 2016 12:51:18 -0400 From: Konrad Rzeszutek Wilk To: Andrew Cooper Message-ID: <20160906165118.GB2161@char.us.oracle.com> References: <1472005332-32207-1-git-send-email-konrad.wilk@oracle.com> <1472005332-32207-2-git-send-email-konrad.wilk@oracle.com> <57BD7D19020000780010881B@prv-mh.provo.novell.com> <99e2c349-e808-3fb1-eabd-7199bd99f592@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <99e2c349-e808-3fb1-eabd-7199bd99f592@citrix.com> User-Agent: Mutt/1.6.2 (2016-07-01) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Cc: ross.lagerwall@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org Subject: Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Aug 25, 2016 at 05:08:16PM +0100, Andrew Cooper wrote: > On 24/08/16 09:55, Jan Beulich wrote: > > > > > On 24.08.16 at 04:22, wrote: > > > --- a/xen/common/livepatch.c > > > +++ b/xen/common/livepatch.c > > > @@ -70,6 +70,9 @@ struct payload { > > > unsigned int nsyms; /* Nr of entries in .strtab and symbols. */ > > > struct livepatch_build_id id; /* ELFNOTE_DESC(.note.gnu.build-id) of the payload. */ > > > struct livepatch_build_id dep; /* ELFNOTE_DESC(.livepatch.depends). */ > > > + void **bss; /* .bss's of the payload. */ > > > + size_t *bss_size; /* and their sizes. */ > > Is size_t wide enough in the extreme case? Perhaps yes, because I > > don't think we'll ever load 64-bit ELF on a 32-bit platform. > > Even if we did, there is no chance that more than a single size_t's worth of > data needs clearing, or the payload wouldn't fit in the current virtual > address space. Perhaps go even in further an add an arbitrary limit? Like so (compile tested only): From 22d0a6e0c6fc61a9e257ec4db78c2e58978b2976 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Tue, 6 Sep 2016 12:45:50 -0400 Subject: [PATCH] livepatch: Add limit of 2MB to payload .bss sections. The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793 "xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the size of the binary at 2MB. We follow that in capping the size of the .BSSes to be at maximum 2MB. Signed-off-by: Konrad Rzeszutek Wilk --- xen/common/livepatch_elf.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c index 789e8fc..4a4111d 100644 --- a/xen/common/livepatch_elf.c +++ b/xen/common/livepatch_elf.c @@ -86,7 +86,16 @@ static int elf_resolve_sections(struct livepatch_elf *elf, const void *data) delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past end"); return -EINVAL; } - + else if ( !(sec[i].sec->sh_flags & SHF_EXECINSTR) && + (sec[i].sec->sh_flags & SHF_WRITE) && + sec[i].sec->sh_type == SHT_NOBITS && + sec[i].sec->sh_size > MB(2) ) + { + /* Arbitrary limit. */ + dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] .bss is bigger than 2MB!\n", + elf->name, i); + return -EINVAL; + } sec[i].data = data + delta; /* Name is populated in elf_resolve_section_names. */ sec[i].name = NULL;