Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <684930a2-a247-7d5e-90e8-6e80db618c4c@intel.com>
Date:   Fri, 4 Mar 2022 11:09:36 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.6.1
Subject: Re: [PATCH v3] x86/sgx: Do not limit EAUG'd pages by
 pre-initialization policy
Content-Language: en-US
To:     Jarkko Sakkinen <jarkko@kernel.org>, <linux-sgx@vger.kernel.org>
CC:     Nathaniel McCallum <nathaniel@profian.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@vger.kernel.org>
References: <20220304033918.361495-1-jarkko@kernel.org>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20220304033918.361495-1-jarkko@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MXR0MG1qKy92WWZadVQ5eTRLTTg1M3hYN3hNU3ZVaFd6Ti9rSUwrcEM1ZFh4?=
 =?utf-8?B?RE5DOXR6NTZnOVgwYm9yZXJTSzNYR0FKNXNtUnRSMXB2UWtpR0VGNHg1UHIx?=
 =?utf-8?B?aVJ3U0pOT282cWwvbFgraHBZVzhWTk5OOFFuTWhtSlRrZURCNW1RRkZsVlNY?=
 =?utf-8?B?clFaNlFXT3E2dEhtaVppc3diQkQ3Kzk2eTJrNWZQYjltYWw3K3hGRkhoVlBX?=
 =?utf-8?B?S1lwQndkS2hXSUpnaFVqRVg3ckRIUGFOZThiYkJ6SWh4RDN5emQ1RDBUTjJC?=
 =?utf-8?B?VmhVOW1hYVhDYTJnQmE3SThmamU4QWtjc3dwbUthM3gzSnF3TmorR01zVVlB?=
 =?utf-8?B?czNuVDd4RUpCdXN3K2R6TndqWWpSVGpGd0s1cEwwV3VnTnhpRDc3Q1VCNEZI?=
 =?utf-8?B?d3l1dHpjTC9CYVFWb3E2QWQzMGV0czZXQ1BQdkpocDRNbkZhRTl6YzIzRU5E?=
 =?utf-8?B?WXdqWGtTSlVvQjBvZE1SbVYyOFdrQkREY2pCVlNGeURQUXVVampUMlVUY3c1?=
 =?utf-8?B?SkdXdEJlWXZNUXFZbGdHdEJWa1dRTjBtajhCRGpHNHByblJCaENkeHMxT09V?=
 =?utf-8?B?SGd2TTlnMnR3N1R2QnNRTHlrckFXRlYwRlVNTEljT0N4Y3RGSlNaTmR4TjVS?=
 =?utf-8?B?T3VZMW5GcVpJeWIvRTdPN3hKZkd1eS9Ud1ZXdGN6em5TTkkwSXRDdCtCTnZ6?=
 =?utf-8?B?aUgxWXhuRzFiWGl0eDNTUm5QKzNBK2JaekN2NW5hOFg1dDFJWDBUZjNacWNS?=
 =?utf-8?B?L0F4UGZWeDVWa3ZFb0FmeUZyUFVEYkdCNC9XeFhKOEFtQWVRcWgyaTRveEpy?=
 =?utf-8?B?YkR2VmtkRmNrK2hTb3hQNFQ5RFUwWTlqTzFvV3RXb2lhL3VGZEFneWl6bkcr?=
 =?utf-8?B?dXZtRnMxTlhzcVlDR1U2eVozVVFJaC9TOW10eW9YVUNZT2dxcTJOcWxZZ084?=
 =?utf-8?B?cFAwaG1TL3Vha0tsejlsaXRQTlpLUFRxZTljMVpCS2trRlpuaEhZR2EybE9i?=
 =?utf-8?B?RWlOZ0RQL2lNYmtZbzdKQVJUNldCem9GcmwrMElEdUxnd3dodWsvZlg3ZTdz?=
 =?utf-8?B?ZUFCNkcrSEY2eHhwZlN2U2p6dENtVVhseVdHUXByYi9OeWlyZzBZVWsrdmtL?=
 =?utf-8?B?dml4QyswNWZWTW9WVkpKYVNpU3FNWkxBRDU0dEJVcmw3VndSUS9hRmFEcmdq?=
 =?utf-8?B?YitqYVRCQjdDS1FrZVViZ2VTOVVWOXNSRXByc3BQN0h0TS9CdjhJTGNBY2cr?=
 =?utf-8?B?dGx1VTliWTJDOTQxY0xBNkVLQWYyN1JDMWgyNUJTNlUxMEZBMUJYb2ZwTmpj?=
 =?utf-8?B?T3pSRU1pWnZ3Si85NE05ZFkrZjR6aGpUQzkyeGhzOENKTUgxd2sxcVhLUldp?=
 =?utf-8?B?emlnTFU5alBYdEFsV20wMFdGTjhIc1VidlpSdUNsY3RuZXhXQ1JkcXFiQ0pM?=
 =?utf-8?B?YzdMeDNyUWJpUk5sM295WjVTRXV2c0tjYjlaRFJXYTVqK2JPR2M4eU9RVGlT?=
 =?utf-8?B?b1NwaXR5R0N5YUdkOWpRR05CRmdwcHZ2T3ZKS2RiMFNEWmJtQS9mcHhzZVkw?=
 =?utf-8?B?MjM3bnRFQ2FzaktwcExwTjlGVlhITEs2Z0grVVlsNytVWGJwbGpoTm83c25G?=
 =?utf-8?B?TU9PYXNiZGRkclJkblRuemd4T0RCUk9xb3VkYXdDZzhZRUMvYWNpS3R6d0Rq?=
 =?utf-8?B?T1dVZWNBWUNURStvTGJKcnI3VGJ2RGFmNDNpbnQyQ1pTYm1BN29vVzdDd0NO?=
 =?utf-8?B?OWVHd1BvMWd6NnRsVS95ZWFGUi92SkVGb1hzSVRFbWJ1VGtDVC9TbUR3SmNC?=
 =?utf-8?B?RzA5ZEQ1N0ErYkw4Ym93dGxpQUZNYkZqZ2Q1Z3hZNFFRY28vdmZXSUxPSUF3?=
 =?utf-8?B?Y09wT3JkTEhrVHM2YytJcDBhajBXdmZMb2dZSVluZ3djYnp5c0ZYclpxWkNK?=
 =?utf-8?B?bXlJOXhWUFZucndya0Nyb3VvMFVrb08vUG5tb3RtQnQ3aGVpVExETEk2U0F6?=
 =?utf-8?B?KzdwMnAwdFpFUU1WeTU1aDRUaWxHdURRUlhJNmErVmVWdG1xN0grWnJtelZV?=
 =?utf-8?B?NUQrMkRRYVUrUkZZa1MwaEd0TEczRGhOZktPMXlnNVQ3VjU0WG5uWmxselM5?=
 =?utf-8?B?QVNMZC91aFdJNElFNVNCQlcyaDVPOUg1YVdFeFlSYXp5WUZhUDN1TXRHY0N3?=
 =?utf-8?B?M1EzM3l2dzBjemdIbng3aHBTc3Y3U3pzN0RhaC9ZejFrcEVDYVhCNzNsS2hr?=
 =?utf-8?Q?y1OcYWlrWZUIEsp7EQSv6ll4YQn/dQr0Ge7Wcq9k8c=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b5b3cab1-a46d-43cb-c556-08d9fe1288b5
