Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2385638imu; Tue, 6 Nov 2018 13:43:23 -0800 (PST) X-Google-Smtp-Source: AJdET5fs4lcyleSReBozVgAl/oIBHM8AiIsHYDUnSUfBnNXmHgOyFN4HkxvXD+92GohDYMMKUGo1 X-Received: by 2002:a63:c24c:: with SMTP id l12mr25280537pgg.146.1541540602977; Tue, 06 Nov 2018 13:43:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541540602; cv=none; d=google.com; s=arc-20160816; b=ee7YSvFAgcMloN6tYI18VXDJGHpemSrqEkAOhfihGGSvto8e8eM9lUJJwrhF25sA1j RFBsnk2ayOjsK4B+u4vlUPo1GXGqK6Y1d4+/757Q0jUbyl55EUEzWrx8dfddxgJpW7dF 82BpYGn4ca8k/+pQ708RvjZrEL/m0LvHqr4d6btzaaG6dmQpBQYt8I6vNzALRC6XpfNT 7bDAcQ1fhgKy1m2urJytP4CUPKIbIWeuB2Vap9JJMmVm5ujfBeozhadi5Xt96DLIy+hV 8TkT21uAwAwaVmsVgOfADuPTPyR/J6jwlsEAs+vKLu/NGXIHnqb0StreWJZPclrDMjPu 2Jcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=mfm3w47C9PzN5G0vr3h3PFKiL+FzVNTFCwq+P7UetqA=; b=KS26aKi4dXDInm6V2de0SMjbxhaY96ZcWchOI9Wt8L2zU4lUHsNyLTPyE2Nlqo2GPU SVSH2K0MKa11+sfB7pd4CXVnvCvTed58Jnjrk31lWtYavIjDMtszfXEbbaH/Mw86n/Qr VfYQBB6PEv9EKIV8Rj+cawnQz9y+KH9828hmTJ4VznFTS0x6VKL/09P75ppiSBljG5NB Yj4Y9bwuntWov6af549d40GlY5aCHvDPJhhhCwoh45v2O1g+pKCCgqKnz61+HQmef9dj +0byHKx375HRoPtaZlntcBUV4tzuddOBnWRz70stSTuLK+qBJpHJgtSku9Fy1hwIRq4M sscw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=b2jw2xbR; 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 n6-v6si47193786pgd.25.2018.11.06.13.43.07; Tue, 06 Nov 2018 13:43:22 -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=b2jw2xbR; 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 S1730680AbeKGHJY (ORCPT + 99 others); Wed, 7 Nov 2018 02:09:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:37940 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726261AbeKGHJX (ORCPT ); Wed, 7 Nov 2018 02:09:23 -0500 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 CED8A2083D for ; Tue, 6 Nov 2018 21:42:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541540527; bh=ZLGkX2/fHbuTlmD8ZeECMFUn49KO4EBC58hjYDf9KcA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=b2jw2xbRZRGQCjAwxzxyeX8sn4EodFrMDjIm5BinxRgOrWkFgz9RHiEVqScoFpnhQ jRxqmmk1hcOouqMSQxMiSor7rjp9I0/O+vSgm+iD8OZ7XHZyFjzwf2ajxwgBvpw7le mZIrMbOZHbIfWPI3fCxLwGK2pOmfsN98rGCLUmY8= Received: by mail-wr1-f41.google.com with SMTP id z16-v6so15237564wrv.2 for ; Tue, 06 Nov 2018 13:42:06 -0800 (PST) X-Gm-Message-State: AGRZ1gKJvGkSFMzyra2e3P9TJz4PtjY2azIeqJpFRqYQadzsbcMIAYgO wf8tkLkFBBQuYcn6kzKLqqd+g5fFebO8K+iGNShqKQ== X-Received: by 2002:adf:b1db:: with SMTP id r27-v6mr25013353wra.95.1541540525308; Tue, 06 Nov 2018 13:42:05 -0800 (PST) MIME-Version: 1.0 References: <20181102170627.GD7393@linux.intel.com> <20181102173350.GF7393@linux.intel.com> <20181102182712.GG7393@linux.intel.com> <20181102220437.GI7393@linux.intel.com> <1541518670.7839.31.camel@intel.com> <1541524750.7839.51.camel@intel.com> <22596E35-F5D1-4935-86AB-B510DCA0FABE@amacapital.net> <1C426267-492F-4AE7-8BE8-C7FE278531F9@amacapital.net> <209cf4a5-eda9-2495-539f-fed22252cf02@intel.com> <9B76E95B-5745-412E-8007-7FAA7F83D6FB@amacapital.net> In-Reply-To: <9B76E95B-5745-412E-8007-7FAA7F83D6FB@amacapital.net> From: Andy Lutomirski Date: Tue, 6 Nov 2018 13:41:53 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: userspace exception fixups To: Dave Hansen Cc: Andrew Lutomirski , "Christopherson, Sean J" , Jann Horn , Linus Torvalds , Rich Felker , Dave Hansen , Jethro Beekman , Jarkko Sakkinen , Florian Weimer , Linux API , X86 ML , linux-arch , LKML , Peter Zijlstra , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org, Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Carlos O'Donell" , adhemerval.zanella@linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 6, 2018 at 1:07 PM Andy Lutomirski wrote: > > > > > On Nov 6, 2018, at 1:00 PM, Dave Hansen wrote: > > > >> On 11/6/18 12:12 PM, Andy Lutomirski wrote: > >> True, but what if we have a nasty enclave that writes to memory just > >> below SP *before* decrementing SP? > > > > Yeah, that would be unfortunate. If an enclave did this (roughly): > > > > 1. EENTER > > 2. Hardware sets eenter_hwframe->sp =3D %sp > > 3. Enclave runs... wants to do out-call > > 4. Enclave sets up parameters: > > memcpy(&eenter_hwframe->sp[-offset], arg1, size); > > ... > > 5. Enclave sets eenter_hwframe->sp -=3D offset > > > > If we got a signal between 4 and 5, we'd clobber the copy of 'arg1' tha= t > > was on the stack. The enclave could easily fix this by moving ->sp fir= st. > > > > But, this is one of those "fun" parts of the ABI that I think we need t= o > > talk about. If we do this, we also basically require that the code > > which handles asynchronous exits must *not* write to the stack. That's > > not hard because it's typically just a single ERESUME instruction, but > > it *is* a requirement. > > > > I was assuming that the async exit stuff was completely hidden by the API= . The AEP code would decide whether the exit got fixed up by the kernel (wh= ich may or may not be easy to tell =E2=80=94 can the code even tell without= kernel help whether it was, say, an IRQ vs #UD?) and then either do ERESUM= E or cause sgx_enter_enclave() to return with an appropriate return value. > > Sean, how does the current SDK AEX handler decide whether to do EENTER, ERESUME, or just bail and consider the enclave dead? It seems like the *CPU* could give a big hint, but I don't see where there is any architectural indication of why the AEX code got called or any obvious way for the user code to know whether the exit was fixed up by the kernel?