Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5847235ybi; Tue, 4 Jun 2019 13:21:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqwy/gXYW5/xOmWg9GFEoIrqknmXTgruiMFFYjdgy9S3lBKvvVUtnzFvuHDXouWzq5rNNHJc X-Received: by 2002:a17:902:aa83:: with SMTP id d3mr17101038plr.74.1559679708279; Tue, 04 Jun 2019 13:21:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559679708; cv=none; d=google.com; s=arc-20160816; b=M88pe1fHlEZU4PQhZ9dhPCGppuyeyziJiJ8DwZmEBllRfxoNtQuOldDKYR6ju75T+4 iXBoCL/mACNQQmHjlj0vM6hLnLBkcH/cp2OgVZjcsd1/EpRVdwq/A7rdIpIoLPFz+Fr2 9wKtCQP3vAQEf+tgJYCK16G6VWe2oiPkaykGNHZ1kbFmVCH/wU2s+FpUhMrsyhn1g5jB Y+08UGch0RJ0Qn4vwAOJAlvvnIUJrUCVMGQ/qe9oyBJkAGozcyxX0oFb6CAjxjxaB0CH K37BRPqPAoWpxuvzFnYsV3teh1mOEXc4RsPJ58avIBVCfNIufjkLYpB+QY8r+WAANPTB G9BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=apPt93EDXv6zhNdTe+agCl50OB492qOviU2F748tUhM=; b=sB983hC8e3wiaholWR8l8vH5c3QDlZGME9XOa23xIAHgRNsJ/SWKW6AQjyih+tWoPo Xjst2QA72XOW7chwjx8X79wqEW8AgPTzbOaE47JpbGZCQD5/+VfXTZwbDIqMnF9c3P94 BTVck7ed+l6UX7GOJpQcYIwJ0sAkZ4WgNv8C4FDTPi4zFGXcCPKN6OKPAc2hIXMkNfgu p9YdH2ZRemM5l12Oreaw9TUtxu5fvRaSH8VgmDx38P86fDY2GRmgnhcITCxUe8MYCOfc ty86TAzKflHe67xa5Uc1ddHn03bQt9Ro2xPed/G6ht80NpwvBcFLFZ32i7I4LybqmtfH wsnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rbONcUbd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3si23337732pfp.288.2019.06.04.13.21.29; Tue, 04 Jun 2019 13:21:48 -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; dkim=pass header.i=@kernel.org header.s=default header.b=rbONcUbd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726668AbfFDUS3 (ORCPT + 99 others); Tue, 4 Jun 2019 16:18:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:53104 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726488AbfFDUS2 (ORCPT ); Tue, 4 Jun 2019 16:18:28 -0400 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 F40AC20B7C for ; Tue, 4 Jun 2019 20:18:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559679507; bh=iG0LtosQD92m9TTWN5JRMbddz/rPfUkoOrLnFTnZQOQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rbONcUbdged+eCYwiMBzEgIiISkpCCnOqZ/4M19YbzaRTOQKMWsCBAxo5+IxafmlK 34t68z4pDP29OChTaaouHHy6Tiwq2L9QIUePzd+ewplo2OOiZ67f3wAfD1vyAlek/3 rK7nBAoWHn927V1BRXLPKPfNrMiub2NxnMrBaFLk= Received: by mail-wr1-f54.google.com with SMTP id e16so8916841wrn.1 for ; Tue, 04 Jun 2019 13:18:26 -0700 (PDT) X-Gm-Message-State: APjAAAXAZZNYs/nE2rcnXvfEI/7HHTZyEn7QgxqiFVpZky1xJYAXhU2J yiIbQJFY20K/2Ppb9i87gfb6ugurYAyLhyWwL3KKcA== X-Received: by 2002:adf:cc85:: with SMTP id p5mr7455664wrj.47.1559679505381; Tue, 04 Jun 2019 13:18:25 -0700 (PDT) MIME-Version: 1.0 References: <20190531233159.30992-1-sean.j.christopherson@intel.com> <20190531233159.30992-4-sean.j.christopherson@intel.com> <960B34DE67B9E140824F1DCDEC400C0F654ECBBD@ORSMSX116.amr.corp.intel.com> <20190603200804.GG13384@linux.intel.com> <20190603203950.GJ13384@linux.intel.com> In-Reply-To: <20190603203950.GJ13384@linux.intel.com> From: Andy Lutomirski Date: Tue, 4 Jun 2019 13:18:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 3/9] x86/sgx: Allow userspace to add multiple pages in single ioctl() To: Sean Christopherson Cc: "Xing, Cedric" , Jarkko Sakkinen , Andy Lutomirski , Stephen Smalley , James Morris , "Serge E . Hallyn" , LSM List , Paul Moore , Eric Paris , "selinux@vger.kernel.org" , Jethro Beekman , "Hansen, Dave" , 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 3, 2019 at 1:39 PM Sean Christopherson wrote: > > On Mon, Jun 03, 2019 at 01:08:04PM -0700, Sean Christopherson wrote: > > On Sun, Jun 02, 2019 at 11:26:09PM -0700, Xing, Cedric wrote: > > > > From: Christopherson, Sean J > > > > Sent: Friday, May 31, 2019 4:32 PM > > > > > > > > +/** > > > > + * sgx_ioc_enclave_add_pages - handler for %SGX_IOC_ENCLAVE_ADD_PAGES > > > > + * > > > > + * @filep: open file to /dev/sgx > > > > + * @cmd: the command value > > > > + * @arg: pointer to an &sgx_enclave_add_page instance > > > > + * > > > > + * Add a range of pages to an uninitialized enclave (EADD), and > > > > +optionally > > > > + * extend the enclave's measurement with the contents of the page (EEXTEND). > > > > + * The range of pages must be virtually contiguous. The SECINFO and > > > > + * measurement maskare applied to all pages, i.e. pages with different > > > > + * properties must be added in separate calls. > > > > + * > > > > + * EADD and EEXTEND are done asynchronously via worker threads. A > > > > +successful > > > > + * sgx_ioc_enclave_add_page() only indicates the pages have been added > > > > +to the > > > > + * work queue, it does not guarantee adding the pages to the enclave > > > > +will > > > > + * succeed. > > > > + * > > > > + * Return: > > > > + * 0 on success, > > > > + * -errno otherwise > > > > + */ > > > > +static long sgx_ioc_enclave_add_pages(struct file *filep, unsigned int cmd, > > > > + unsigned long arg) > > > > +{ > > > > + struct sgx_enclave_add_pages *addp = (void *)arg; > > > > + struct sgx_encl *encl = filep->private_data; > > > > + struct sgx_secinfo secinfo; > > > > + unsigned int i; > > > > + int ret; > > > > + > > > > + if (copy_from_user(&secinfo, (void __user *)addp->secinfo, > > > > + sizeof(secinfo))) > > > > + return -EFAULT; > > > > + > > > > + for (i = 0, ret = 0; i < addp->nr_pages && !ret; i++) { > > > > + if (signal_pending(current)) > > > > + return -ERESTARTSYS; > > > > > > If interrupted, how would user mode code know how many pages have been EADD'ed? > > > > Hmm, updating nr_pages would be fairly simple and shouldn't confuse > > userspace, e.g. as opposed to overloading the return value. > > Or maybe update @addr and @src as well? That would allow userspace to > re-invoke the ioctl() without having to modify the struct. If you're going to use -ERESTARTSYS, that's the way to go. -EINTR would be an alternative. A benefit of -ERESTARTSYS is that, with -EINTR, it wouldn't be that surprising for user code to simply fail to handle it.