X-MS-Exchange-CrossTenant-AuthSource: BN0PR11MB5744.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2022 19:09:40.9565
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: FqYaELlUYGg6ZE/uhDFaN/E6jQ2aBFBNwkbIDcvR0qDvocsj1xWgnyaSj0IM/knZqlF4cfSPpmfubpHe08xCCcMaptDuWVAJuNMPfnP7QkY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4011
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Jarkko,

On 3/3/2022 7:39 PM, Jarkko Sakkinen wrote:
> Pre-initialization policy is meant for EADD'd pages because they are
> part of the enclave identity. It's a good practice to not let touch the
> permissions after initialization, and does provide guarantees to e.g.
> LSM's about the enclave.

I disagree. There are scenarios where it is indeed good practice to
modify the permissions after initialization.  For example, pages that
may be used for relocatable code can start with RWX permissions but once
the pages have been populated with the code they should be able to restrict
permissions to RX only. It is not good practice to require RWX permission
over their entire lifetime. Ideally pages should only have the lowest
permissions possible. 

Supporting the modification of permissions after initialization enables
the security conscious enclave owner to support the security
principle of least privilege.

> 
> For EAUG'd pages it should be sufficient to let mmap(), mprotect() and
> SGX opcodes to control the permissions. Thus effectively disable
> pre-initialization policy by setting vm_max_prot_bits to RWX.

Setting vm_max_prot_bits of EAUG pages to RWX results in dynamically
added (RW) pages to allow RWX PTEs!

Please correct me if I am wrong but I do not see how mmap() and
mprotect() will control permissions here. Will these flows be able to
prevent a RWX mapping of dynamically added RW EPCM pages? From what
I understand SGX controls the permissions here with sgx_encl_may_map()
called during mmap() and mprotect() and it will allow such mappings
after this patch. RWX mapping (VMA) with RWX PTEs of RW EPCM memory
will be allowed, correct?

That means, an enclave using EAUG to expand its heap will have
enclave pages with RW EPCM but yet could have RWX PTEs pointing to
them after the user creates a RWX mmap().

From what I understand this circumvents the kernel's security mechanisms.

This also breaks one of the original rules of SGX as per:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/sgx.rst#n74

"EPCM permissions are separate from the normal page tables.  This prevents the
kernel from, for instance, allowing writes to data which an enclave wishes to
remain read-only."

In these changes the kernel allows all dynamically added pages to be
executable - even when the enclave wishes them not to be.

> Then, remove vm_run_prot_bits. For EADD'd pages the roof is where
> it was during construction, for EAUG'd we don't simply care. This
> hard to keep in-sync variable adds only a layer of complexity and
> nothing else.
> 
> Without vm_run_prot_bits existing, SGX_IOC_ENCLAVE_RELAX_PERMISSIONS
> does absolutely nothing. Therefore, it can be safely removed.

Removing vm_run_prot_bits cripples SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS.
With this removal SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS will support the
modification of EPCM permissions but PTE and VMA permissions will continue
to allow the maximum access possible for the page, whether the enclave page
supports the permission or not.

I find it risky to circumvent the kernel's security mechanisms and
I am not comfortable signing off on this. Or am I just not understanding it
correctly?

Reinette