From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59F14CDB474 for ; Fri, 20 Oct 2023 13:56:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE21E8D00BC; Fri, 20 Oct 2023 09:56:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB86A8D0003; Fri, 20 Oct 2023 09:56:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA8B38D00BC; Fri, 20 Oct 2023 09:56:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AA8F38D0003 for ; Fri, 20 Oct 2023 09:56:41 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5027912071D for ; Fri, 20 Oct 2023 13:56:41 +0000 (UTC) X-FDA: 81365990202.07.CC1FA61 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf14.hostedemail.com (Postfix) with ESMTP id 3CBD610000F for ; Fri, 20 Oct 2023 13:56:39 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=GDpC5UdM; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf14.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697810199; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2Lv+JPTrGJWr5PKLTGg8ZQKvp8HvUDI21SsiboerxPU=; b=aY2Mi4OeAozWfmGMkAdwwfvYLJu1/HMRYQwLi2Yh5bMYdzVePYexxjChtaDuB2AkedEa29 2yRf1dCNGxunH9eSSMf7mE3I4qYJXZgf43vB9xdriZTIiZBsXcbmOO3cIRWSti+5sfre+a jEidRxCz7EsaVxLqfpaC8kgHOxu6yic= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=GDpC5UdM; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf14.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697810199; a=rsa-sha256; cv=none; b=sfPlc+iSPQE0hC+Z2Y92DeIDMwWp6R2OiNVHG8NVkd+xaXFqF7iZacNCH5cLDDADJW7E30 z5fbnrX5Z5zuW6iIYwJoEDKGzkYnD/akSwn/i7RpFyo91b6dh9d8ppwWvfOqUaQWfxJkdM oeb6Qguimj34vD4RaehUvEZ1k7tR7wA= Received: from [192.168.100.7] (unknown [39.34.188.12]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id 745D56607377; Fri, 20 Oct 2023 14:56:18 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1697810197; bh=rKfZfpFQKx5mNZYmDoPXgE0AS8y+IyTbCZMCDsJThSQ=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=GDpC5UdMeV5DzD30TDmYalwaFxn1hMovA+uu/S5FTUYpQLOeERNorFBCv4gofox3a iQA6F5vueG5gUgX35ADJg4EOCi6jjs6eY21q/pa39yr1ZqSYjjKjCgwzGK/969TA1a ZD80vCXwVQs5QZ7Fp8hi5dCAsRZHI4VfaYNHGMy9irZC2ugHd5gAfTjUt5o2TELaLx NNSy3+jXeodA0EwNPsMgld2HFkeALd3IYhjuAw5W4vfAGAukXsH2oh+5KKR5uvcpyV TkXjWb9sHYI4Zdcyg3hHeiZAWeHy2vT1Zb1lFmlY4N/wKlCEHNVwIcv+XfwNDi95a/ Plz7SPiFE6kpg== Message-ID: <38f132b8-4fd2-40e2-b24e-62164a0ee4e6@collabora.com> Date: Fri, 20 Oct 2023 18:56:07 +0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: Muhammad Usama Anjum , jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, surenb@google.com, alex.sierra@amd.com, apopple@nvidia.com, aneesh.kumar@linux.ibm.com, axelrasmussen@google.com, ben@decadent.org.uk, catalin.marinas@arm.com, david@redhat.com, dwmw@amazon.co.uk, ying.huang@intel.com, hughd@google.com, joey.gouly@arm.com, corbet@lwn.net, wangkefeng.wang@huawei.com, Liam.Howlett@oracle.com, lstoakes@gmail.com, mawupeng1@huawei.com, linmiaohe@huawei.com, namit@vmware.com, peterx@redhat.com, peterz@infradead.org, ryan.roberts@arm.com, shr@devkernel.io, vbabka@suse.cz, xiujianfeng@huawei.com, yu.ma@intel.com, zhangpeng362@huawei.com, dave.hansen@intel.com, luto@kernel.org, linux-hardening@vger.kernel.org Subject: Re: [RFC PATCH v2 6/8] mseal: Check seal flag for mremap(2) Content-Language: en-US To: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org References: <20231017090815.1067790-1-jeffxu@chromium.org> <20231017090815.1067790-7-jeffxu@chromium.org> From: Muhammad Usama Anjum In-Reply-To: <20231017090815.1067790-7-jeffxu@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: zekgds87fadypru6gecxqzd5dn74dytr X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3CBD610000F X-HE-Tag: 1697810198-112758 X-HE-Meta: U2FsdGVkX19LzN6Wd2va2IuxX6PujxEDruUbXX8tSdjoQSwQxfTDaff7IJOhZESItwjQWZA+NePGuE4Ke1XNmiQuMH3Pf5DYyBXCh074F/mzXU+ChGY8McGGozu4lYDT2+cFrHouzJmSF7ExFU8NT4rXnNx4uZJrwNuHBOgZuldcbqH1nnN7eX2q9wZsrbv9VsSdHJYzC6W0qqVnJRbaO945Jc3u3WSHcbG5zyERM09turRj2/YmIqqiVhnPGA/SUBAsQoGIod3LVV1AJAvKp2fqe2mqzY0dBlL7wGm6WQmWkBJPeR0xYB4emWx6ksb0HRr7QuByK1nNkLTIM6i0A2Gj/Dhk2B1VhuDm+5fRuiupaj29SbTZQKSSxgmOa4c9jWwApRC9WWml5lmpqCVcfECc7UYKPSrPbHG7c7bGcXi/y2ZceE/o+b5kzGISXVP9OaRrVmIhikC41Z0vhqOd+AMuBPo7Eiq2cXwYWV54nRiSuzhl7A+vTX1Yelwq2QZu/Xek9ET65Wvu5PM2ZAqZaimhJ6q83D8Y5fQWylgQTeDQRgf2hbSOdLLMHjSmdcIqChrvrT9RPQ2eRy9MTu1J5xAbkvHkxGNnFWaZ8fDsjETJ9d5lJKUgqDNRBKeGu9aduxyQfdJmJkdYjPEe4S+WC8XGAE2yYkDvd0/wTDzk/x5P6ZVaxBETQKFhQS+a1vf471zGUSd7RyzEzZeVDPN9I/F2wo0T0fngxWMNG0t/zBOMU7crwStrVaQlOi22OGMefg9oRvTrzu0y+hsrINo9SEKctqeY3lRcRg6YzBC1MBFDIzCVtgII4GibQXahI0EqsRM7k9mWN674nrl2iKl11sp0fEBaAdiOhnJrXNxZcf2aYDwZJzW3cAIYN263+nc31BeZWCD2/R7nXAaKoW8I47BQMj6jE6oyxE00MwT0sbkooamixGcNdd6oakWz029yKtO7c+cLfzoM1C5AzHE OSXRZGtj M4GJMvO+LPB5sfsgRdJEKsyrN73VabZdrmlBsMZcCyvk3quVTCUgLig8rip2fHScTHzHXmffMeZ/43fqR3WVifmEPZqe/Rm7dYlUPmcWvm6uRmle4bA90AZh+ZK4LjZnv5GHmaDW3b+3aGsO+XG+kQif+uzFX51myk1/5kIE0N0IvZDJ0HFpRMWuJz60OdydnxSRCY3pIA4PAjpcwd4V1mypcEZ1WsF7H7uR13UC7zkdPdhHJ/eHMtVh6cqo2hVkspuCOpYahea4gvcRTll9XE3yLCZss7vYlAao/liL43/S2OZZcTCwZUkgz4PsF/mJgtObv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/17/23 2:08 PM, jeffxu@chromium.org wrote: > From: Jeff Xu > > mremap(2) can shrink/expand a VMA, or move a VMA to a fixed > address and overwriting or existing VMA. Sealing will > prevent unintended mremap(2) call. > > What this patch does: > When a mremap(2) is invoked, if one of its VMAs has MM_SEAL_MREMAP > set from previous mseal(2) call, this mremap(2) will fail, without > any VMA modified. > > This patch is based on following: > 1. At syscall entry point: SYSCALL_DEFINE5(mremap,...) > There are two cases: Maybe we can reduce the code duplication by bringing the check if memory is sealed before call to mremap_to(). > a. going into mremap_to(). > b. not going into mremap_to(). > > 2. For mremap_to() case. > Since mremap_to() is called only from SYSCALL_DEFINE5(mremap,..), > omit changing signature of mremap_to(), i.e. not passing > checkSeals flag. > In mremap_to(), it calls can_modify_mm() for src address and > dst address (when MREMAP_FIXED is used), before any update is > made to the VMAs. > > 3. For non mremap_to() case. > It is still part of SYSCALL_DEFINE5(mremap,...). > It calls can_modify_mm() to check sealing in the src address, > before any update is made to src VMAs. > Check for dest address is not needed, because dest memory is > allocated in current mremap(2) call. > > Signed-off-by: Jeff Xu > --- > mm/mremap.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/mm/mremap.c b/mm/mremap.c > index ac363937f8c4..691fc32d37e4 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -836,7 +836,27 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len, > if ((mm->map_count + 2) >= sysctl_max_map_count - 3) > return -ENOMEM; > > + /* > + * Check src address for sealing. > + * > + * Note: mremap_to() currently called from one place: > + * SYSCALL_DEFINE4(pkey_mprotect, ...) > + * and not in any other places. > + * Therefore, omit changing the signature of mremap_to() > + * Otherwise, we might need to add checkSeals and pass it > + * from all callers of mremap_to(). > + */ > + if (!can_modify_mm(mm, addr, addr + old_len, MM_SEAL_MREMAP)) > + return -EACCES; > + > if (flags & MREMAP_FIXED) { > + /* > + * Check dest address for sealing. > + */ > + if (!can_modify_mm(mm, new_addr, new_addr + new_len, > + MM_SEAL_MREMAP)) > + return -EACCES; > + Move these two checks to just before call to mremap_to() in sys_mremap() or even earlier. Or even better move the first condition before mremap_to() and second condition can be checked before call to mremap_to(). > ret = do_munmap(mm, new_addr, new_len, uf_unmap_early); > if (ret) > goto out; > @@ -995,6 +1015,11 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, > goto out; > } > > + if (!can_modify_mm(mm, addr, addr + old_len, MM_SEAL_MREMAP)) { > + ret = -EACCES; > + goto out; > + } > + > /* > * Always allow a shrinking remap: that just unmaps > * the unnecessary pages.. -- BR, Muhammad Usama Anjum