Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: Gr8vt0UrdPl9QD1QFhiVM4FsfugMOr8ctk86Z0plhUMxRVdtbPq/39LFmbY38WqB0kUk4C6zDY
 aO3R1V51znFw==
IronPort-SDR: 0TRG9d159j5c9hBSSSCMIu6gXkycyMjX1F7tQzG4wyo0IKU//t6Rjy7rtmSJpE8wmgJBtGNMaW
 0dD1d0P6IOIA==
Date:   Tue, 30 Jun 2020 07:55:43 -0700
From:   Sean Christopherson <sean.j.christopherson@intel.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, x86@kernel.org,
        linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org,
        Andy Lutomirski <luto@amacapital.net>,
        Jethro Beekman <jethro@fortanix.com>,
        akpm@linux-foundation.org, andriy.shevchenko@linux.intel.com,
        asapek@google.com, cedric.xing@intel.com, chenalexchen@google.com,
        conradparker@google.com, cyhanish@google.com,
        dave.hansen@intel.com, haitao.huang@intel.com,
        josh@joshtriplett.org, kai.huang@intel.com, kai.svahn@intel.com,
        kmoy@google.com, ludloff@google.com, luto@kernel.org,
        nhorman@redhat.com, npmccallum@redhat.com, puiterwijk@redhat.com,
        rientjes@google.com, tglx@linutronix.de, yaozhangx@google.com
Subject: Re: [PATCH v33 15/21] x86/vdso: Add support for exception fixup in
 vDSO functions
Message-ID: <20200630145543.GB7733@linux.intel.com>
References: <20200617220844.57423-1-jarkko.sakkinen@linux.intel.com>
 <20200617220844.57423-16-jarkko.sakkinen@linux.intel.com>
 <20200629171022.GC32176@zn.tnic>
 <20200630060055.GS12312@linux.intel.com>
 <20200630084128.GA1093@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200630084128.GA1093@zn.tnic>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jun 30, 2020 at 10:41:28AM +0200, Borislav Petkov wrote:
> On Mon, Jun 29, 2020 at 11:00:55PM -0700, Sean Christopherson wrote:
> > E.g. the vDSO function should get the fixup even if userspace screws
> > up mmap() and invokes __vdso_sgx_enter_enclave() without being tagged
> > an SGX task.
> 
> I sincerely hope you don't mean this seriously.
> 
> Please add a member to task_struct which denotes that a task is an
> sgx task, test that member where needed and forget real quickly about
> running *any* *fixup* for unrelated tasks.

But IMO they're not unrelated if they end up in __vdso_sgx_enter_enclave().
Getting to the point where __vdso_sgx_enter_enclave() actually attempts
ENCLU (the single fixup entry) requires a very deliberate attempt to run an
enclave.  Not to mention the fixup doesn't squash the fault, it simply
morphs what would be a signal into a synchronous error.

And I don't see how to sanely track this in task_struct.  As stated before,
the only foolproof way to identify an SGX task is by tracking whether it
has a VMA backed by /dev/sgx/enclave, i.e. the flag would probably need to
reside in mm_struct.  Keying off opening /dev/sgx/enclave isn't viable as
enclaves can be handed off via SCM_RIGHTS or fork().

Putting a flag in mm_struct is doable, but it would need to be sticky to
keep things sane, e.g. clearing the flag on unmapping the enclave would
require refcounting VMAs and hooking vm_ops->close.  The refcounting is
painful (we had it for several years) and ->close prevents merging VMAs,
which IMO is far worse than unconditionally morphing fault-based signals
that originate in __vdso_sgx_enter_enclave().  And assuming we don't do the
whole ->close thing, we'd end up with MADV_DONTFORK -> fork() having
divergent behavior for mm_structs without /dev/sgx/enclave VMAs, i.e. the
child of MADV_DONTFORK -> fork() case would not be tagged SGX (unless we
intentionally do the "wrong" thing and propagate the flag), whereas the
munmap() case would result in a SGX-tagged mm_struct with no
/dev/sgx/enclave VMAs.