Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1254963pxk; Fri, 25 Sep 2020 09:56:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEbWSlDq+v4pqRDEBZxu/8TUcuY5yP2mDR6PuSoLykBYtLq/aQeD+NMZBi2GmppS96yAUs X-Received: by 2002:a50:ed02:: with SMTP id j2mr2380231eds.137.1601052999217; Fri, 25 Sep 2020 09:56:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601052999; cv=none; d=google.com; s=arc-20160816; b=Bbk+3Z8Pcd7L06Z+oSOS/ymNoIUf2Wr93Fy6S0rq0CqW6/ihkof867TaTyVK8vxEWn 7Pbh/+5afu7zuVq7TqLZEGQOCiJd8xQVnfz79zsiLw3VOnRL6NW5NWGkf67r8adLV4uM xNuKvfxTBXlkVZjN1+N8MrtnolXNW469+4ezn9d5F8a1yi51E06JSi4Fy7wuDn2kS61S FTb6CenbYpjpUPNG7Yv522j5tnXsruBvbU4bunpkumuzznWFIJ7N3mBwkuujcnc0k2Ws ik2dcPD0ywn0ZEJNAz2dIE3fYm5PK6K2KRqCIoyMwppglSUjpGemi4UR5NMw1IEF8m8D vkMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:subject:message-id:date:from:mime-version :dkim-signature; bh=eEWwZLpJetdxFg0/z1dpsWl++F4SZEJtSJB+bp0AfQ8=; b=iIQoKVDd8nj85u/b3Q8BywSWZIMG6e6Y0+7YFI6Jp9oQ5eKrvBJDgR3+sJ+38JMTqG e+puNw7Agr8MAJSSiY/Q22beiHUhkYj5FujJrLnTfoU6LW1hvdzXrdf7FfWa8tm1maa3 nuY0Qt8qaNDJYnGyLI/eZSJ3zUrcWFSZj99yuD/z8TZ0Rehk4MM0GOOJAQeVO78+TIbI z5BIsaNDn8V/lfirirUYMTU7FNUr1mM1SHX1+1lKGUd/BA8uDVUsWsbUoeeXy7pYUpt0 P+5iPnc44aYOoA3kzDRjRBF2BGnGyG/+88OuWBiYCAxdPWhIHWlKa1ltn33RKgfnXSnF 6zxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="o9L/ESS0"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id g21si2289834edy.588.2020.09.25.09.56.14; Fri, 25 Sep 2020 09:56:39 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="o9L/ESS0"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728212AbgIYQzO (ORCPT + 99 others); Fri, 25 Sep 2020 12:55:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:56018 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727201AbgIYQzN (ORCPT ); Fri, 25 Sep 2020 12:55:13 -0400 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 E18B521D42 for ; Fri, 25 Sep 2020 16:55:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601052913; bh=ib/7oEhvLrcpwHngtLoUjyPRrDSFjMvIeWnVdOB6HYQ=; h=From:Date:Subject:To:From; b=o9L/ESS0k1EjMroqQl7fhssfLDDCl3cqdvToi9QYL8UHFUI+9IxLYLQGUmrdWq9fl tpMiZ0x5vtJ3Y90LYShzhGyi7Jm1aBhmit6oU7VoIVbr/0uKP9GB9CYygsCa0tdyZF LU6qrjwB7mLTyFCS0JS2XhgUCSXK7grYeEew/fU8= Received: by mail-wr1-f45.google.com with SMTP id s12so4325628wrw.11 for ; Fri, 25 Sep 2020 09:55:12 -0700 (PDT) X-Gm-Message-State: AOAM530AxINxjg1zZlVN93WK29FZTjMFMIYYy5QRuvh47AlCzSbERwFw oOMaL9BYZldFtFlAHMg/aIIbjwDQ7stkeYp1MZirDw== X-Received: by 2002:a05:6000:11c5:: with SMTP id i5mr5561345wrx.18.1601052911367; Fri, 25 Sep 2020 09:55:11 -0700 (PDT) MIME-Version: 1.0 From: Andy Lutomirski Date: Fri, 25 Sep 2020 09:55:00 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Can we credibly make vdso_sgx_enter_enclave() pleasant to use? To: Borislav Petkov , Jethro Beekman , Jarkko Sakkinen , "Christopherson, Sean J" , Dave Hansen , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org vdso_sgx_enter_enclave() sucks. I don't think anyone seriously likes it, but maybe it's the best we can do. I'm wondering if it's worth trying to do better. Here's what I'd like if I could wave a magic wand: struct sgx_enclave_run { __u64 tcs; __u32 flags; __u32 exit_reason; /* * These values are exposed to the enclave on entry, and the values * left behind by the enclave are returned here. * Some enclaves might write to memory pointed to by rsp. */ __u64 rsp, rbp, r8, r9, r10, r11, r12, r13, r14, r15; /* Maybe other regs too? */ union { struct sgx_enclave_exception exception; /* Pad the entire struct to 256 bytes. */ __u8 pad[256 - 32]; }; }; long vdso_sgx_enter_enclave(unsigned int leaf, struct sgx_enclave_run *r); No callback, no asm wrapper needed, no nastiness from the perspective of the caller. So here are my questions. First, do people agree with me that this would be better? Second, could this be implemented in a way that doesn't utterly suck? The best I've come up with so far is abusing WRFSBASE to shove a little data structure containing the real user RSP or RBP along with the old FSBASE into FSBASE, do EENTER, and then undo the FSBASE dance. We'd also need some additional exception fixup magic to prevent a signal or ptrace() from observing the intermediate states and getting extremely confused. --Andy