Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2901501imu; Sun, 11 Nov 2018 03:33:29 -0800 (PST) X-Google-Smtp-Source: AJdET5exPy0y0EssNl0f5RENZUtesQLQORLEc2JQGuji/qdiL5GVqaSS5//by8hHk5Xqfjcu4YSw X-Received: by 2002:a63:2e02:: with SMTP id u2mr14042822pgu.9.1541936009142; Sun, 11 Nov 2018 03:33:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541936009; cv=none; d=google.com; s=arc-20160816; b=OljJAMsoypPsLJVNPC+ubmKjhc4nf2hpkD+CYUIoOTI+z4onPMldOlW7+IAtpf9uoF ZIl3UZQiv+Ubbu0yo6YVF51JNyFYgsm4ucCZQpusAowx0VbZ2n44MzwEGjypMQ1SjLIi JNQWYHxw/ASQmoRlVK+RNnq9gPPJuXxIJmYhYxeq4OS4psb6nmFWzaIRYYQ4hzJke5xm 6oc2wFSCOCTVdrJ8KkYO6q+scXNr2FPqfzQJ+XbCAf0zRZ5V6tMxoiH4NHuq0KSvVhk0 V968qvQkwdMAKP2hE/76PwEIhUdYHEVXUONrqWa2nfXcj+GrldWSkUgG+7F6MWa4v232 B3Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7RJbNLtoZqvc7HHQCzECMl44zUxO1R3qBR88fI2ozko=; b=LajJ9XL9CNjN94eQgzmsJ4+dKoUZS5v6Yph0fDjaOYN1ZDLZQ3ibp5EaY1UA5ob+gB jXQqkY6vfanFBBcepFSzExRdT+W0ZDAvFbtTLr1On1kxvXGYmgZrkZFsQkee2URewFS7 38bxPwdQEWqevszcV+qNdfZzBukt0EIKH+bnz+yfB79mTrnX+Sh1CkiBCZ2GSP315k4d S3nRJtrSRUP/kcbgNelcETR9FWvTDO/ASYfJpB/x3z7ewSCddhokMynwdmGKcLuBBSto LAFWP+kEAuSztP1KlKmPDH3+uFPR7x2BWYfJufOc3EW+KhA1MsfjPJRkTRlr6f6g1TNr 0z4Q== 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 a5-v6si9780349plh.157.2018.11.11.03.33.14; Sun, 11 Nov 2018 03:33:29 -0800 (PST) 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 S1728098AbeKKVTr (ORCPT + 99 others); Sun, 11 Nov 2018 16:19:47 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:44281 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727556AbeKKVTr (ORCPT ); Sun, 11 Nov 2018 16:19:47 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 45C34806D3; Sun, 11 Nov 2018 12:31:24 +0100 (CET) Date: Sun, 11 Nov 2018 12:31:25 +0100 From: Pavel Machek To: Andy Lutomirski Cc: Yu-cheng Yu , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H. J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , "Shanbhogue, Vedvyas" Subject: Re: [PATCH v5 04/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Message-ID: <20181111113125.GI27666@amd> References: <20181011151523.27101-1-yu-cheng.yu@intel.com> <20181011151523.27101-5-yu-cheng.yu@intel.com> <4295b8f786c10c469870a6d9725749ce75dcdaa2.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TA4f0niHM6tHt3xR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --TA4f0niHM6tHt3xR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > > > +/* > > > > + * State component 12 is Control flow Enforcement kernel states > > > > + */ > > > > +struct cet_kernel_state { > > > > + u64 kernel_ssp; /* kernel shadow stack */ > > > > + u64 pl1_ssp; /* ring-1 shadow stack */ > > > > + u64 pl2_ssp; /* ring-2 shadow stack */ > > > > +} __packed; > > > > + > > > > > > Why are these __packed? It seems like it'll generate bad code for no > > > obvious purpose. > > > > That prevents any possibility that the compiler will insert padding, al= though in > > 64-bit kernel this should not happen to either struct. Also all xstate > > components here are packed. > > >=20 > They both seem like bugs, perhaps. As I understand it, __packed > removes padding, but it also forces the compiler to expect the fields > to be unaligned even if they are actually aligned. This structure is shared with hardware, right? __packed seems like right thing to do semantically. As x86 handles unaligned accesses automatically, there should not be much difference either way. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --TA4f0niHM6tHt3xR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlvoEw0ACgkQMOfwapXb+vLY1gCglZ9VACt9vxNg/QC9O9on/sJW mGoAnA825hlJ7l0ichrQ9oFwIh31PPDp =dUic -----END PGP SIGNATURE----- --TA4f0niHM6tHt3xR--