From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB3EAC04EBC for ; Sun, 18 Nov 2018 07:16:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B0CE22080F for ; Sun, 18 Nov 2018 07:16:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0CE22080F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727079AbeKRRf2 (ORCPT ); Sun, 18 Nov 2018 12:35:28 -0500 Received: from mga09.intel.com ([134.134.136.24]:44865 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725915AbeKRRf2 (ORCPT ); Sun, 18 Nov 2018 12:35:28 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2018 23:16:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,247,1539673200"; d="scan'208";a="87333249" Received: from kaczmarx-mobl.ger.corp.intel.com (HELO localhost) ([10.249.254.89]) by fmsmga008.fm.intel.com with ESMTP; 17 Nov 2018 23:15:50 -0800 Date: Sun, 18 Nov 2018 09:15:48 +0200 From: Jarkko Sakkinen To: Andy Lutomirski Cc: Dave Hansen , "Christopherson, Sean J" , Jethro Beekman , Florian Weimer , Linux API , Jann Horn , Linus Torvalds , X86 ML , linux-arch , LKML , Peter Zijlstra , Rich Felker , 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 Subject: Re: RFC: userspace exception fixups Message-ID: <20181118071548.GA4795@linux.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 01, 2018 at 10:53:40AM -0700, Andy Lutomirski wrote: > Hi all- > > The people working on SGX enablement are grappling with a somewhat > annoying issue: the x86 EENTER instruction is used from user code and > can, as part of its normal-ish operation, raise an exception. It is > also highly likely to be used from a library, and signal handling in > libraries is unpleasant at best. > > There's been some discussion of adding a vDSO entry point to wrap > EENTER and do something sensible with the exceptions, but I'm > wondering if a more general mechanism would be helpful. I haven't really followed all of this discussion because I've been busy working on the patch set but for me all of these approaches look awfully complicated. I'll throw my own suggestion and apologize if this has been already suggested and discarded: return-to-AEP. My idea is to do just a small extension to SGX AEX handling. At the moment hardware will RAX, RBX and RCX with ERESUME parameters. We can fill extend this by filling other three spare registers with exception information. AEP handler can then do whatever it wants to do with this information or just do ERESUME. In some ways this dummied version of Sean's suggestion. I think whatever the solution is it should be lightweight and this is such solution. Why? Because exception handling could be then used to implement other stuff than just error hadling like syscall wrapper for the enclaves in nice and lean way. /Jarkko