Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp30808imm; Tue, 3 Jul 2018 13:17:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcQOa+5Az2x3MHOqFDpDuU2YD5enwH2LAZjGhIIPdh+K6ntT6PPnrpZ+iQUxHLJ0IhL3XpQ X-Received: by 2002:a65:60cf:: with SMTP id r15-v6mr18380472pgv.41.1530649063855; Tue, 03 Jul 2018 13:17:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530649063; cv=none; d=google.com; s=arc-20160816; b=LocErrna6RBer1DPSwf4OvL1Dygqt89MZJ8axqsv7QAl6sh5ynHuxR2Od1YBzUMmkL sCrLTQMPTAXWf39wkA3YELpO5G0J3wVIHwehWbY0e/X6uB3dgvLnZJ18Zz4nZVr41Squ 4n53RAq4rMKxF5QyDC7+UEgBsYGnpOKxq6Pf/uwcbYntHeBwx/slymgibh3Lx+qr56Lu GjmP1K1jylbv01IyebP5Qzcv2ztgKG2Ukauc0fH3AiTJhHyTP+V4SbK6woT6uKRfjnfW MyUjs1X+WoRxXFgRynU620oDijdOcLyNqzrEI+Xvzwy03xXCP4rsZLRIbFRgtkVLJSaH V9Xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=JQQsyDuYqq2o99auMF2xRWjiEfpdiffoKrB992zbTec=; b=YdhRJ/3hY+1sT+9lvOM76Tc/4l/IL7ey58DuVblWujbpsrciMguXvd6EQsnkUYYgYm 0gWeZUADtoaiZufPNVTCLRQOYW7EZi9xomUwYCi7ID2xKJ3sd127eCZ058gTp+H428Eo lrD8m7f0LhzGhrxI+10GK+InZ1h9+o/NLRLmPjvT2qRlEqN+K/25CS5EkR72vFhs8cWP DtHRSQV5xtjCDMMZZdctTJBMV9IIDlz92oCQKJvTiS2GINXr45pArDkRB9LC4mXWWaPO LMFV97jc29HVzK4tw83toVDak+FYqPcZymAQCQz+FKKcSzd1cdIj0S2sFDkve/KGb6zQ WW5Q== 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 x19-v6si1401638pgl.660.2018.07.03.13.17.26; Tue, 03 Jul 2018 13:17:43 -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 S1752664AbeGCUQY (ORCPT + 99 others); Tue, 3 Jul 2018 16:16:24 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:45383 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751950AbeGCUQX (ORCPT ); Tue, 3 Jul 2018 16:16:23 -0400 Received: from p4fea482e.dip0.t-ipconnect.de ([79.234.72.46] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1faRif-0002B4-FZ; Tue, 03 Jul 2018 22:16:13 +0200 Date: Tue, 3 Jul 2018 22:16:12 +0200 (CEST) From: Thomas Gleixner To: Jarkko Sakkinen cc: x86@kernel.org, platform-driver-x86@vger.kernel.org, dave.hansen@intel.com, sean.j.christopherson@intel.com, nhorman@redhat.com, npmccallum@redhat.com, linux-sgx@vger.kernel.org, Ingo Molnar , "H. Peter Anvin" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [PATCH v12 08/13] x86/sgx: wrappers for ENCLS opcode leaf functions In-Reply-To: <20180703182118.15024-9-jarkko.sakkinen@linux.intel.com> Message-ID: References: <20180703182118.15024-1-jarkko.sakkinen@linux.intel.com> <20180703182118.15024-9-jarkko.sakkinen@linux.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 Jul 2018, Jarkko Sakkinen wrote: > This commit adds wrappers for Intel(R) SGX ENCLS opcode leaf functions Add... > except for ENCLS(EINIT). The ENCLS instruction invokes the privileged > functions for managing (creation, initialization and swapping) and > debugging enclaves. > > +#define IS_ENCLS_FAULT(r) ((r) & 0xffff0000) > +#define ENCLS_FAULT_VECTOR(r) ((r) >> 16) > + > +#define ENCLS_TO_ERR(r) (IS_ENCLS_FAULT(r) ? -EFAULT : \ > + (r) == SGX_UNMASKED_EVENT ? -EINTR : \ > + (r) == SGX_MAC_COMPARE_FAIL ? -EIO : \ > + (r) == SGX_ENTRYEPOCH_LOCKED ? -EBUSY : -EPERM) Inlines please along with proper comments. > +#define __encls_ret_N(rax, inputs...) \ > + ({ \ > + int ret; \ > + asm volatile( \ > + "1: .byte 0x0f, 0x01, 0xcf;\n\t" \ > + "2:\n" \ > + ".section .fixup,\"ax\"\n" \ > + "3: shll $16,%%eax\n" \ SHLL ??? _All_ the macro maze needs proper comments. > + " jmp 2b\n" \ > + ".previous\n" \ > + _ASM_EXTABLE_FAULT(1b, 3b) \ > + : "=a"(ret) \ > + : "a"(rax), inputs \ > + : "memory"); \ > + ret; \ > + }) .... > +static inline int __emodt(struct sgx_secinfo *secinfo, void *epc) > +{ > + return __encls_ret_2(EMODT, secinfo, epc); > +} > + > #define SGX_MAX_EPC_BANKS 8 > > #define SGX_EPC_BANK(epc_page) \ > @@ -39,4 +190,29 @@ extern bool sgx_lc_enabled; > void *sgx_get_page(struct sgx_epc_page *ptr); > void sgx_put_page(void *epc_page_ptr); > +#define SGX_FN(name, params...) \ > +{ \ > + void *epc; \ > + int ret; \ > + epc = sgx_get_page(epc_page); \ > + ret = __##name(params); \ > + sgx_put_page(epc); \ This whole get/put magic is totally pointless. The stuff is 64bit only, so all it needs is the address, because 'put' is a noop on 64bit. > + return ret; \ > +} > + > +#define BUILD_SGX_FN(fn, name) \ > +static inline int fn(struct sgx_epc_page *epc_page) \ > + SGX_FN(name, epc) > +BUILD_SGX_FN(sgx_eremove, eremove) > +BUILD_SGX_FN(sgx_eblock, eblock) > +BUILD_SGX_FN(sgx_etrack, etrack) > +BUILD_SGX_FN(sgx_epa, epa) > + > +static inline int sgx_emodpr(struct sgx_secinfo *secinfo, > + struct sgx_epc_page *epc_page) > + SGX_FN(emodpr, secinfo, epc) > +static inline int sgx_emodt(struct sgx_secinfo *secinfo, > + struct sgx_epc_page *epc_page) > + SGX_FN(emodt, secinfo, epc) Bah this is really unreadable crap. What's so horribly wrong with writing this simply as: static inline int sgx_eremove(struct sgx_epc_page *epc_page) { return __encls_ret_1(EREMOVE, epc_page_addr(epc_page)); } static inline int sgx_emodt(struct sgx_secinfo *secinfo, struct sgx_epc_page *epc_page) { return __encls_ret_2(EREMOVE, secinfo, epc_page_addr(epc_page)); } instead of all these completely pointless meta functions and build macro maze around it. Why? Because then every function which is actually used in code has a proper prototype instead of nongrepable magic and a gazillion of wrappers. Thanks, tglx