Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2238074imu; Tue, 6 Nov 2018 11:09:44 -0800 (PST) X-Google-Smtp-Source: AJdET5c+ssAcNDqJwD64Mko+AXWjLT68Vk1PxV3BPdsAr3rEk+hwcoM5HqQ/Nl9vuk1ZDrCLjNru X-Received: by 2002:a17:902:b405:: with SMTP id x5-v6mr21209317plr.4.1541531384861; Tue, 06 Nov 2018 11:09:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541531384; cv=none; d=google.com; s=arc-20160816; b=DVCYzTNM3/QlWl9UvaCi29vto4wcHS8MJMFmURXsO+4nQj4RwBjuYSzjIDSqC36M09 BqOWC8R/ThfexpNn8pql56qV8GgZnAXG9uvQ2vQaOK/t4zMAknlOanANUPVkr0kKhLJv y/BC0IHKhn+eH2YYNi/jjG96ISwb5PekIHm6Hd/uEHkNrXHdnUqOBzPfMJQ1xhpJpsm6 q2DbqADFCfgu9VUaqi2TGSvbIVxtj21jOBV8sYqt2Byt24Ivyo+OZLNRyBFn3FOaW/YX fDkV+BoVcbsMwx3ykztsP1XWg1tAOXGKqJCRo7PISYtNdw3E2IZ9jKunZ2+0wJMLrTx1 x/ag== 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=GveOV2pQKBnxgMWnIa+ptOisa9ygXl9h0ckXnJlyHms=; b=BJYXPBs20PshXVbRSRwWpofKY+92qub8l9dxhABi8uKAqEwsEZ6jfleVRktin4fRl2 d+vkP4J3di2zEGjJqOd7ihRbdF/ebu1NNrhCWD0S+zUWSpo+/2dJzU7uRjpmWjuWWbzx GEaAc+S+y+doBBWfqw/0bqWzEVzTj+VzzQddjNpy5KsYWaHnrMP+vXf9gmglzrBzOS94 Y6TRXpE581AjQ/sehCYaU0FHfm/y1c50rx0x2rIQpKj330L7q3HRop1WPm3x+l4Znlr5 MZHW08TouLvOBsQmR1EuA+AejELckL3nktU3Sb1HMgT+kn0wStneGqMEBMC2Bbs8lXDx laOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=BRnIspXo; 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 t69si16474138pgb.365.2018.11.06.11.09.29; Tue, 06 Nov 2018 11:09:44 -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=BRnIspXo; 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 S1730661AbeKGEeM (ORCPT + 99 others); Tue, 6 Nov 2018 23:34:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:47718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730529AbeKGEeM (ORCPT ); Tue, 6 Nov 2018 23:34:12 -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 96B2621019 for ; Tue, 6 Nov 2018 19:02:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541530945; bh=OWckdEQFOYA4cQI4pvxJmjEMWkomeSWDwDzW0sSXU3I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BRnIspXorYhZ52GkKqjKwcn+s0kJVwoICdJ5dFN1rG7cxprt17FJWg1Q8O4mSlYY7 49LaD3Bwyzi1SVRXWVzs4Vod6wFcIhhnevbGCWh8Vi/PzCqhc7xKk+85VE2u1t5D3I iqgEOsMYulPu/7RWws9FqcZBLQ02ha+r2otWcw8A= Received: by mail-wr1-f41.google.com with SMTP id y15-v6so14770486wru.9 for ; Tue, 06 Nov 2018 11:02:25 -0800 (PST) X-Gm-Message-State: AGRZ1gINIzYTIJCkvU/zEtmq8yfsnlzMWM5uH2o9rNLWHIhERtTqpiti u2jhkqRLZRM3G9qVGv+lJWUHFW5h9U0md41+5FGfKg== X-Received: by 2002:adf:82c9:: with SMTP id 67-v6mr23365080wrc.131.1541530943892; Tue, 06 Nov 2018 11:02:23 -0800 (PST) MIME-Version: 1.0 References: <20181102163034.GB7393@linux.intel.com> <7050972d-a874-dc08-3214-93e81181da60@intel.com> <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> In-Reply-To: From: Andy Lutomirski Date: Tue, 6 Nov 2018 11:02:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: userspace exception fixups To: Dave Hansen Cc: "Christopherson, Sean J" , Andrew Lutomirski , 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" 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 10:41 AM Dave Hansen wrote: > > On 11/6/18 10:20 AM, Andy Lutomirski wrote: > > I almost feel like the right solution is to call into SGX on its own > > private stack or maybe even its own private address space. > > Yeah, I had the same gut feeling. Couldn't the debugger even treat the > enclave like its own "thread" with its own stack and its own set of > registers and context? That seems like a much more workable model than > trying to weave it together with the EENTER context. So maybe the API should be, roughly sgx_exit_reason_t sgx_enter_enclave(pointer_to_enclave, struct host_state *state); sgx_exit_reason_t sgx_resume_enclave(same args); where host_state is something like: struct host_state { unsigned long bp, sp, ax, bx, cx, dx, si, di; }; and the values in host_state explicitly have nothing to do with the actual host registers. So, if you want to use the outcall mechanism, you'd allocate some memory, point sp to that memory, call sgx_enter_enclave(), and then read that memory to do the outcall. Actually implementing this would be distinctly nontrivial, and would almost certainly need some degree of kernel help to avoid an explosion when a signal gets delivered while we have host_state.sp loaded into the actual SP register. Maybe rseq could help with this? The ISA here is IMO not well thought through.