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 B480FC636D4 for ; Tue, 14 Feb 2023 01:56:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19D6F6B0073; Mon, 13 Feb 2023 20:56:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 14E0E280002; Mon, 13 Feb 2023 20:56:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 014FA280001; Mon, 13 Feb 2023 20:56:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E602F6B0073 for ; Mon, 13 Feb 2023 20:56:44 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AD2341607A8 for ; Tue, 14 Feb 2023 01:56:44 +0000 (UTC) X-FDA: 80464233528.23.244E40F Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf05.hostedemail.com (Postfix) with ESMTP id E2358100010 for ; Tue, 14 Feb 2023 01:56:41 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WukYlK+o; spf=pass (imf05.hostedemail.com: domain of pcc@google.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676339801; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8JwtFQD8SoayVtxvpf9Tvl5oCjOJCdMofv2mGIfAKNU=; b=JoQVhbrZXr539SlKvTlZje+xsmfh92ka9s2OW/w9+ovHqecyK0I3MoYLpMuKQ4VVlT43ov xxn6gzlArJR/j9n5kpGBSEpA2QGatBb4sJUcjkHFCjLPLiHVYEh9kGpPNkLYc8IzLn+8or ZCVbF2239fIUmwlYI2/nor9qx8CG2KM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WukYlK+o; spf=pass (imf05.hostedemail.com: domain of pcc@google.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676339801; a=rsa-sha256; cv=none; b=kpqnNCENMprqBovpp74hVRm54S3Kp6TG63V8eKC0JB4efZMmgUDydKLolmvQVqybGohuFE gV6+skGZJ9ugONfg/2KNwbUo/vOa5Wp/a+Cgv37M1RC1odUtDX0pzFw5Nl8c6uf9KoszdB 45AQCS1RcIZdmCah8hAQCau8IitfG34= Received: by mail-vk1-f181.google.com with SMTP id bs10so7253385vkb.3 for ; Mon, 13 Feb 2023 17:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1676339801; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8JwtFQD8SoayVtxvpf9Tvl5oCjOJCdMofv2mGIfAKNU=; b=WukYlK+o87DNK+Tb/rp7p/vq74KXUh5hhMXfFYGS95zecSP9hVZ+kPAvbZaR/3hxqM 7oYdTAHVeWmBoTld4RTYAoJ7TknPluk2vLb+NvnOASevqe8Lvsu0tOdbgea4B+sn7yZp EMWdSfxpiDfqMM+4cVk+nb/A5+7vYSDyFV7J40BjApvSeSnJVWBUj0HlWnAjAB/Tb77C 3IGQ3WqgAHN7iaFeKR/JlcWiSPGwvUE5PrdPWTJiqcrb0xpwa68+5/4co3W2+yb3QgFU vPYlyc9vaz26ySIDlirR8qKExKrQRRbveYiOv0Xz0AH88UJMqrkshwhJMdJ97q4i6oah OkHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676339801; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8JwtFQD8SoayVtxvpf9Tvl5oCjOJCdMofv2mGIfAKNU=; b=NWZ7C3WJzFtDFoz5KSXzUkN5pH1Y0x46eMnB2YMrq6nhoyXt3sy9dLIlCHbgZBshlF WXyH6M7Uv+Ec7dErr7vIzh8N/I+WgJytG/QbtcW72f51Sofy/yU5VoMkEE0dPGO+dapg +NOL0/iGBGnilh+mlQMFy8W4eoTpjP6TEapTCcDQ3SV20bxfmR2cWL6M+pKGVbl5dtC0 3qARMiXxYhnw7/RKfyNe8EZ0/fU5UO+tqZRxB4kyV5KsLlWu1aEl24A6wZ7kCxVFm9qK 30EEnJx0JkbL4S8a94lI8OtOch4ivgSgNnjOOY6UMY5Vj6vmuEuuRRuFZwoXw3I/bkbC dpDA== X-Gm-Message-State: AO0yUKVGpOYi5c5KNAZZboVyN6uu0ZD4LjbUCYum9VMwG2OFp172doHL wqd6q9BjwxJ/nDg2k6/TtW3L8jTCSp/gPG+ilA5qBg== X-Google-Smtp-Source: AK7set9aqNDyWNtq1Vea2KNA0zDrJxSgotDJvCTEo43Onzx35+8gYI51K0AjPEkE/I0qvwqb/rx/RGZv4dE+iewEyKo= X-Received: by 2002:a1f:7f1c:0:b0:401:87ef:e516 with SMTP id o28-20020a1f7f1c000000b0040187efe516mr86906vki.16.1676339800880; Mon, 13 Feb 2023 17:56:40 -0800 (PST) MIME-Version: 1.0 References: <20220610152141.2148929-1-catalin.marinas@arm.com> <66cc7277b0e9778ba33e8b22a4a51c19a50fe6f0.camel@mediatek.com> In-Reply-To: From: Peter Collingbourne Date: Mon, 13 Feb 2023 17:56:29 -0800 Message-ID: Subject: Re: [PATCH v2 0/4] kasan: Fix ordering between MTE tag colouring and page->flags To: Catalin Marinas Cc: =?UTF-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= , "andreyknvl@gmail.com" , =?UTF-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= , =?UTF-8?B?R3Vhbmd5ZSBZYW5nICjmnajlhYnkuJop?= , "linux-mm@kvack.org" , =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , "kasan-dev@googlegroups.com" , "ryabinin.a.a@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "vincenzo.frascino@arm.com" , "will@kernel.org" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: ynomapqwwxb6jywa99j67ke8ao58fjzc X-Rspam-User: X-Rspamd-Queue-Id: E2358100010 X-Rspamd-Server: rspam06 X-HE-Tag: 1676339801-335239 X-HE-Meta: U2FsdGVkX1/kXrXeHGfd9EN3z+PTTM6WNJABiCo57+ggIYFP5s1fWIJYwEl3gvd1Lf1qMHWeI5X/MzELHxgi3npY8WHYwblhlIhM60e2tPqs6CWQyoRmSs6t/lDXZEKR+a+j2d+QfFhHKYOPJ11Pmp0IxVe7+UqjUjUGut31cbxNGCUKs5tsEipayDrfis3z+exw+pTWfAR+oi5bHMLfxI2CFCRHcVKG2w8e1zlHP+edfpjYepqFVRM6mdoLtEzwzSD13WwjcXF8cBk7nDCwPXIxVK/9ta9yWs7ihOvA/nlLNJYQwUADoDxhTgAN98eu9YrwlG5gaSxrE4HLKvunDLA3FW+u7vmU1FWoxlcwaoEZ5sI+F6uQkBXdUCj6DiUNuzG6QOxqf863nFErvMPL8aYHTUftNgzXzqwOO3tX2DCUEhK9HNZm7pablD0x0LeOfYNxhcrL8Sp1Ue7jpHmOLmTRWr0d3ZWSJp33u9htGP3GhYodczg0d4G3hsG1A3LlcWMzw8haqXEd9X+DQ29A1iJkn3aJ3hRXmXZ/8uN/s8JRe/z9Er4gxeyRYQ5xTg9crQv3zNboNLssubY9YePVxyuHL7DE9M0FrdaDh+spMt2aBagj7ZkFG5pjpCjN/Wd8UhAFf3ipiF7A2BOOQ1ug/yniZ6gTSMA8XEP+ee7M8Njvpd4cgk9K//X4TI7IB2jcAnKBDYAVWUVD+wGC8gn5z4ciYhFjvsoCL+96crW817QXUvwCth+NIqH4oUnZ4yMiCPLHQ/3Syg2fZ3tJj79pXaVZ8VvNaWHG3mxkJ3pawdcIqIzfkeybDKfNiltCBWHjaACHVNO/4LkUKdWAjHcKkdxIfU5aU4mD6sp0zH/V3uCGrOz15Cr5oe+n88mQJJu6KRT8Tvb6R3aB3d/GdbL4j1uOkkuqpp+mwCLOIHcRqzngfIP9LJsLvTqSk+p6q4ajf63UlqSUjjgjhutcaHI Q2RmW9ta 4f8FALxot8mF/7cGN/CgFoRp3Khrt4jBFhccxvb+UOm87z7UPcJc48QbK7Z6WVbCEH7LmDi4MyhUq1u8Kdk7XVfVnJiC/UUqkpsjYlhp+/ZD5br6pQhazKfuhX//+z+WIALF4m5ej3G+AQhmtliGFR0ZKdxSI6woYKK2G5C9x8asgSbQ4e5zCl+EZi4Yi+54DDjFnuChPKuwrjr0HqnhGpEQcGEtuDqTgnF8i+ldEa44kwEM6lg+RcD0p4DdJmmZRX6w2AkFdbY1pZd0YzMKHxpnnquVc2ohdzU8fMFYjq+/R0hj1HwHRuQEBqGULfzXOmv+n+E7kpMw4ylc7qemqM5HYCRD4DAlSJx52Awmi9ZxUshIywEVyrr+exNIf+IkEvXyjBNRMjKG9Jw7vrXRQfgfOyY+rFgiUAO068Np4KwL8Fzb5Cw5QyO5IMh6VR9mFM1BP1rSETCqzjftbdHptvdxJT6ehJ6RA5dbErGPbddsxqERjShabM1Fb/w== 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 Mon, Feb 13, 2023 at 10:47 AM Catalin Marinas wrote: > > On Fri, Feb 10, 2023 at 11:03:45AM -0800, Peter Collingbourne wrote: > > On Fri, Feb 10, 2023 at 10:28 AM Catalin Marinas > > wrote: > > > On Thu, Feb 09, 2023 at 10:19:20PM -0800, Peter Collingbourne wrote: > > > > Thanks for the information. We encountered a similar issue internally > > > > with the Android 5.15 common kernel. We tracked it down to an issue > > > > with page migration, where the source page was a userspace page with > > > > MTE tags, and the target page was allocated using KASAN (i.e. having > > > > a non-zero KASAN tag). This caused tag check faults when the page was > > > > subsequently accessed by the kernel as a result of the mismatching tags > > > > from userspace. Given the number of different ways that page migration > > > > target pages can be allocated, the simplest fix that we could think of > > > > was to synchronize the KASAN tag in copy_highpage(). > > > > > > > > Can you try the patch below and let us know whether it fixes the issue? > > > > > > > > diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c > > > > index 24913271e898c..87ed38e9747bd 100644 > > > > --- a/arch/arm64/mm/copypage.c > > > > +++ b/arch/arm64/mm/copypage.c > > > > @@ -23,6 +23,8 @@ void copy_highpage(struct page *to, struct page *from) > > > > > > > > if (system_supports_mte() && test_bit(PG_mte_tagged, &from->flags)) { > > > > set_bit(PG_mte_tagged, &to->flags); > > > > + if (kasan_hw_tags_enabled()) > > > > + page_kasan_tag_set(to, page_kasan_tag(from)); > > > > mte_copy_page_tags(kto, kfrom); > > > > > > Why not just page_kasan_tag_reset(to)? If PG_mte_tagged is set on the > > > 'from' page, the tags are random anyway and page_kasan_tag(from) should > > > already be 0xff. It makes more sense to do the same for the 'to' page > > > rather than copying the tag from the 'from' page. IOW, we are copying > > > user-controlled tags into a page, the kernel should have a match-all tag > > > in page->flags. > > > > That would also work, but I was thinking that if copy_highpage() were > > being used to copy a KASAN page we should keep the original tag in > > order to maintain tag checks for page accesses. > > If PG_mte_tagged is set on the source, it means that the tags are no > longer trusted and we should reset to match-all. Otherwise if > copy_highpage() is called on a page that was never mapped as PROT_MTE in > user space, PG_mte_tagged would not be set on the source and no tags > copied. In such case, we should keep the original KASAN tag in the > destination. Unless I misunderstood what you meant. I was thinking that it might be possible for PG_mte_tagged to be set on a page with KASAN tags. But as far as I can tell, this isn't actually possible (or not intended to be possible, at least). So I agree, we can just call page_kasan_tag_reset() here. Patch sent (with stable backport instructions) here: https://lore.kernel.org/all/20230214015214.747873-1-pcc@google.com/ Peter