From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit Date: Mon, 16 Nov 2015 12:11:11 -0800 Message-ID: References: <1447456706-24347-1-git-send-email-boris.ostrovsky@oracle.com> <56468D24.8030801@oracle.com> <564A0371.2040104@oracle.com> <20151116195906.GB20137@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20151116195906.GB20137@pd.tnic> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Borislav Petkov Cc: Boris Ostrovsky , David Vrabel , "linux-kernel@vger.kernel.org" , xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov wrote: > On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote: > >> ... >> The reader surely doesn't remember that this isn't guaranteed to be a >> swapgs instruction on native. Using: >> >> ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV >> >> would be safer (it would get rid of the SWAPGS_UNSAFE_STACK mess) and >> much clearer. We could hide *that* behind a macro and no one would be >> confused. (Well, they'd be confused by the fact that Xen PV handles >> gsbase very differently from native, but that has nothing to do with >> the macro.) >> >> I think we could convert piecemeal, and I wonder if this new patch for >> 32-bit native on 4.4 (this is needed for 4.4, right?) would be a good >> starting point. Borislav, what do you think? Would you be okay with >> adding a Xen PV pseudofeature? > > AFAICT, I'd prefer this becomes rather a jump label which gets enabled > on xen. Especially if a single pseudofeature might not be enough, > apprently... Except it's not a jump. (Also, the alternatives infrastructure is IMO much nicer than the jump label infrastructure.) Taking SWAPGS as an example, the semantics we need are: - On native, do swapgs. This *can't* be a call due to RSP issues. - On Xen PV, swapgs will work, but it's emulated. We'd rather just nop it out. In principle, we could static jump over it on Xen, but that also involves forcing the jump label to be built on old GCC versions, which PeterZ objected to the last time I asked. If it would make you feel better, it could be X86_BUG_XENPV :-p Are there really multiple feature bits for this stuff? I'd like to imagine that the entry code is all either Xen PV or native/PVH/PVHVM -- i.e. I assumed that PVH works like native for all entries. --Andy tip #101: Trim your mails when you reply. -- Andy Lutomirski AMA Capital Management, LLC