Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4742641ybi; Mon, 3 Jun 2019 16:50:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmpgwZ2prSmu62/b5jtqD7J5VthdBYRR9J+HioZeOcu+9pWmw/OhGkEIe5EXZKU71N16uz X-Received: by 2002:a63:5457:: with SMTP id e23mr6276852pgm.307.1559605840111; Mon, 03 Jun 2019 16:50:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559605840; cv=none; d=google.com; s=arc-20160816; b=ouMWLeX9gt4JlI9oHKj7EKGRz5q3yu6w7+hzp90Z3PZX5/r2qn1kjCDgG3rbU5Kq8R E6e2Pti6bOW9n78aJhZUG1MhXmsInYVn7k7dc5psFLdi/BI0yOVSFGgmMvsp9qRpBlLu hmtHEBTFAQFI0OW+00Hbc2SKB+F5dxOAi2U71hG22aA4MtpBOUIE6Hmdq07SN8dvc1O+ ySYYDkcxwqFKZs59a05gFBbyp3bC1AhY6cESHQAJot6DSUOIOE4qkU3FjxznaS8clfwz 9aNiB7BwkQPbYKUZvKfQrS6QDfUZfAaaT8k+vHeqIStMQABczj8LceRcmx/9f52ovueS kJwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=jdzFg6VNP/5Av5PbMuh5Lictz5x4RL4od64M/QptHAw=; b=ygywjAeDhck28xcozFWUVrBaK47jat++JcrfXYNhc/lCPOmuaACktitPfAf8ZCdAx1 Sk+SuxkfYvRI+jFw82jJd/upRnR00NTmvksHUP0xdHWu70RdnScsdvTXERYRfwJNw8Sr 9fXbsbi1PRBcEUnc+sfISqq27wYnFPkVLGwBeW7FFb4LJr/ZmkuXr8jQuNj9Sg5eN83i tQ1AaMqMNqGoJJd79VdfDCe+FMx0l3epeYIDCtg5hoZcsqwx2Pc4ctKyIlZfO+cECdBY hDxiK82TQrCr0uzU4NRrx/KCrvywr27zETN9/vp4pIBDKMOJo2TPc3gPtEE6IarPIFW3 QGKA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a65si19379680pfb.204.2019.06.03.16.50.23; Mon, 03 Jun 2019 16:50:40 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726477AbfFCXsu convert rfc822-to-8bit (ORCPT + 99 others); Mon, 3 Jun 2019 19:48:50 -0400 Received: from mga03.intel.com ([134.134.136.65]:45303 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726101AbfFCXsu (ORCPT ); Mon, 3 Jun 2019 19:48:50 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2019 16:48:49 -0700 X-ExtLoop1: 1 Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 03 Jun 2019 16:48:48 -0700 Received: from orsmsx125.amr.corp.intel.com (10.22.240.125) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 3 Jun 2019 16:48:48 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.165]) by ORSMSX125.amr.corp.intel.com ([169.254.3.172]) with mapi id 14.03.0415.000; Mon, 3 Jun 2019 16:48:47 -0700 From: "Xing, Cedric" To: "Christopherson, Sean J" , "Hansen, Dave" CC: Jarkko Sakkinen , Andy Lutomirski , Stephen Smalley , James Morris , "Serge E . Hallyn" , LSM List , Paul Moore , Eric Paris , "selinux@vger.kernel.org" , Jethro Beekman , "Thomas Gleixner" , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , "Andy Shevchenko" , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes , "Roberts, William C" , "Tricca, Philip B" Subject: RE: [RFC PATCH 3/9] x86/sgx: Allow userspace to add multiple pages in single ioctl() Thread-Topic: [RFC PATCH 3/9] x86/sgx: Allow userspace to add multiple pages in single ioctl() Thread-Index: AQHVGAki7TYpY4ZsUk+m4jTej+khLaaK1z+AgAAGRQD//79uoA== Date: Mon, 3 Jun 2019 23:48:47 +0000 Message-ID: <960B34DE67B9E140824F1DCDEC400C0F654ED499@ORSMSX116.amr.corp.intel.com> References: <20190531233159.30992-1-sean.j.christopherson@intel.com> <20190531233159.30992-4-sean.j.christopherson@intel.com> <20190603203712.GI13384@linux.intel.com> In-Reply-To: <20190603203712.GI13384@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTAxNjYzMWQtZDY5OC00ZWI3LTk2OWEtOWJkZjNiZTQyOWEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTUg1cmMzcysxSFhSSFhEb1Z5MGpja250Qzk1SnhVakRIOTFySFNaNXlkQUdaWVh0SmNSNEZMNHZGT3JrdnRubiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Christopherson, Sean J > Sent: Monday, June 03, 2019 1:37 PM > To: Hansen, Dave > Cc: Jarkko Sakkinen ; Andy Lutomirski > ; Xing, Cedric ; Stephen Smalley > ; James Morris ; Serge E . Hallyn > ; LSM List ; > Paul Moore ; Eric Paris ; > selinux@vger.kernel.org; Jethro Beekman ; Thomas > Gleixner ; Linus Torvalds foundation.org>; LKML ; X86 ML > ; linux-sgx@vger.kernel.org; Andrew Morton foundation.org>; nhorman@redhat.com; npmccallum@redhat.com; Ayoun, Serge > ; Katz-zamir, Shay ; > Huang, Haitao ; Andy Shevchenko > ; Svahn, Kai ; > Borislav Petkov ; Josh Triplett ; > Huang, Kai ; David Rientjes ; > Roberts, William C ; Tricca, Philip B > > Subject: Re: [RFC PATCH 3/9] x86/sgx: Allow userspace to add multiple > pages in single ioctl() > > On Mon, Jun 03, 2019 at 01:14:45PM -0700, Dave Hansen wrote: > > On 5/31/19 4:31 PM, Sean Christopherson wrote: > > > -struct sgx_enclave_add_page { > > > +struct sgx_enclave_add_pages { > > > __u64 addr; > > > __u64 src; > > > __u64 secinfo; > > > + __u32 nr_pages; > > > __u16 mrmask; > > > } __attribute__((__packed__)); > > > > IMNHO this follows a user interface anti-pattern: exposing page sizes > > where not strictly required. > > > > Think of how this would look to an application if page size was > > variable. With this interface, they always need to scale their > > operations by page size instead of just aligning it. > > I briefly considered taking size in bytes, but I took a shortcut because > EPC pages are architecturally defined to be 4k sized and aligned. That > being said, I don't necessarily disagree, especially if nr_pages isn't > squeezed into a u32. > > > BTW, why is nr_pages a u32? Do we never envision a case where you can > > add more than 4TB of memory to an enclave? ;) > > Heh, fair enough. IIRC, a while back someone posted about having > problems building a 512gb enclave in a 92mb EPC... > > How about this for the intermediate patch: > > struct sgx_enclave_add_region { > __u64 addr; > __u64 src; > __u64 size; > __u64 secinfo; > __u16 mrmask; > __u16 reserved16; > __u32 reserved; > } > > and with the flags field: > > struct sgx_enclave_add_region { > __u64 addr; > __u64 src; > __u64 size; > __u64 secinfo; > __u16 mrmask; > __u16 flags; What is "flags" here? > __u32 reserved; > }