Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1520611pxb; Thu, 14 Apr 2022 07:56:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwX29Y2vC1S4g/aSkME8DxYIRUdwXd5mYI0ytRiCY35ryfcKIGEwjYmPo2F9fYtG5fccput X-Received: by 2002:a05:6402:3690:b0:41d:79b5:5979 with SMTP id ej16-20020a056402369000b0041d79b55979mr3457668edb.309.1649948216200; Thu, 14 Apr 2022 07:56:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649948216; cv=none; d=google.com; s=arc-20160816; b=RNs51EfKUSjYuVdJdrQBUBzOnJt3daKcTF1104kYsYYmbUbAsr/AYmbV33QwQ77DoN RWjhRd/cVcprUzsPiD29Fe1UxM91sbHF4CsXmz822OJ6Y3GWHAxpBHeO//R3gS76BKgM jbL4oI3miPL3RaeziBu6cCTRw+OAvt62Ux3E1lPMXzCJrD5nvu1IDJHd83377wzV3d0g QpikxPUV2syQq5J8hN8CEpN1iXlSHpYPE1LBXNVkkry7kHlKlMkiz7PfUQ9SpfaeaCJe 7gX3UHVxd6fCLZMs0O+6+YozHHyISccDwpOVaCuexg4AGA+eZd0XudQoZkYTpt10xlth cFPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=pnGQhzqbaHX9h0fFVuGJBAidjkvp56S+0QgidweN4VU=; b=KWUNf6YvzISsP9wR/cWgV9WQmwAx6U5RKk2cOZpoqyR/W+YenK6FvYnSEOQxYa25/J S7UZVQtLdqXHhzP0m2rkbq40yfxjtAI72WZSvbZktOKdgiSkeapx1FQn9iWPPUbi+JaJ 51OM7MBI+uGdGS03Grg6ZAO0qz8xFsCJ7zLr/bGHATq4Hc3zOivQOtGJU986bFotWFSW ECGLVtPCAUNa9XKbtTZ99oVGoOHKfcNy8KVVQu/JnLRLoGE3G1qE65lycBH82QA2fWhh yQbET0DxWsMNEkgMYhKoY1F6OJYIycN8nK8xwN+UWObBClsA0GDOv3B+/H5OqOoyuzNI tp/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Cr7xtMr7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f8-20020a056402354800b00421aa8b312csi348956edd.217.2022.04.14.07.56.31; Thu, 14 Apr 2022 07:56:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Cr7xtMr7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239035AbiDMVO4 (ORCPT + 99 others); Wed, 13 Apr 2022 17:14:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239032AbiDMVNK (ORCPT ); Wed, 13 Apr 2022 17:13:10 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD82344A33; Wed, 13 Apr 2022 14:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649884247; x=1681420247; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TtQBkc71W/eE9bza27771JItHGMI7ZHCR/obhz2nAK0=; b=Cr7xtMr76CVXDf1v69X7XjR6DImUkVj1yV16N+OC13sYeUcE08xgZ1ND MdNrAPPUyVNd6bPrj9wlt4CCrGr3DBEgIN1JhT/2e99JJy9Q09dhURNZp YRybhxJLwHkdAVK9T8xHMOxKqHyfTwbyWrpaDwNH5JpS8SiNWeeAnjPXN ff7fPlR8X4t+O7o7rAcSW9VNUMBotB1M39jkeK6yvclzLi9WkskQ8xAE7 60THUbJq2fMu6qqr4XfExlbwnaGB8JvUIwCy02jYz++vCx6OlmY0o0+QJ dyruq7/XDPlaPQHvlXilpDWRMSqeKV0sPEuFba+m+KaRKVWXa6SMlSnCf A==; X-IronPort-AV: E=McAfee;i="6400,9594,10316"; a="323219039" X-IronPort-AV: E=Sophos;i="5.90,257,1643702400"; d="scan'208";a="323219039" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2022 14:10:44 -0700 X-IronPort-AV: E=Sophos;i="5.90,257,1643702400"; d="scan'208";a="725054290" Received: from rchatre-ws.ostc.intel.com ([10.54.69.144]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2022 14:10:44 -0700 From: Reinette Chatre To: dave.hansen@linux.intel.com, jarkko@kernel.org, tglx@linutronix.de, bp@alien8.de, luto@kernel.org, mingo@redhat.com, linux-sgx@vger.kernel.org, x86@kernel.org, shuah@kernel.org, linux-kselftest@vger.kernel.org Cc: seanjc@google.com, kai.huang@intel.com, cathy.zhang@intel.com, cedric.xing@intel.com, haitao.huang@intel.com, mark.shanahan@intel.com, vijay.dhanraj@intel.com, hpa@zytor.com, linux-kernel@vger.kernel.org Subject: [PATCH V4 17/31] x86/sgx: Tighten accessible memory range after enclave initialization Date: Wed, 13 Apr 2022 14:10:17 -0700 Message-Id: <1eaa05cc46a09728036060b209deb2cf0351eb62.1649878359.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org Before an enclave is initialized the enclave's memory range is unknown. The enclave's memory range is learned at the time it is created via the SGX_IOC_ENCLAVE_CREATE ioctl() where the provided memory range is obtained from an earlier mmap() of /dev/sgx_enclave. After an enclave is initialized its memory can be mapped into user space (mmap()) from where it can be entered at its defined entry points. With the enclave's memory range known after it is initialized there is no reason why it should be possible to map memory outside this range. Lock down access to the initialized enclave's memory range by denying any attempt to map memory outside its memory range. Locking down the memory range also makes adding pages to an initialized enclave more efficient. Pages are added to an initialized enclave by accessing memory that belongs to the enclave's memory range but not yet backed by an enclave page. If it is possible for user space to map memory that does not form part of the enclave then an access to this memory would eventually fail. Failures range from a prompt general protection fault if the access was an ENCLU[EACCEPT] from within the enclave, or a page fault via the vDSO if it was another access from within the enclave, or a SIGBUS (also resulting from a page fault) if the access was from outside the enclave. Disallowing invalid memory to be mapped in the first place avoids preventable failures. Reviewed-by: Jarkko Sakkinen Signed-off-by: Reinette Chatre --- Changes since V3: - Add Jarkko's Reviewed-by tag. Changes since V1: - Add comment (Jarkko). arch/x86/kernel/cpu/sgx/encl.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c index 7ccda6fe1f8f..11f97fdcac1e 100644 --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -402,6 +402,11 @@ int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start, XA_STATE(xas, &encl->page_array, PFN_DOWN(start)); + /* Disallow mapping outside enclave's address range. */ + if (test_bit(SGX_ENCL_INITIALIZED, &encl->flags) && + (start < encl->base || end > encl->base + encl->size)) + return -EACCES; + /* * Disallow READ_IMPLIES_EXEC tasks as their VMA permissions might * conflict with the enclave page permissions. -- 2.25.1