From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC2E4C433DB for ; Fri, 26 Feb 2021 14:54:00 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 43FA064E20 for ; Fri, 26 Feb 2021 14:54:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43FA064E20 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.90385.171064 (Exim 4.92) (envelope-from ) id 1lFeV3-0005Po-N3; Fri, 26 Feb 2021 14:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 90385.171064; Fri, 26 Feb 2021 14:53:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lFeV3-0005Ph-K3; Fri, 26 Feb 2021 14:53:49 +0000 Received: by outflank-mailman (input) for mailman id 90385; Fri, 26 Feb 2021 14:53:48 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lFeV2-0005Pc-1v for xen-devel@lists.xenproject.org; Fri, 26 Feb 2021 14:53:48 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lFeUz-0005Qq-Rz; Fri, 26 Feb 2021 14:53:45 +0000 Received: from 54-240-197-233.amazon.com ([54.240.197.233] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lFeUz-0006WC-Hk; Fri, 26 Feb 2021 14:53:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=/XxitYmbtMdY5Kmb/chQfd8nUNCdrYxRbctwC8wUOZs=; b=cUAm7PLyUfKUIh/sGUcqrMzJHU hnAHVueoe1zwqiQGvMkIP7+0YFye5ZNqfp+ABGldD9nuDJD+g0mpAXq84DVtr2qxyB6MV4zXhrXtE TGp8U2aC5jvlFF0XmWe1R0Tq7wlZnNJnE8na8BL/FAi66LDezA3dZlDv725rc3LBX+PA=; Subject: Re: [PATCH XENSTORE v1 10/10] xs: add error handling To: Norbert Manthey , xen-devel@lists.xenproject.org Cc: Ian Jackson , Juergen Gross , Wei Liu , Julien Grall , Michael Kurth References: <20210226144144.9252-1-nmanthey@amazon.de> <20210226144144.9252-11-nmanthey@amazon.de> From: Julien Grall Message-ID: <78560c14-81dc-05de-26f8-15861459806d@xen.org> Date: Fri, 26 Feb 2021 14:53:43 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210226144144.9252-11-nmanthey@amazon.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Hi Norbert, On 26/02/2021 14:41, Norbert Manthey wrote: > In case of a failure deep in the call tree, we might return NULL as the > value of the domain. In that case, error out instead of dereferencing > the NULL pointer. > > This bug was discovered and resolved using Coverity Static Analysis > Security Testing (SAST) by Synopsys, Inc. This commit message is not very descriptive. Internally, I suggested: " tools/xenstore: Harden xs_domain_is_introduced() The function single_with_domid() may return NULL if something went wrong (e.g. XenStored returns an error or the connection is in bad state). They are unlikely but not impossible, so it would be better to return an error and allow the caller to handle it gracefully rather than crashing. In this case we should treat it as the domain has disappeared (i.e. return false) as the caller will not likely going to be able to communicate with XenStored again. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. " I would have expected this to be addressed given that... > > Signed-off-by: Norbert Manthey > Reviewed-by: Julien Grall