From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [PATCH v7 00/22] XSA55 libelf fixes for unstable Date: Wed, 12 Jun 2013 15:02:17 +0100 Message-ID: <20920.32617.37092.230817@mariner.uk.xensource.com> References: <1370974865-19554-1-git-send-email-ian.jackson@eu.citrix.com> <51B77ABA.20304@citrix.com> <20920.31638.988504.813293@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20920.31638.988504.813293@mariner.uk.xensource.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: Andrew Cooper , "xen-devel@lists.xensource.com" , "mattjd@gmail.com" , "security@xen.org" List-Id: xen-devel@lists.xenproject.org Ian Jackson writes ("Re: [PATCH v7 00/22] XSA55 libelf fixes for unstable"): > I have had a review from Oracle by private email. Prompted by that > review I did a search and now I'm suspicious of a range test in > xc_dom_alloc_segment. The status of this is as follows: I have no review as yet of the post-v7 patch: 23/?? libxc: Better range check in xc_dom_alloc_segment just posted by me in the v7 00/22 subthread. I only have one formal review (Andrew Cooper's) on: 03/22 159 libxc: Fix range checking in xc_dom_pfn_to_ptr etc. 15/22 773 libelf: use only unsigned integers 16/22 413 libelf: check loops for running away 18/22 72 libxc: Add range checking to xc_dom_binloader 19/22 322 libxc: check failure of xc_dom_*_to_ptr, xc_map_foreign_range 20/22 307 libxc: check return values from malloc 21/22 47 libxc: range checks in xc_dom_p2m_host and _guest (numbers are length of the patch file in lines). On these patches I have Andrew Cooper's review on the latest version but other review(s) on earlier versions which I decided not to consider applied to the current version: 11/22 libelf: check all pointer accesses [v2 acked by Ian Campbell] Of these I think the most troublesome areas are: 15: Risk of regressions and other unintended functional changes. 16: Risk of regressions or of failure to catch all problematic loops. 18: Risk of failure to catch all problems in this fiddly code. I'm still waiting for a comment from Tim Deegan or some other hypervisor memory arrangemente expert on patch 21, on what xc_dom_p2m_host and xc_dom_p2m_guest should do with out-of-range pfns in shadow mode. Should they turn them into INVALID_MFN rather than simply returning them ? (And is the definition of "invalid" the same as for non-shadow, ie using rambase_pfn and total_pages.() Thanks, Ian.