Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1779779imm; Tue, 22 May 2018 09:11:23 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpKtNe/8oGUxcty9YNL3ZAGHvLAYCDTMlrvGn6LndgpHkrNrfXqvCoiuqguTWi84XKmQPA3 X-Received: by 2002:a17:902:5e3:: with SMTP id f90-v6mr25941353plf.175.1527005483183; Tue, 22 May 2018 09:11:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527005483; cv=none; d=google.com; s=arc-20160816; b=KL5NH5reVtchMWs4ZJBYHn2I5eOG+n1recFwHmKNbYFboEXi+Rdu39SlzEVlCfuOUK m8bqNjwPBjeeDGEBm9reR3rx/z8bjvN+HZD5dhYa87eTpCgoKpcn4yf1xauSGZPAWSjJ zUwBDMa/xcUPHwHtLBj1XCo55yAeO1MHM+c+tTlKSl1xTjR8oigBt3qHlzzVYqNbm/Zh fjMWVzVUr4m7IpOI/AWuov4WgY+lqtgfCEtwIT62xIVKjbCH8Q6SaBeRxrNg+BzyKMOc v36lkBtv4H0tTNoof0hfrR2wcQ5bOuERFPfs1vM3q2iLTvHu8RT+K5lwB0Dh4vrcpsw5 Y0qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:in-reply-to:references :subject:cc:to:from:date:message-id:arc-authentication-results; bh=Tu+IwTQnl22m8aCx85N4GMEZC3Ul1kiVeJtVURwFdeE=; b=Wn+IKX7EWAmFFlquxneQrIXskatWTJRKwLuYT0TFEBGvCkOt+azNxZOcjJ8zO4AhF4 8l+ruLQ6whfn7ixZLKFB8FQIeEBsl1tqGqX5EkXcLiRfevZkoDNao+h5HcJ18zFXedDe hxzcUOabW5OQtq5Ii6oGKPmKf8uiFzsHbF1NaNr0vV1PQqPHiqL96hr41AV+h43fdOC5 lxXT70/S9K7AZGKmzB89BFIDvMTC8wpoHB2oY0VCW1Sd0bSUttbPXFoN2G8JyxC3HWFR AohOxfxqUAiTSj14fc0J3vX1t+DcsTIr5EBdUevbNRCa5VPG9NnjjEgJhC5C/Wy6QG4x gB6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h7-v6si13073093pgc.14.2018.05.22.09.11.08; Tue, 22 May 2018 09:11:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752163AbeEVQLA convert rfc822-to-8bit (ORCPT + 99 others); Tue, 22 May 2018 12:11:00 -0400 Received: from prv1-mh.provo.novell.com ([137.65.248.33]:49780 "EHLO prv1-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751837AbeEVQK5 (ORCPT ); Tue, 22 May 2018 12:10:57 -0400 Received: from INET-PRV1-MTA by prv1-mh.provo.novell.com with Novell_GroupWise; Tue, 22 May 2018 10:10:56 -0600 Message-Id: <5B04410D02000078001C4CC5@prv1-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 18.0.0 Date: Tue, 22 May 2018 10:10:53 -0600 From: "Jan Beulich" To: Cc: "xen-devel" , "Boris Ostrovsky" , "Juergen Gross" , Subject: Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary References: <20180522035445.16911-1-boris.ostrovsky@oracle.com> <20180522035445.16911-2-boris.ostrovsky@oracle.com> <5B0421E502000078001C4B91@prv1-mh.provo.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 22.05.18 at 17:15, wrote: > On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote: >>>>> On 22.05.18 at 15:45, wrote: >>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky wrote: >>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen) >>>> /* 64-bit entry point. */ >>>> .code64 >>>> 1: >>>> + /* Set base address in stack canary descriptor. */ >>>> + mov $MSR_GS_BASE,%ecx >>>> + mov $canary, %rax >>>> + cdq >>>> + wrmsr >>> >>> CDQ only sign-extends EAX to RAX. What you really want is to move the >>> high 32-bits to EDX (or zero EDX if we can guarantee it is loaded >>> below 4G). >> >> What you describe is CDQE (AT&T name: CLTD); CDQ (AT&T: CLTQ) >> sign-extends EAX to EDX:EAX. > > But that would still be wrong, as it would set EDX to 0xFFFFFFFF if > the kernel was loaded between 2G and 4G. Looking closer at the code, > we just left 32-bit mode, so we must have been loaded below 4G, > therefore EDX must be zero. Ah, yes, indeed. Jan