Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1200648imd; Thu, 1 Nov 2018 11:46:22 -0700 (PDT) X-Google-Smtp-Source: AJdET5ceBNieSsXYhnfeIVkZ62FqY2ucoZuQX59xHy6Y4Fx+HuOs8B02rWxOHDKNYfSDTXCE6eGQ X-Received: by 2002:a62:9015:: with SMTP id a21-v6mr8852448pfe.49.1541097982723; Thu, 01 Nov 2018 11:46:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541097982; cv=none; d=google.com; s=arc-20160816; b=Xd5tVIe9qdvg5Hhv4D1G+HaqPXm4dWAhG5T1nMn4qSCJV+hKEe2ZTnqDZSNfThdp27 as6bgAyJYMZ6fPOIVNBfkaxXC9LrdQsir3oId1jSZEYFyO3Sx4awv4tPqiLNtZp+xFkb hb9YYUyOKW2g+D2UdJM4Ifd224gC7BNOOUWuZWtt/xO3io+Hbm/yNxW4Gn8KYJLg8YYy bWIVAbTedl7X/wSZCgQqJ18FPbiPYATK9j3HK/cd0suXaAdgkEH51R8YwLaYmO5qml6N kTAuiFrZcy8XwPuzUEM5E82q+xOiDWqq/T0luKZK45SoZ1V1CuLLOvfhyvImcoGZ/oay 3Ohg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=LRFAefcU8B722UOuF5RZ+QTjbCZ3RTXkR1KzZGGyNHk=; b=MwfeJtlSF5Sle4r1nBMsUP1GbGGnTnMvZwVsl46N9Rf8B4Bp3X1fQsmenSZmT45bPS q940EpqmXPoJH4biGgtoP2bloW7RV8eSurP0mP/ypdyLLtiMKo+5vwuAde5CLuAhOA8K /P8a1a1fnYz5/6rStHSljfkokWhc5qNjxlGArqQS4oUiArcs4xZKwVX4cSgtm3ApMrGr 2S+VgsShFg8m6O3+gmbw1Kq+IHFCr0U4kkDciXcOPMsZg6LGxmL5Pdadvqf5BA4LvzKu U1VPKwMvTuMTNPtQDLfLWouuJkw+6NeNVqTlTzvXhxwFPV4DjsJc3X725nuO6DooFJ3T jnnA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si3024596pll.325.2018.11.01.11.46.07; Thu, 01 Nov 2018 11:46:22 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727561AbeKBDt4 (ORCPT + 99 others); Thu, 1 Nov 2018 23:49:56 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:57898 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725961AbeKBDt4 (ORCPT ); Thu, 1 Nov 2018 23:49:56 -0400 X-Greylist: delayed 937 seconds by postgrey-1.27 at vger.kernel.org; Thu, 01 Nov 2018 23:49:55 EDT Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1gIHh2-0001Vu-00; Thu, 01 Nov 2018 18:27:44 +0000 Date: Thu, 1 Nov 2018 14:27:44 -0400 From: Rich Felker To: Andy Lutomirski Cc: Dave Hansen , "Christopherson, Sean J" , Jethro Beekman , Jarkko Sakkinen , Florian Weimer , Linux API , Jann Horn , Linus Torvalds , 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 Subject: Re: RFC: userspace exception fixups Message-ID: <20181101182744.GA5150@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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. > > The basic idea would be to allow libc, or maybe even any library, to > register a handler that gets a chance to act on an exception caused by > a user instruction before a signal is delivered. As a straw-man > example for how this could work, there could be a new syscall: > > long register_exception_handler(void (*handler)(int, siginfo_t *, void *)); > > If a handler is registered, then, if a synchronous exception happens > (page fault, etc), the kernel would set up an exception frame as usual > but, rather than checking for signal handlers, it would just call the > registered handler. That handler is expected to either handle the > exception entirely on its own or to call one of two new syscalls to > ask for normal signal delivery or to ask to retry the faulting > instruction. > > Alternatively, we could do something a lot more like the kernel's > internal fixups where there's a table in user memory that maps > potentially faulting instructions to landing pads that handle > exceptions. This strikes me as just an "extra layer of signal handlers"; rather than replacing global state with something that's library-safe, it's just making new global state that has to have a singleton owner managing it. If these handlers were thread-local (vs process-global signal disposition) then you could just register/unregister them on entry/exit to the library code that needs them, but that has nontrivial execution time cost. Moreover, thread-local signal handlers can already be done really nicely if you don't care about having a global handler (which doesn't really make sense for synchronous signals). I have fairly canonical draft code I wrote to demonstrate this a while back which I can share if there's interest. One possible advantage of your approach is that it could distinguish actual synchronous signals from ones sent by kill/sigqueue/etc. This matters in contexts where the application wants the signal blocked or ignored. For example if you temporarily set a handler for SIGILL or SIGSEGV, then unblock it and try to do something that might generate the signal, you risk consuming an unrelated pending signal sent by kill/sigqueue/etc. As far as I know there is no way to do this "transparently". It came up as an issue for why libc init code cannot do this kind of probing for instruction availability at startup (or any time). > Do you think this would be useful? Here are some use cases that I > think are valid: > > (a) Enter an SGX enclave and handle errors. There would be two > instructions that would need special handling: EENTER and ERESUME. I'm not familiar with SGX but the vdso approach sounds like a better abstraction. > (b) Do some math and catch division by zero. I think it would be a > bad idea to have user code call a function and say that it wants to > handle *any* division by zero, but having certain specified division > instructions have special handling seems entirely reasonable. I don't think this is useful. If you really need a division that needs to survive invalid operands, a simple check before the div (100%-predictable branch in non-erroneous usage) is dirt cheap. > (c) Ditto for floating point errors. Signaling floating point exceptions (rather than sticky flags) are something of an oddity that's never enabled by default, not supported on all platforms, and largely (IMO) useless. Generating code that can support them can be moderately costly too. > (d) Try an instruction and see if it gets #UD. In general this seems fairly useful. > (e) Run a bunch of code and handle page faults to a given address > range by faulting something in. This is not like the others, in that > a handler wants to handle a range of target addresses, not > instructions. And userfaultfd is plausibly a better solution anyway. Agree re: userfaultfd. > (f) Run NaCl-like sandboxed code where the code can cause page faults > to certain mapped-but-intentionally-not-present ranges and those need > to be handled. > > On Windows, you can use SEH to do crazy things like running > known-buggy code and eating the page faults. I don't think we want to > go there. Agree, this is a huge rabbit hole of filth. Don't go there. Rich