Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5851414ybi; Tue, 4 Jun 2019 13:27:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqyKTKKE2bfPFSsrS9S576EMy2xeT0pn6TA314ClVADDoBY6XrqSANLF4UcBP/BjObiGpj+a X-Received: by 2002:a62:36c1:: with SMTP id d184mr41782919pfa.49.1559680038664; Tue, 04 Jun 2019 13:27:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559680038; cv=none; d=google.com; s=arc-20160816; b=o/0rKeNM6/QrUaOfB1Bj6vXvpv+iR18GR7aYHpU7CygIVUZaxJFh7prNmD/7ciwMRD MNWcWPGMtpZmmpybWp0QpSkagcCpwkGJaf7ydXVEuXNmxmq1obu9yFJJYRYOwbwPYrbR t2S3S9I8lUCXAhtm4sXQToib5AQI3jubVwAOtpFolKTV6FfgHma00MfGRI9D3tgzWl3q GOn5CfAx2bDw8GA5Vm3CprT2MzvTXen/mDexAAte6AtZEUhCqHJ8hKRNR69Y4gi8aPzE pQxi+dUZ86uHMMDlnKxxhu7fs6DWlw5SS0A17YIGihaAL7XdniN3ybGtcbQsROOQc9lG JkEw== 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=kDsdXWYU9tgJkeaA8jdlgeTc9uIaNoIeHdbLhJVxYRQ=; b=MD+GfaoV9+lgT6ehzT72qSXF5CHKVzRDVcOAWnhCQqHY67WIoPuSwKivQY/QjjVtpW KtPyz2jIUJmxEYQTIo/BaEVtPOJoeH0RMEOn1l/XNpeWIvsB0VaKiXq+e1aAz7O5OqlG 5KyWmS6veF4R+zPni1t3xJ73Pp+q46OFr6iY2HMHkfv/Yo2WGvw/JQDlyqROwpEafuPN o2rkwJLItJgQrChv9qI0KVoDvSHf92OuSXge7MSu2u1kLQB6hEDUS/Yzl30L0ad3YZtr YKi6949GtjuSD216gkAB0Cc5MtYLf6bBdKXaZAUizeUG85V7vJuPFr7nyouinfJoxnSm Cg+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RGzP2rSx; 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 e39si18751076plg.103.2019.06.04.13.27.01; Tue, 04 Jun 2019 13:27:18 -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=RGzP2rSx; 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 S1726541AbfFDUQS (ORCPT + 99 others); Tue, 4 Jun 2019 16:16:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:52246 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbfFDUQS (ORCPT ); Tue, 4 Jun 2019 16:16:18 -0400 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.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 468822133D for ; Tue, 4 Jun 2019 20:16:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559679377; bh=UUD8js2GAwr4II2RKampxullfYCdUCEzAhpMSNle0/Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RGzP2rSxHLkPNvO6s5zF9RmhMr7ron36rvZeXufXGabhAl0HSmZSVK6VEGGL94SxR JSGRwOIr5m3QWD+LmSqNETKHpFBN+ZXFxG9AvOUE4/QVjjDZ8s6FBraiWEYrwtUWL8 DezGQaioxI4qhrTSbuv0eYVn7NjF5biPe7ZXpPBo= Received: by mail-wm1-f54.google.com with SMTP id v19so31819wmj.5 for ; Tue, 04 Jun 2019 13:16:17 -0700 (PDT) X-Gm-Message-State: APjAAAXyKQR7jXQ7BK12iwkRnSuvMD1chz6n4L/5sn07oa0EiLFz6Lwt thNh5bCvkvBtDqPsETbRCo3N7fAF7cgUPuLYnnTHug== X-Received: by 2002:a1c:6242:: with SMTP id w63mr15836829wmb.161.1559679375566; Tue, 04 Jun 2019 13:16:15 -0700 (PDT) MIME-Version: 1.0 References: <20190531233159.30992-1-sean.j.christopherson@intel.com> <20190531233159.30992-3-sean.j.christopherson@intel.com> <20190604114951.GC30594@linux.intel.com> In-Reply-To: <20190604114951.GC30594@linux.intel.com> From: Andy Lutomirski Date: Tue, 4 Jun 2019 13:16:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 2/9] x86/sgx: Do not naturally align MAP_FIXED address To: Jarkko Sakkinen Cc: Sean Christopherson , Andy Lutomirski , Cedric Xing , Stephen Smalley , James Morris , "Serge E . Hallyn" , LSM List , Paul Moore , Eric Paris , selinux@vger.kernel.org, Jethro Beekman , Dave Hansen , Thomas Gleixner , Linus Torvalds , LKML , X86 ML , linux-sgx@vger.kernel.org, Andrew Morton , nhorman@redhat.com, npmccallum@redhat.com, Serge Ayoun , Shay Katz-zamir , Haitao Huang , Andy Shevchenko , Kai Svahn , Borislav Petkov , Josh Triplett , Kai Huang , David Rientjes , William Roberts , Philip Tricca 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 Tue, Jun 4, 2019 at 4:50 AM Jarkko Sakkinen wrote: > > On Fri, May 31, 2019 at 04:31:52PM -0700, Sean Christopherson wrote: > > SGX enclaves have an associated Enclave Linear Range (ELRANGE) that is > > tracked and enforced by the CPU using a base+mask approach, similar to > > how hardware range registers such as the variable MTRRs. As a result, > > the ELRANGE must be naturally sized and aligned. > > > > To reduce boilerplate code that would be needed in every userspace > > enclave loader, the SGX driver naturally aligns the mmap() address and > > also requires the range to be naturally sized. Unfortunately, SGX fails > > to grant a waiver to the MAP_FIXED case, e.g. incorrectly rejects mmap() > > if userspace is attempting to map a small slice of an existing enclave. > > > > Signed-off-by: Sean Christopherson > > Why you want to allow mmap() to be called multiple times? mmap() could > be allowed only once with PROT_NONE and denied afterwards. Is this for > sending fd to another process that would map already existing enclave? > > I don't see any checks for whether the is enclave underneath. Also, I > think that in all cases mmap() callback should allow only PROT_NONE > as permissions for clarity even if it could called multiple times. > What's the advantage to only allowing PROT_NONE? The idea here is to allow a PROT_NONE map followed by some replacemets that overlay it for the individual segments. Admittedly, mprotect() can do the same thing, but disallowing mmap() seems at least a bit surprising.