From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752507AbdI2PTQ (ORCPT ); Fri, 29 Sep 2017 11:19:16 -0400 Received: from mail-eopbgr40047.outbound.protection.outlook.com ([40.107.4.47]:61072 "EHLO EUR03-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752385AbdI2PTK (ORCPT ); Fri, 29 Sep 2017 11:19:10 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@epam.com; Subject: Re: [PATCH v1 02/14] tee: add register user memory To: Mark Rutland Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tee-dev@lists.linaro.org, Jens Wiklander , Volodymyr Babchuk References: <1506621851-6929-1-git-send-email-volodymyr_babchuk@epam.com> <1506621851-6929-3-git-send-email-volodymyr_babchuk@epam.com> <20170929105311.GC5781@leverpostej> From: Volodymyr Babchuk Message-ID: Date: Fri, 29 Sep 2017 18:19:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170929105311.GC5781@leverpostej> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [85.223.209.54] X-ClientProxiedBy: VI1PR0101CA0062.eurprd01.prod.exchangelabs.com (2603:10a6:800:1f::30) To VI1PR0301MB2142.eurprd03.prod.outlook.com (2603:10a6:800:26::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c3f577e-676a-4701-7c2e-08d5074d6dad X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:VI1PR0301MB2142; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0301MB2142;3:i7FPKtV7GIMf7mlOnMbTeTasV6oUpvBjtWsctMMtQ/ypatWrocCQIzpV1nwjpwIUIjfbOhZOPMiw/CK4NryTaJEiL3kL8tlPqAPnBgCQiOxY6oFaIekxGGUccED5uTjByDaHkZhF1z/2TmF1Vt9Hnr0Z0ft66a85JTW/yT8JCuVRvmmkmzl0YvZIEE//0IKoiU3x7dmKNtoH+AAolwIFIuDmajGkkuBo57vOaRS6IId243ClLL5oQSEJSCWkSWFQ;25:615eyTIAaw8wPMOU57iyzvK7jeXDMhZSFd4b+LaQRCdnjevq2PiyfXwPA+qVtzugOeUvFRzo64TJXrQ2s2PEcAjNWZZehaogRBZEJh7NQyRKviR/Rm+7L2nTUYJ+DRnonbwozuel+VYB1yR+x6zWaqyWrL0MRv57dmPBKLU9WHSWfNMOnir1RW/x+UIggM6nKxQb1wo1X5B+nqSkKlz2Q4oEMuyNLYcklxaPqDSznQz3STCVCSTp1zZp95YasZ6GJN+ouRL10g724KGYicPRxMBl2ZhUhjL83BedOqiH+JCHA67UFotF9bJ+X24RAbjk9jIlRq0pKMWwb3jLgtesjQ==;31:Qw5OQVRj7EefxetDq4dF929W11+DiPbwJfPyOojNu02BAtp7bq4C8aljj6wQdTczLE0XSLwFVBd/yJgUysQTYT6YTyDx8+dUJjFzKtJll471Y0JqMzNcLwUCHXK+JvrQ6xp8ZL2LN5E2B9Pk82j0Ip6Wg3wCpPbB8lVwvHEt2OvmszW7JqnDG5/SMDY8tthayOa7pjBjWjA+gvr4Q/tZwiNVlBX8V8iTX/xfAbk+Vhs= X-MS-TrafficTypeDiagnostic: VI1PR0301MB2142: X-Microsoft-Exchange-Diagnostics: 1;VI1PR0301MB2142;20:91zas/A7/YdXTxulRi2UOqRk0EDG71yBKVkTaidCKp50nIMXJ1Z45ET0dpzW1nnB84ikpsYn03NllSEK2JtE6ke7atX80IHcho/PBiDMw5KPR7FP5hwMpFqy022ZxfoE4x88L9LmOg6bDbt4HTd6h/TtFDeh1HtWLhoNvQ7YNI+EVZ/gjNgHQkkx06keGmSG3XNjmvRO61mUP8v4/1H9m8u7amcuSs7bbNJ3eBjZ2QInPL+gIPOjIxI7LCnKyHDiHVnZTZRL9GenFsgr71zjWDirFSaFjpMsy7BPap4trCbVGDbvVT1lpjKHRADqOHmrsDRq8i+OkjHdIZK71sO0EvKlTRrFI8Cj+AlS38+zFqDJ2qgh4nUQuQW+vPVjX3guSFQ0axXb90RrRqKjMKnr6n5a9lMbA9Z6TcC1QKRKt7uvNnuZrv5UTH8mdPDcpGC0wQiL7hM+llwz0qBL6/O7TQo769QHa3k3LUbBxc5wPh0VqjtjTlGUxlDSdOVpJ8VW;4:rTTgnWoGZU8J8G5oQs+Yi+PRzapZgZamIXD9s0z/sZ900jHx+230ngoh28phK9TsVjcCZXSKgOH/jvzC/KHLVoOMYtF3MPm0dsdiOB1wAxL7l7fqkwOBnQIivuWzBw8PnsmS3ZKLhsdk4W2p3b4qOKO4gQKDxXGQabkbuDB6obOKzLmG3rLHfhoj0rakwTk+ndo/8SLi/mwag2PvVxqMPrQaWYkDPr6LS5kR31UIHCRJHMpA6p2xpF0SfWN592BQ X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:VI1PR0301MB2142;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:VI1PR0301MB2142; X-Forefront-PRVS: 0445A82F82 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(39860400002)(376002)(346002)(24454002)(189002)(199003)(97736004)(6116002)(101416001)(64126003)(189998001)(83506001)(8676002)(36756003)(106356001)(81166006)(68736007)(345774005)(8936002)(76176999)(105586002)(50986999)(81156014)(54356999)(33646002)(229853002)(25786009)(305945005)(7736002)(2906002)(2950100002)(39060400002)(6916009)(54906003)(86362001)(65806001)(4326008)(65956001)(5660300001)(3846002)(6486002)(65826007)(50466002)(80792005)(316002)(53936002)(53546010)(16576012)(66066001)(77096006)(31696002)(58126008)(6666003)(6246003)(47776003)(23676002)(72206003)(31686004)(478600001)(230700001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0301MB2142;H:[10.17.182.79];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjAzMDFNQjIxNDI7MjM6eWwxa3NncFZpdmY0dFdjSHNsTnJIRU1U?= =?utf-8?B?RlYvTG1VNk04UjBVczU2bDhEeE10b3pMcWg2ejRwazJIMlNqUjE4Wi84YThW?= =?utf-8?B?ZGpGS1VLSVJSdXBlVUo4VUl2MUh0U3U2dnZmaWozY2d5QjQybmJBQXFzMDcy?= =?utf-8?B?ZXQwd1NSYWVYNVRPUElrbmo0dXFodUN2V0oxWjRxSzNlN3NmTGxLbDZobVZo?= =?utf-8?B?ZGl6RFJrNmRRSU00eFhoT08wdFE1NURNWXF1MlVPOVZvcEN1SDhoemd6TWVP?= =?utf-8?B?MlFadmZ3MURvQ2hqaU9KeG5pSTFBYXNOaU0xSEpNckpCeDZoajk3ZDJSUk11?= =?utf-8?B?VTU0NzFBb1NsR28ySURnalZlaTZ5dFRTSDR5Um00SHIzdlVJR3daRWZPMTVS?= =?utf-8?B?SVpldjNVcFRuay9tSjFZT0hmL1EveE9MRm5uNjVnNVZZYnhRaURqM3B4Tkpn?= =?utf-8?B?aWxFUjZxSk1MSkUrSjJFajBmci9Lcm9SUGlRclVrVE1LczNPN1huVWJ0MkJJ?= =?utf-8?B?KzMrakMrTDE3Zi9jZFpLMVllMmFnRDJheGhyMXBWU1BEbWFMOVZGY2RVYWEv?= =?utf-8?B?bERySFBFb3hBYzkybHBvNE11N1JKbVZINDU4Tjh0Y2lVaGhmajJnZWNxdmpN?= =?utf-8?B?TkE5YUVSamRYcncvbFNTU09sdzhiYXZNb2k2emM1Q1Z0OUMwMjRZYWRhRFYy?= =?utf-8?B?eXFFSndkRFdMR1ZTS2tqZWFFc0pkN2Z5SGlHSTVycTFXdkhmQ3pMTVZmZFZw?= =?utf-8?B?dHlkOUlYWFdWNisxbmlZc21sMUk3Qnp4YzFEWWYwNkxRa2FWbW0walJMYmlJ?= =?utf-8?B?MDNhb1YrbHlBTitSZHZRbVo4S1RYTkQ1dWM5dkpuZFBxTXlyQStGU0svSlRX?= =?utf-8?B?YlB6ZzNaOHczc1N0SmdwUWNseEFReitQaFREY2ZNV01QKyt5ZmdoUmFNZVFO?= =?utf-8?B?RFRwUlpTWGpkc1dsM2dVaXVoTEl2N2RPalhXS01tYjhNY2laZ1p2MnJSUy84?= =?utf-8?B?dVVWRVR1N1lESkVsOU9jMmV3QXo5bVJDN3loQ3YxaTJ6bDJvRlFZYVVEQ21u?= =?utf-8?B?YTd2ZnozMStyM0hQRkRQSkdYL0h0TXFtZHVvVzVpZjlSNzRKVzM1d2dMYmRB?= =?utf-8?B?NzRKakxIb3phclcxek0xWEYrdUgwZVR3ZDY0NmJqelpUcDR2V25tWXNZenov?= =?utf-8?B?bFdXVHBXZ3UweFpnWnBSdzlGc0JQeTVQcFlqS0x2TyswdS9PWWc0ZTNYY3Vo?= =?utf-8?B?aGJuSFJ3V3hTSzNHd1pTcEluMkV2eUJIUmlYbHMxN1pBb09lSFhOMnIvMlVB?= =?utf-8?B?VG5JQVZ0UWVqZkZGNnJDNURuTVQ1Y0dTajMvT3dFNldxM29WUmRyeEw4NnR5?= =?utf-8?B?NFN4WXd6TXNrMThKbFF3b3F1RnlRdTBaQ2pmRk1EVkFTbUhLZlJYSlZEZU1T?= =?utf-8?B?c01CMkRXUTBDWUVQSkl5SUtxUmIyY212bkllY3RSTTVkNk0xMHhTSGc2Q1Zu?= =?utf-8?B?SzdGenk1YTh4VHBRT0toSExwanVndjZLVkdveHhUdHVUWVR5bjkxWm05MW5S?= =?utf-8?B?UU5sb1hIeEJZYmtpSU5KRk1nQXIvckVPZnV0SiswOWVVSW81dzRDY0xVMnFr?= =?utf-8?B?TVhVckZaTXE0b2pBSWVJcUpQNlRpdTVWWnEyeCtUZ1lOZk5Jd05JNmI1ckNl?= =?utf-8?B?SGt1WEs2SHRHY0wyZHRtbmp6Y1d1T2EvemRxVGZtREdscElvRGNDMWxCcG9S?= =?utf-8?B?aHlCUzVGNkMxcWJ6TGhYSTJweDRVS05HSmI0d1ZLRUdtQzA1MldoQjNkVXdl?= =?utf-8?B?Y09hMVJKVCtlZytHRTVpOE4xdC8yeHF5UVQrY2FYbkRrUkRZUm11aEVQOUhh?= =?utf-8?B?VU5KeWxzWGQxdjdSdG9hNnF3V3dXYjdaS25GUWczRWZHL2g3S0thN050OU9x?= =?utf-8?Q?ju1VFwCuuKQ5t2fPDbuc4890neL4sYpc=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0301MB2142;6:zBPmu8ZmuY34hoJWT1v9FWHo3tbbke0vaCMlkfe/5Jd+hlqp5vZJoELiX7Pyxd69NWLHdNDRy533t5Vd9GZg+Cno2JdBimzeunksBFaMHQntEqgxLgOpghmBxrmgqv1AT8D97jr48vxQJMb/FoxRxIT2KhqokmLLx5BAoNoupquH/RIduQnY5vP911UDQ5YbYah7n3dTZVQb77Nxtspk6ub2xP/ErGj/q+VIUHg2dAuFw1HCfegDT+rl8pOxekFJwrc67Kyyk1ESssgq02Jr2pJAt8f0beidV+0CCaQ/fFwRvY9qFTUEvB2TxpOb+X6/WXOn4IV7mAFLe9TZmhjPCg==;5:H7yiAqIVFABmiMsdRW2mtYm8rE8GD5rXzco0GTl6OPN9eTm7P48Q7R01H9p3OXNc4g+8iV6WhMUsllvwvH6w5p5KcdYAQUYSa2H8HZ+fqrNp/aEhXtMBswQMEpL1F5v117V8aVvZoC+9jYecEvQXLQ==;24:J4dg1j9OR6gKpN3F13ea7/rYulrC2N184zhmTWQ+4NvOhlaE9YJ4mqOQBW/yyULdrVWRRatIKMXIZsuLo0Pco/f5LchQHFeU0P3SZBjlETU=;7:KfvGL2m31DI5Th18Pn3/Lac7rkB6CtMGWxHSHWX4XSk6gi2IQNZvj75t5qf05o4Lc//BPG+2KDMCAxrQljsCBbexieJxa3awQXkj0YzZRMeQ/T6DJ+AM0oDGvThdTWCQG/JOsEZrWOjb04R6RA0/kS6WvdX8AvhNfkKBuwrsG2yW82cOa84VGp9RYzAbK+MRatWrirKB2rE4t6YMb5p7ALMqeh1FiY/QCT6G3FEgEyc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2017 15:19:07.3005 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0301MB2142 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.09.17 13:53, Mark Rutland wrote: > On Thu, Sep 28, 2017 at 09:03:59PM +0300, Volodymyr Babchuk wrote: >> +static int >> +tee_ioctl_shm_register(struct tee_context *ctx, >> + struct tee_ioctl_shm_register_data __user *udata) >> +{ >> + long ret; >> + struct tee_ioctl_shm_register_data data; >> + struct tee_shm *shm; >> + >> + if (copy_from_user(&data, udata, sizeof(data))) >> + return -EFAULT; >> + >> + /* Currently no input flags are supported */ >> + if (data.flags) >> + return -EINVAL; >> + >> + shm = tee_shm_register(ctx, data.addr, data.length, >> + TEE_SHM_DMA_BUF | TEE_SHM_USER_MAPPED); >> + if (IS_ERR(shm)) >> + return PTR_ERR(shm); >> + >> + data.id = shm->id; >> + data.flags = shm->flags; >> + data.length = shm->size; >> + >> + if (copy_to_user(udata, &data, sizeof(data))) >> + ret = -EFAULT; >> + else >> + ret = tee_shm_get_fd(shm); > > Why do you need both the fd and an id? That seems redundant. > > [...] Not exactly. This approach is used for all shared memory object types. fd is used to control life cycle. id identifies the buffer. There are at least three types of shared memory objects available: - Allocated memory is already present in tee subsystem - My patch series add registered shared memory - There are patches in linaro branch that add support for dma_buf shared memory objects It it easier to identify them all with id, that with fd (which can be tricky in case of dma_buf objects, by the way). >> +struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr, >> + size_t length, u32 flags) >> +{ >> + struct tee_device *teedev = ctx->teedev; >> + const u32 req_flags = TEE_SHM_DMA_BUF | TEE_SHM_USER_MAPPED; >> + struct tee_shm *shm; >> + void *ret; >> + int rc; >> + int num_pages; >> + unsigned long start; >> + >> + if (flags != req_flags) { >> + dev_err(teedev->dev.parent, "invliad shm flags %#x", flags); >> + return ERR_PTR(-EINVAL); >> + } >> + >> + if (!tee_device_get(teedev)) >> + return ERR_PTR(-EINVAL); >> + >> + if (!teedev->desc->ops->shm_register || >> + !teedev->desc->ops->shm_unregister) { >> + dev_err(teedev->dev.parent, >> + "register shared memory unspported by device"); > > I don't think this should be a dev_err. The user requested something > that the device did not support, but that's not a device-side error. > > A user may legitmiately do this to probe whether the TEE supports > registering memory. Agree. I'll remove dev_err() invocation. >> + tee_device_put(teedev); >> + return ERR_PTR(-EINVAL); > > Perhaps EOPNOTSUPP? Sure. Thanks. >> + } >> + >> + shm = kzalloc(sizeof(*shm), GFP_KERNEL); >> + if (!shm) { >> + ret = ERR_PTR(-ENOMEM); >> + goto err; >> + } >> + >> + shm->flags = flags | TEE_SHM_REGISTER; >> + shm->teedev = teedev; >> + shm->ctx = ctx; >> + shm->id = -1; >> + start = rounddown(addr, PAGE_SIZE); >> + shm->offset = addr - start; >> + shm->size = length; >> + num_pages = (roundup(addr + length, PAGE_SIZE) - start) / PAGE_SIZE; > > Why not mandate that the user passes a buffer which has a start and end > aligned to PAGE_SIZE? > > Otherwise, the buffer is size is silently upgraded without the user's > knowledge, which seems likely to result in bugs. Because according to GlobalPlatform TEE specification, client can register any portion of own memory. I agree that it is error-prone to allow TEE (and TA) to see not shared parts of client memory. But in terms of GlobalPlatform, Linux and its userspace considered as non-secure anyways. While TEE and TAs are considered trusted. Misbehaved TEE or TA anyways can do many bad things, so corruption of userspace memory does not look so bad. >> + shm->pages = kcalloc(num_pages, sizeof(struct page), GFP_KERNEL); > > I think you mean sizeof(struct page *) here. Ooops. Good catch. Thank you > Generally, for: > > lhs = some_alloc(sizeof(x)) > > ... it's preferred that x is *lhs, so as to keep the types in sync. e.g. > > shm->pages = kcalloc(num_pages, sizeof(*shm->pages), GFP_KERNEL); Yes, will do in this way. Thank you. >> + if (!shm->pages) { >> + ret = ERR_PTR(-ENOMEM); >> + goto err; >> + } >> + >> + rc = get_user_pages_fast(start, num_pages, 1, shm->pages); >> + if (rc > 0) >> + shm->num_pages = rc; >> + if (rc != num_pages) { >> + if (rc > 0) >> + rc = -ENOMEM; >> + ret = ERR_PTR(rc); >> + goto err; >> + } >> + >> + mutex_lock(&teedev->mutex); >> + shm->id = idr_alloc(&teedev->idr, shm, 1, 0, GFP_KERNEL); >> + mutex_unlock(&teedev->mutex); > > AFAICT, idr_alloc() can fail, so I beleive you're missing a sanity check > on the return value here. You are right. Will fix. Thank you for the review. From mboxrd@z Thu Jan 1 00:00:00 1970 From: volodymyr_babchuk@epam.com (Volodymyr Babchuk) Date: Fri, 29 Sep 2017 18:19:02 +0300 Subject: [PATCH v1 02/14] tee: add register user memory In-Reply-To: <20170929105311.GC5781@leverpostej> References: <1506621851-6929-1-git-send-email-volodymyr_babchuk@epam.com> <1506621851-6929-3-git-send-email-volodymyr_babchuk@epam.com> <20170929105311.GC5781@leverpostej> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 29.09.17 13:53, Mark Rutland wrote: > On Thu, Sep 28, 2017 at 09:03:59PM +0300, Volodymyr Babchuk wrote: >> +static int >> +tee_ioctl_shm_register(struct tee_context *ctx, >> + struct tee_ioctl_shm_register_data __user *udata) >> +{ >> + long ret; >> + struct tee_ioctl_shm_register_data data; >> + struct tee_shm *shm; >> + >> + if (copy_from_user(&data, udata, sizeof(data))) >> + return -EFAULT; >> + >> + /* Currently no input flags are supported */ >> + if (data.flags) >> + return -EINVAL; >> + >> + shm = tee_shm_register(ctx, data.addr, data.length, >> + TEE_SHM_DMA_BUF | TEE_SHM_USER_MAPPED); >> + if (IS_ERR(shm)) >> + return PTR_ERR(shm); >> + >> + data.id = shm->id; >> + data.flags = shm->flags; >> + data.length = shm->size; >> + >> + if (copy_to_user(udata, &data, sizeof(data))) >> + ret = -EFAULT; >> + else >> + ret = tee_shm_get_fd(shm); > > Why do you need both the fd and an id? That seems redundant. > > [...] Not exactly. This approach is used for all shared memory object types. fd is used to control life cycle. id identifies the buffer. There are at least three types of shared memory objects available: - Allocated memory is already present in tee subsystem - My patch series add registered shared memory - There are patches in linaro branch that add support for dma_buf shared memory objects It it easier to identify them all with id, that with fd (which can be tricky in case of dma_buf objects, by the way). >> +struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr, >> + size_t length, u32 flags) >> +{ >> + struct tee_device *teedev = ctx->teedev; >> + const u32 req_flags = TEE_SHM_DMA_BUF | TEE_SHM_USER_MAPPED; >> + struct tee_shm *shm; >> + void *ret; >> + int rc; >> + int num_pages; >> + unsigned long start; >> + >> + if (flags != req_flags) { >> + dev_err(teedev->dev.parent, "invliad shm flags %#x", flags); >> + return ERR_PTR(-EINVAL); >> + } >> + >> + if (!tee_device_get(teedev)) >> + return ERR_PTR(-EINVAL); >> + >> + if (!teedev->desc->ops->shm_register || >> + !teedev->desc->ops->shm_unregister) { >> + dev_err(teedev->dev.parent, >> + "register shared memory unspported by device"); > > I don't think this should be a dev_err. The user requested something > that the device did not support, but that's not a device-side error. > > A user may legitmiately do this to probe whether the TEE supports > registering memory. Agree. I'll remove dev_err() invocation. >> + tee_device_put(teedev); >> + return ERR_PTR(-EINVAL); > > Perhaps EOPNOTSUPP? Sure. Thanks. >> + } >> + >> + shm = kzalloc(sizeof(*shm), GFP_KERNEL); >> + if (!shm) { >> + ret = ERR_PTR(-ENOMEM); >> + goto err; >> + } >> + >> + shm->flags = flags | TEE_SHM_REGISTER; >> + shm->teedev = teedev; >> + shm->ctx = ctx; >> + shm->id = -1; >> + start = rounddown(addr, PAGE_SIZE); >> + shm->offset = addr - start; >> + shm->size = length; >> + num_pages = (roundup(addr + length, PAGE_SIZE) - start) / PAGE_SIZE; > > Why not mandate that the user passes a buffer which has a start and end > aligned to PAGE_SIZE? > > Otherwise, the buffer is size is silently upgraded without the user's > knowledge, which seems likely to result in bugs. Because according to GlobalPlatform TEE specification, client can register any portion of own memory. I agree that it is error-prone to allow TEE (and TA) to see not shared parts of client memory. But in terms of GlobalPlatform, Linux and its userspace considered as non-secure anyways. While TEE and TAs are considered trusted. Misbehaved TEE or TA anyways can do many bad things, so corruption of userspace memory does not look so bad. >> + shm->pages = kcalloc(num_pages, sizeof(struct page), GFP_KERNEL); > > I think you mean sizeof(struct page *) here. Ooops. Good catch. Thank you > Generally, for: > > lhs = some_alloc(sizeof(x)) > > ... it's preferred that x is *lhs, so as to keep the types in sync. e.g. > > shm->pages = kcalloc(num_pages, sizeof(*shm->pages), GFP_KERNEL); Yes, will do in this way. Thank you. >> + if (!shm->pages) { >> + ret = ERR_PTR(-ENOMEM); >> + goto err; >> + } >> + >> + rc = get_user_pages_fast(start, num_pages, 1, shm->pages); >> + if (rc > 0) >> + shm->num_pages = rc; >> + if (rc != num_pages) { >> + if (rc > 0) >> + rc = -ENOMEM; >> + ret = ERR_PTR(rc); >> + goto err; >> + } >> + >> + mutex_lock(&teedev->mutex); >> + shm->id = idr_alloc(&teedev->idr, shm, 1, 0, GFP_KERNEL); >> + mutex_unlock(&teedev->mutex); > > AFAICT, idr_alloc() can fail, so I beleive you're missing a sanity check > on the return value here. You are right. Will fix. Thank you for the review.