Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3750861pxb; Tue, 26 Jan 2021 03:56:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJyWL+hylbyZEJU68NTLwAKF/f89OyC3r77qcbD5CNguCxw9NCBxunO22no/53wrwDyrL/5c X-Received: by 2002:a17:906:6d44:: with SMTP id a4mr3417105ejt.453.1611662177281; Tue, 26 Jan 2021 03:56:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611662177; cv=none; d=google.com; s=arc-20160816; b=luhm9/UC3uc2wEzL0vkCe7p2oly1X9s49joApoc0IboEwz1CHMQmuP0Lm9FZ0c4m+s jL0OnR539pHJedPnHPfkMb6SFWDMwaB5VNf+mLMrK8dXfRrx3tqCYUi8IRURcYWIHU26 u4ipLybrIUfrgc6aZnf8xfaG049U8m65kc+vAcn5wbtQ/tOGGJgkyuvUDNzXED/Rw+ev ffKwNcsFCdBMpekw/y80OZHjLCxI6nWEH5iE1rWkxSVufhgJWXACzhRpXR6M39AwfZyn mBDsdqsSqCBctV20JaP/+xMKWU+aCQtZE5kRv37UFqVdh/QVRRhXw0Y+CW0O4em2qNpt lVjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=PXqQGPq3ll7UHp9/4NpsEU4ZHUtPgKgCmbAW8ARI7Jk=; b=qGvYBny32Ni2uDgjct9mzvT/WLT4E513jtqrBacyMJI4jYvh73QFD3pSCL/3tvCD24 F5uvvQIWTd9WlmvFBzHf50x90tiLoYJHJv6Zx/7FypUyopIDnK2uXZWjsMSHNNloHJC0 88AXsGob1jRPu8ZCDr+kE5/fxsizWQ8eW+Jat7W/Z4h5MxmjakBehEFvxxL1csIUOHLN gKDkqeuayiDpSNsz521ypQ79Px/op+/DTRCKsLStdj1XdZ+W0lurGVRisAEjisffHyQb +Xb05J/nuSEUBfEppmu3OMEQq5pI0PmfDVMtnCXOMG0JXkPM43/E+lVZ760WAK8cnElb k7wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb22si8459445edb.112.2021.01.26.03.55.52; Tue, 26 Jan 2021 03:56:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392578AbhAZLzP (ORCPT + 99 others); Tue, 26 Jan 2021 06:55:15 -0500 Received: from foss.arm.com ([217.140.110.172]:35864 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405015AbhAZLzI (ORCPT ); Tue, 26 Jan 2021 06:55:08 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5924D101E; Tue, 26 Jan 2021 03:54:22 -0800 (PST) Received: from [10.37.12.25] (unknown [10.37.12.25]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EA0703F66B; Tue, 26 Jan 2021 03:54:19 -0800 (PST) Subject: Re: [PATCH v4 1/3] arm64: Improve kernel address detection of __is_lm_address() To: Catalin Marinas Cc: Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Leon Romanovsky , Andrey Konovalov , Will Deacon , "Paul E . McKenney" , Naresh Kamboju References: <20210122155642.23187-1-vincenzo.frascino@arm.com> <20210122155642.23187-2-vincenzo.frascino@arm.com> <20210125130204.GA4565@C02TD0UTHF1T.local> <20210125145911.GG25360@gaia> <4bd1c01b-613c-787f-4363-c55a071f14ae@arm.com> <20210125175630.GK25360@gaia> From: Vincenzo Frascino Message-ID: <62348cb4-0b2e-e17a-d930-8d41dc4200d3@arm.com> Date: Tue, 26 Jan 2021 11:58:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210125175630.GK25360@gaia> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/25/21 5:56 PM, Catalin Marinas wrote: > On Mon, Jan 25, 2021 at 04:09:57PM +0000, Vincenzo Frascino wrote: >> On 1/25/21 2:59 PM, Catalin Marinas wrote: >>> On Mon, Jan 25, 2021 at 02:36:34PM +0000, Vincenzo Frascino wrote: >>>> On 1/25/21 1:02 PM, Mark Rutland wrote: >>>>> On Fri, Jan 22, 2021 at 03:56:40PM +0000, Vincenzo Frascino wrote: >>>>>> Currently, the __is_lm_address() check just masks out the top 12 bits >>>>>> of the address, but if they are 0, it still yields a true result. >>>>>> This has as a side effect that virt_addr_valid() returns true even for >>>>>> invalid virtual addresses (e.g. 0x0). >>>>>> >>>>>> Improve the detection checking that it's actually a kernel address >>>>>> starting at PAGE_OFFSET. >>>>>> >>>>>> Cc: Catalin Marinas >>>>>> Cc: Will Deacon >>>>>> Suggested-by: Catalin Marinas >>>>>> Reviewed-by: Catalin Marinas >>>>>> Signed-off-by: Vincenzo Frascino >>>>> >>>>> Looking around, it seems that there are some existing uses of >>>>> virt_addr_valid() that expect it to reject addresses outside of the >>>>> TTBR1 range. For example, check_mem_type() in drivers/tee/optee/call.c. >>>>> >>>>> Given that, I think we need something that's easy to backport to stable. >>>>> >>>> >>>> I agree, I started looking at it this morning and I found cases even in the main >>>> allocators (slub and page_alloc) either then the one you mentioned. >>>> >>>>> This patch itself looks fine, but it's not going to backport very far, >>>>> so I suspect we might need to write a preparatory patch that adds an >>>>> explicit range check to virt_addr_valid() which can be trivially >>>>> backported. >>>>> >>>> >>>> I checked the old releases and I agree this is not back-portable as it stands. >>>> I propose therefore to add a preparatory patch with the check below: >>>> >>>> #define __is_ttrb1_address(addr) ((u64)(addr) >= PAGE_OFFSET && \ >>>> (u64)(addr) < PAGE_END) >>>> >>>> If it works for you I am happy to take care of it and post a new version of my >>>> patches. >>> >>> I'm not entirely sure we need a preparatory patch. IIUC (it needs >>> checking), virt_addr_valid() was fine until 5.4, broken by commit >>> 14c127c957c1 ("arm64: mm: Flip kernel VA space"). Will addressed the >>> flip case in 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using >>> __is_lm_address()") but this broke the >> NULL address is considered valid. >>> >>> Ard's commit f4693c2716b3 ("arm64: mm: extend linear region for 52-bit >>> VA configurations") changed the test to no longer rely on va_bits but >>> did not change the broken semantics. >>> >>> If Ard's change plus the fix proposed in this test works on 5.4, I'd say >>> we just merge this patch with the corresponding Cc stable and Fixes tags >>> and tweak it slightly when doing the backports as it wouldn't apply >>> cleanly. IOW, I wouldn't add another check to virt_addr_valid() as we >>> did not need one prior to 5.4. >> >> Thank you for the detailed analysis. I checked on 5.4 and it seems that Ard >> patch (not a clean backport) plus my proposed fix works correctly and solves the >> issue. > > I didn't mean the backport of the whole commit f4693c2716b3 as it > probably has other dependencies, just the __is_lm_address() change in > that patch. > Then call it preparatory patch ;) >> Tomorrow I will post a new version of the series that includes what you are >> suggesting. > > Please post the __is_lm_address() fix separately from the kasan patches. > I'll pick it up as a fix via the arm64 tree. The kasan change can go in > 5.12 since it's not currently broken but I'll leave the decision with > Andrey. > Ok, will do. -- Regards, Vincenzo