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.5 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 1DF44C433DB for ; Tue, 9 Feb 2021 15:15:02 +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 C307664EB8 for ; Tue, 9 Feb 2021 15:15:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C307664EB8 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.83280.154551 (Exim 4.92) (envelope-from ) id 1l9Uiy-0005rc-4j; Tue, 09 Feb 2021 15:14:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 83280.154551; Tue, 09 Feb 2021 15:14: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 1l9Uiy-0005rV-0q; Tue, 09 Feb 2021 15:14:44 +0000 Received: by outflank-mailman (input) for mailman id 83280; Tue, 09 Feb 2021 15:14:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l9Uiw-0005rQ-Im for xen-devel@lists.xenproject.org; Tue, 09 Feb 2021 15:14:42 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 398a33ec-0192-4276-a988-e8691c4c73cd; Tue, 09 Feb 2021 15:14:41 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CE300B21A; Tue, 9 Feb 2021 15:14:40 +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: 398a33ec-0192-4276-a988-e8691c4c73cd 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=1612883680; 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=U6qYsU4In/PbhGu50pUxSSjZI/9AictEFwYLXUfuVZg=; b=djzeuIbxCdOI0K1rlXfuzOffmqPJR4Svmm0VvWKzHGR8z1WNB74/dLnMNB7hv5+toL7fbJ SEMV6dJYztymzF6xxGodJ5e8F6tP+pYNco36eI+4NRoahLF0u5eh7t4awDQdLGuB+Nfo+V OceDJXyzxbgWivcbm65WhlD6/OwlUcc= Subject: Re: [PATCH 02/17] x86: split __{get,put}_user() into "guest" and "unsafe" variants 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> <13d1d621-21db-0e59-6603-2b22b6a9d180@suse.com> From: Jan Beulich Message-ID: <11d58555-97d2-0489-b123-cbcf084a0094@suse.com> Date: Tue, 9 Feb 2021 16:14:41 +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 09.02.2021 15:55, Roger Pau Monné wrote: > On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote: >> The "guest" variants are intended to work with (potentially) fully guest >> controlled addresses, while the "unsafe" variants are not. (For >> descriptor table accesses the low bits of the addresses may still be >> guest controlled, but this still won't allow speculation to "escape" >> into unwanted areas.) > > Descriptor table is also in guest address space, and hence would be > fine using the _guest accessors? (even if not in guest control and > thus unsuitable as an speculation vector) No, we don't access descriptor tables in guest space, I don't think. See read_gate_descriptor() for an example. After all PV guests don't even have the full concept of self-managed (in their VA space) descriptor tables (GDT gets specified in terms of frames, while LDT gets specified in terms of (VA,size) tuples, but just for Xen to read the underlying page table entries upon 1st access). >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -274,7 +274,7 @@ static void compat_show_guest_stack(stru >> { >> if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask ) >> break; >> - if ( __get_user(addr, stack) ) >> + if ( get_unsafe(addr, stack) ) >> { >> if ( i != 0 ) >> printk("\n "); >> @@ -343,7 +343,7 @@ static void show_guest_stack(struct vcpu >> { >> if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask ) >> break; >> - if ( __get_user(addr, stack) ) >> + if ( get_unsafe(addr, stack) ) > > Shouldn't accessing the guest stack use the _guest accessors? Hmm, yes indeed. > Or has this address been verified by Xen and not in idrect control of > the guest, and thus can't be used for speculation purposes? > > I feel like this should be using the _guest accessors anyway, as the > guest stack is an address in guest space? I think this being a debugging function only, not directly accessible by guests, is what made me think speculation is not an issue here and hence the "unsafe" variants are fine to use (they're slightly cheaper after all, once the subsequent changes are in place). But I guess I will better switch these two around. Jan