From patchwork Wed Sep 18 18:50:51 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Volodymyr Babchuk X-Patchwork-Id: 11151155 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id AB254197C for ; Wed, 18 Sep 2019 18:52:52 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8657F21A4C for ; Wed, 18 Sep 2019 18:52:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=epam.com header.i=@epam.com header.b="U+2nIVv5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8657F21A4C Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=epam.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAf2X-0006Ar-M8; Wed, 18 Sep 2019 18:50:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iAf2W-0006AX-AX for xen-devel@lists.xenproject.org; Wed, 18 Sep 2019 18:50:56 +0000 X-Inumbo-ID: 3d4d380a-da45-11e9-978d-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe0e::610]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3d4d380a-da45-11e9-978d-bc764e2007e4; Wed, 18 Sep 2019 18:50:53 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JMU04dRMAPlzKMH4aCsDTRY8I4tpVYPsFhD7AVURhKKoheCd+THzPpBxHCcjKLjdUMvJm38y9XC60V64ntzhCgJzM0jjF0iI6IeLR/47g+gVEup5v/4y+fcha8y518R0c407LFpI41j//4LraLC0QDVOVJE+N618jFNw4Cx7J0RFXdHpqbnR7ZM9utdMfco0MC5pnJ1gZSE2MOSuNPzL95QshtpPGMJcFOK7IDR7nDp9cTpZ14LqO+4FS2RjHazr7YryD+A5CvIGZempKgmNqjeKC4lBOp3scdeJQGNjLg/nkryJ7mPwmDk+Z5g8G/D/rw19oWZSTfVIEmRPsog22A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BO64aWIMKF8+kHI1j+d2aul1S4f+TxtzxSQwzpb1xk4=; b=Qu1L1tZHK7SR16Ky4ETs8a52dpEHbr2zCb/zqifmTPmuSXvwLeV0lX3CasXtiYwqz2R984jGOXhTiN4gFXS2RmwbrE6jtr56n1RLqdYAC8FvTnjaRNcCGVupHc9gsNmAXtkRMPV9ijtTEy8UN7TFYgyh76jaiuSfIpxRvE5eOsymSxRLg7DqTYZgcDRr9y9Ov+0E2Whp/YJg2SqdBTtIpNuw+K4XiE4fYYSibrRjfpKDRhF7ObhsgPVxYvv100LGKQyYT7eeRNFBVxyUr4pFbsweX6l073T0RFydpIFuCP7zZwmJfDi3bcq3ekTP4+F2BpsOWSb792oa5F4xfuLerg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BO64aWIMKF8+kHI1j+d2aul1S4f+TxtzxSQwzpb1xk4=; b=U+2nIVv5YeOqt9N4jBHaKdmh04m+Fx18tKSzyo0GBQxGsINn9h/sKHPaso/mxriMMwmQwaA78s2jnErFNPSI3illzbBj1LOTlAns13rtp2g5J341R8XPKODRoCXowHyhRvQnK3NkHZ5YY0PplgLHfyVaGGNwW0k/QfZY3zn5YEY= Received: from AM0PR03MB4148.eurprd03.prod.outlook.com (20.177.40.10) by AM0PR03MB5761.eurprd03.prod.outlook.com (20.179.252.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Wed, 18 Sep 2019 18:50:51 +0000 Received: from AM0PR03MB4148.eurprd03.prod.outlook.com ([fe80::71e3:834d:5708:5a0a]) by AM0PR03MB4148.eurprd03.prod.outlook.com ([fe80::71e3:834d:5708:5a0a%5]) with mapi id 15.20.2199.015; Wed, 18 Sep 2019 18:50:51 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Thread-Topic: [PATCH v2 1/6] xen/arm: optee: impose limit on shared buffer size Thread-Index: AQHVblH+avUrsKasKUuqntnk7iOMNA== Date: Wed, 18 Sep 2019 18:50:51 +0000 Message-ID: <20190918185041.22738-2-volodymyr_babchuk@epam.com> References: <20190918185041.22738-1-volodymyr_babchuk@epam.com> In-Reply-To: <20190918185041.22738-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@epam.com; x-originating-ip: [85.223.209.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a723deed-fbb3-4439-d738-08d73c692104 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR03MB5761; x-ms-traffictypediagnostic: AM0PR03MB5761:|AM0PR03MB5761: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(189003)(199004)(52084003)(66476007)(6116002)(478600001)(14454004)(66446008)(80792005)(2616005)(55236004)(8936002)(66066001)(5660300002)(2501003)(81156014)(305945005)(7736002)(81166006)(66556008)(8676002)(256004)(71200400001)(14444005)(71190400001)(99286004)(54906003)(1076003)(86362001)(26005)(11346002)(6512007)(5640700003)(2906002)(186003)(102836004)(3846002)(64756008)(76116006)(2351001)(91956017)(6506007)(25786009)(486006)(66946007)(36756003)(476003)(446003)(4326008)(316002)(6436002)(76176011)(6486002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR03MB5761; H:AM0PR03MB4148.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: epam.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TOElGEeH6956ADnV/Kzf8VC1K2e5FfCBcwKmcKX91XCBVin5zhth/NgQT7dRJc2TGvo93Ez3QYkcyE1pI9p7K3GAd5kQQMSLzrz2+zUSl8L13+jb+uP/lsv7ese/sDoGEZksSiU2D6Nz1dU0hO3nvQ2y92NqXiF/AKV4Mf4ojbqbsy8/JDysCz8093+VXDFjGJDX3peN7qRG4I75tM6NAnjYfndqTtJTPJ4WhxA855dKrKFK3bdFXGKxggM1izlmsAWvrYbCoX60VQjmvuTXH6vaRptwtAG9t1J30e33nXFgbpHZ0HzHmSQQbW1EZYmLK9dALCOBZxevPMgXH+kHY5AZOAhorGf500X1Sq3XmoNZAOzX5EaOYsiWun19/55y/I3XVwL1CT5bMb77K7ATu/0MZi5xtrQD2XkZLNmKjzg= MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a723deed-fbb3-4439-d738-08d73c692104 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 18:50:51.7463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1J7LHiSkQC3hGzvqds2x4L+lZTDBbKPL6n9OLIBxmjBEZK9XiTk9RmUQYF5es39SvYrsZ73tg9oHs7FwjYAORWStuVvWVqqslLmRqraMO4M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5761 Subject: [Xen-devel] [PATCH v2 1/6] xen/arm: optee: impose limit on shared buffer size X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "tee-dev@lists.linaro.org" , Julien Grall , Stefano Stabellini , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" We want to limit number of calls to lookup_and_pin_guest_ram_addr() per one request. There are two ways to do this: either preempt translate_noncontig() or limit size of one shared buffer size. It is quite hard to preempt translate_noncontig(), because it is deep nested. So we chose the second option. We will allow 129 pages per one shared buffer. This corresponds to the GP standard, as it requires that size limit for shared buffer should be at least 512kB. One extra page (129th) is needed to cope with the fact that user's buffer is not necessary aligned with page boundary. Also, with this limitation OP-TEE still passes own "xtest" test suite, so this is okay for now. Signed-off-by: Volodymyr Babchuk --- Changes from v1: - Added comment before BUILD_BUG_ON(PAGE_SIZE != 4096); - Fixed typo in the commit message - Decreased MAX_SHM_BUFFER_PG to 129 --- xen/arch/arm/tee/optee.c | 44 +++++++++++++++++++++++++++++----------- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index ec5402e89b..d64e9c3b85 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -72,6 +72,19 @@ */ #define MAX_TOTAL_SMH_BUF_PG 16384 +/* + * Limit for shared buffer size. Please note that this define limits + * number of pages. But user buffer can be not aligned to a page + * boundary. So it is possible that user would not be able to share + * exactly MAX_SHM_BUFFER_PG * PAGE_SIZE bytes with OP-TEE. + * + * Global Platform specification for TEE requires that any TEE + * implementation should allow to share buffers with size of at least + * 512KB, which equals to 128 4KB pages. Due to align issue mentioned + * above, we need to increase this value to 129. + */ +#define MAX_SHM_BUFFER_PG 129 + #define OPTEE_KNOWN_NSEC_CAPS OPTEE_SMC_NSEC_CAP_UNIPROCESSOR #define OPTEE_KNOWN_SEC_CAPS (OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM | \ OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM | \ @@ -697,16 +710,29 @@ static int translate_noncontig(struct optee_domain *ctx, size = ROUNDUP(param->u.tmem.size + offset, OPTEE_MSG_NONCONTIG_PAGE_SIZE); pg_count = DIV_ROUND_UP(size, OPTEE_MSG_NONCONTIG_PAGE_SIZE); + if ( pg_count > MAX_SHM_BUFFER_PG ) + return -ENOMEM; + order = get_order_from_bytes(get_pages_list_size(pg_count)); /* - * In the worst case we will want to allocate 33 pages, which is - * MAX_TOTAL_SMH_BUF_PG/511 rounded up. This gives order 6 or at - * most 64 pages allocated. This buffer will be freed right after - * the end of the call and there can be no more than + * In the worst case we will want to allocate 1 page, which is + * MAX_SHM_BUFFER_PG/511 rounded up. This buffer will be freed + * right after the end of the call and there can be no more than * max_optee_threads calls simultaneously. So in the worst case - * guest can trick us to allocate 64 * max_optee_threads pages in + * guest can trick us to allocate 1 * max_optee_threads pages in * total. + * + * It may seem strange to have such complex calculations if we + * always will allocate exactly one page. Those calculations exist + * in the first place because earlier there were bigger limit for + * shared buffer size, so there were cases, when we needed more + * that one page there. Right now this is not true, but this code + * remains for two reasons: + * - Users can change MAX_SHM_BUFFER_PG to a higher value, in which + * case they will need this code. + * - There is a plan to implement preemption in the code below, which + * will allow use to increase default MAX_SHM_BUFFER_PG value. */ xen_pgs = alloc_domheap_pages(current->domain, order, 0); if ( !xen_pgs ) @@ -747,13 +773,7 @@ static int translate_noncontig(struct optee_domain *ctx, xen_data = __map_domain_page(xen_pgs); } - /* - * TODO: That function can pin up to 64MB of guest memory by - * calling lookup_and_pin_guest_ram_addr() 16384 times - * (assuming that PAGE_SIZE equals to 4096). - * This should be addressed before declaring OP-TEE security - * supported. - */ + /* Only 4k pages are supported right now */ BUILD_BUG_ON(PAGE_SIZE != 4096); page = get_domain_ram_page(gaddr_to_gfn(guest_data->pages_list[idx])); if ( !page )