Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp856040imu; Fri, 7 Dec 2018 09:57:29 -0800 (PST) X-Google-Smtp-Source: AFSGD/UH2KJ/uENozv0vEGaUtFMtlY9CeASrwQbrmaGU7g/C/KN4HjbZCe1QOlmEsTDBgYQIFCch X-Received: by 2002:a17:902:aa8c:: with SMTP id d12mr3089754plr.25.1544205448978; Fri, 07 Dec 2018 09:57:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544205448; cv=none; d=google.com; s=arc-20160816; b=TWy1+crZU2maCLtuCyNJPks8h4XrtRxJnDbltlW4WoezNGXS/X3Feh0Mkf8FtiayjK 8V5Lg2nq2gDk7b2k9wOyUzTaNeFBXCOcgowEor6SGG72nOOf0IoFDFh3GLaLQLiit3AD TePCytFRpDXbNQzZZewbilXyVsYB+mzlz7eOJOMIdNxE3EajefEc2wRPUZs4l2bRF9yQ Ig+dhD5MHUD28OaWVE1+JgxjHsWZEgXv2j5q6trjgYp55ej9TouOT42iP2eTDpQ/JIl3 ToKgsJpM6VQ/JlqoWMbaML9aXw8EySXLlEH/i6buTsriUNVCdim2NfjTNJDfP1t8wakI 8tsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=uzqVrJgYXnmxG0ub/6JiWXjb2nl7cXfoi7VcjY3xQys=; b=EzcFQ0zSzaylwJN43FmFBBes/hG6Gx1dlUxZSifx8ShLyeXorZwEtmYu/REeYfkXm8 HSxgMvMX8cEb5XxoiTi2B4XKMdux5kifd6rnNOShy/Q73QWINdm/Vf4djQHEvfX5Ntcd 5RB9y+qC6fE48/3PPosfIwsrgnluZUbe77nKVXQOsuFZCUWSWM9KbFGpRTyAMgnkqh7P Uc2yPuWY6nscgf6xdE58gGdmCdeRmEqg+v3TsldFz6V7QUXaGDKttm9jDWy4CaqCQpOM 7GNebxxcDRArOAHuKZB14shTzETNJBpGEiP7PvcNZJs+ktH5ctArjLeCYoapynsqd1QX PpGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=I5+jkLMq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si3342768pgm.194.2018.12.07.09.57.13; Fri, 07 Dec 2018 09:57:28 -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; dkim=pass header.i=@kernel.org header.s=default header.b=I5+jkLMq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726177AbeLGR40 (ORCPT + 99 others); Fri, 7 Dec 2018 12:56:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:37732 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726130AbeLGR40 (ORCPT ); Fri, 7 Dec 2018 12:56:26 -0500 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2380A2082D for ; Fri, 7 Dec 2018 17:56:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544205385; bh=eYA6Un5E3SjnCQ/0lna2qchuwKY1UJ/Zte/umEg/5hA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=I5+jkLMqLZ9muw1OqFQCOb/FHJgnnAvBxvlLcBYNA9Oke2C/dk0teciiTjv5kpWyc xX5TC8r+2Zwzq8nRj1KhCXhQwSrRm0jemUF8gPDZif84KdZi5oPqBXc6GkrxDAomlm GiHXbMaP5yQPl9HlWnOGaGkcljE+M7Oe3/yiTWPw= Received: by mail-wm1-f48.google.com with SMTP id s14so5225677wmh.1 for ; Fri, 07 Dec 2018 09:56:25 -0800 (PST) X-Gm-Message-State: AA+aEWYwY5Com3mmWoSK0+41C0l/9yfB83XQGr4qh6dPk5mGXato1Jsi gb2RaCih63q6ehU6GvS6+az9KwRE15xumnjw/lHjnA== X-Received: by 2002:a1c:f112:: with SMTP id p18mr2884558wmh.83.1544205383599; Fri, 07 Dec 2018 09:56:23 -0800 (PST) MIME-Version: 1.0 References: <20181206221922.31012-1-sean.j.christopherson@intel.com> <20181206221922.31012-5-sean.j.christopherson@intel.com> <20181207165145.GB10404@linux.intel.com> In-Reply-To: <20181207165145.GB10404@linux.intel.com> From: Andy Lutomirski Date: Fri, 7 Dec 2018 09:56:09 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions To: "Christopherson, Sean J" Cc: Andrew Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , Dave Hansen , Peter Zijlstra , "H. Peter Anvin" , LKML , Jarkko Sakkinen , Josh Triplett , linux-sgx@vger.kernel.org, haitao.huang@linux.intel.com, Jethro Beekman , "Dr. Greg Wettstein" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 7, 2018 at 8:51 AM Sean Christopherson wrote: > > +Cc: linux-sgx, Haitao, Greg and Jethro > > My apologies for neglecting to cc the SGX folks, original thread is here: > > https://lkml.kernel.org/r/20181206221922.31012-1-sean.j.christopherson@intel.com > > On Thu, Dec 06, 2018 at 02:50:01PM -0800, Andy Lutomirski wrote: > > On Thu, Dec 6, 2018 at 2:19 PM Sean Christopherson > > wrote: > > > > > + > > > + /* > > > + * Invoke the caller's exit handler if one was provided. The return > > > + * value tells us whether to re-enter the enclave (EENTER or ERESUME) > > > + * or to return (EEXIT). > > > + */ > > > + if (exit_handler) { > > > + leaf = exit_handler(exit_info, tcs, priv); > > > + if (leaf == SGX_EENTER || leaf == SGX_ERESUME) > > > + goto enter_enclave; > > > + if (leaf == SGX_EEXIT) > > > + return 0; > > > + return -EINVAL; > > > + } else if (leaf != SGX_EEXIT) { > > > + return -EFAULT; > > > + } > > > > This still seems overcomplicated to me. How about letting the > > requested leaf (EENTER or ERESUME) be a parameter to the function and > > then just returning here? As it stands, you're requiring any ERESUME > > that gets issued (other than the implicit ones) to be issued in the > > same call stack, which is very awkward if you're doing something like > > forwarding the fault to a different task over a socket and then > > waiting in epoll_wait() or similar before resuming the enclave. > > Ah, yeah, wasn't thinking about usage models where the enclave could > get passed off to a different thread. > > What about supporting both, i.e. keep the exit handler but make it 100% > optional? And simplify the exit_handler to effectively return a boolean, > i.e. "exit or continue". > > Something like this: > > notrace long __vdso_sgx_enter_enclave(u32 op, void *tcs, void *priv, > struct sgx_enclave_exit_info *exit_info, > sgx_enclave_exit_handler *exit_handler) > { > u64 rdi, rsi, rdx; > u32 leaf; > long ret; > > if (!tcs || !exit_info) > return -EINVAL; > > enter_enclave: > if (op != SGX_EENTER && op != SGX_ERESUME) > return -EINVAL; > > > > /* > * Invoke the caller's exit handler if one was provided. The return > * value tells us whether to re-enter the enclave (EENTER or ERESUME) > * or to return (EEXIT). > */ > if (exit_handler) { > if (exit_handler(exit_info, tcs, priv)) { > op = exit_info->leaf; > goto enter_enclave; > } > } > > if (exit_info->leaf == SGX_EEXIT) > return -EFAULT; > > return 0; > } > > > I like that the exit handler allows userspace to trap/panic with the full > call stack in place, and in a dedicated path, i.e. outside of the basic > enter/exit code. An exit handler probably doesn't fundamentally change > what userspace can do with respect to debugging/reporting, but I think > it would actually simplify some userspace implementations, e.g. I'd use > it in my tests like so: > > long fault_handler(struct sgx_enclave_exit_info *exit_info, void *tcs, void *priv) > { > if (exit_info->leaf == SGX_EEXIT) > return 0; > > > } > Hmm. That't not totally silly, although you could accomplish almost the same thing by wrapping the vDSO helper in another function.