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.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, 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 CC1D7C433E0 for ; Fri, 12 Feb 2021 12:49:01 +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 7B31E64DA5 for ; Fri, 12 Feb 2021 12:49:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B31E64DA5 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com 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.84245.157916 (Exim 4.92) (envelope-from ) id 1lAXsK-0000Qv-Ko; Fri, 12 Feb 2021 12:48:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 84245.157916; Fri, 12 Feb 2021 12:48:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lAXsK-0000Qo-HR; Fri, 12 Feb 2021 12:48:44 +0000 Received: by outflank-mailman (input) for mailman id 84245; Fri, 12 Feb 2021 12:48:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lAXsJ-0000Qj-Ku for xen-devel@lists.xenproject.org; Fri, 12 Feb 2021 12:48:43 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c4b1a9e7-cae1-4596-9ed0-c61f9706fa1a; Fri, 12 Feb 2021 12:48:42 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DCE95AF0D; Fri, 12 Feb 2021 12:48:41 +0000 (UTC) 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" X-Inumbo-ID: c4b1a9e7-cae1-4596-9ed0-c61f9706fa1a X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1613134122; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U3Lgksc6gzrlfPMTHi9oCOygUg4UNBq2FGROCXZz5qY=; b=KsTRWWOq84A82HHdEZQ8fyEL3gLYX45KEYS3d8HdVcUDl0tgJf7ScWWeJnN2pGvKONu9bk ib51iRIg845KyGSJPX1eK5ep6quFtj7thyoxSIx9huXGSJ8n1d2E4HUFJOnPlmxJ6OKdMl 2hutWc6UXzKQwZc/ftSzk5VIkWozvWg= Subject: Re: [PATCH 04/17] x86/PV: harden guest memory accesses against speculative abuse To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Tim Deegan , George Dunlap References: <4f1975a9-bdd9-f556-9db5-eb6c428f258f@suse.com> <5da0c123-3b90-97e8-e1e5-10286be38ce7@suse.com> From: Jan Beulich Message-ID: Date: Fri, 12 Feb 2021 13:48:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 12.02.2021 11:41, Roger Pau Monné wrote: > On Thu, Jan 14, 2021 at 04:04:57PM +0100, Jan Beulich wrote: >> @@ -94,6 +106,8 @@ unsigned __copy_from_user_ll(void *to, c >> return n; >> } >> >> +#if GUARD(1) + 0 > > Why do you need the '+ 0' here? I guess it's to prevent the > preprocessor from complaining when GUARD(1) gets replaced by nothing? Yes. "#if" with nothing after it is an error from all I know. >> --- a/xen/include/asm-x86/asm-defns.h >> +++ b/xen/include/asm-x86/asm-defns.h >> @@ -44,3 +44,16 @@ >> .macro INDIRECT_JMP arg:req >> INDIRECT_BRANCH jmp \arg >> .endm >> + >> +.macro guest_access_mask_ptr ptr:req, scratch1:req, scratch2:req >> +#if defined(CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS) >> + mov $(HYPERVISOR_VIRT_END - 1), \scratch1 >> + mov $~0, \scratch2 >> + cmp \ptr, \scratch1 >> + rcr $1, \scratch2 >> + and \scratch2, \ptr > > If my understanding is correct, that's equivalent to: > > ptr &= ~0ull >> (ptr < HYPERVISOR_VIRT_END); > > It might be helpful to add this as a comment, to clarify the indented > functionality of the assembly bit. > > I wonder if the C code above can generate any jumps? As you pointed > out, we already use something similar in array_index_mask_nospec and > that's fine to do in C. Note how array_index_mask_nospec() gets away without any use of relational operators. They're what poses the risk of getting translated to branches. (Quite likely the compiler wouldn't use any in the case here, as the code can easily get away without, but we don't want to chance it. Afaict it would instead use a 3rd scratch register, so register pressure might still lead to using a branch instead in some exceptional case.) Jan