From: Vincenzo Frascino <vincenzo.frascino@arm.com> To: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Andrey Konovalov <andreyknvl@google.com>, Leon Romanovsky <leonro@mellanox.com>, Alexander Potapenko <glider@google.com>, Catalin Marinas <catalin.marinas@arm.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Will Deacon <will@kernel.org>, Dmitry Vyukov <dvyukov@google.com>, Ard Biesheuvel <ardb@kernel.org> Subject: Re: [PATCH v2 1/2] arm64: Fix kernel address detection of __is_lm_address() Date: Thu, 21 Jan 2021 15:30:51 +0000 [thread overview] Message-ID: <95727b4c-4578-6eb5-b518-208482e8ba62@arm.com> (raw) In-Reply-To: <20210121151206.GI48431@C02TD0UTHF1T.local> On 1/21/21 3:12 PM, Mark Rutland wrote: > [adding Ard] > Thanks for this, it is related to his patch and I forgot to Cc: him directly. > On Thu, Jan 21, 2021 at 01:19:55PM +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). > > When it was added, __is_lm_address() was intended to distinguish valid > kernel virtual addresses (i.e. those in the TTBR1 address range), and > wasn't intended to do anything for addresses outside of this range. See > commit: > > ec6d06efb0bac6cd ("arm64: Add support for CONFIG_DEBUG_VIRTUAL") > > ... where it simply tests a bit. > > So I believe that it's working as intended (though this is poorly > documented), but I think you're saying that usage isn't aligned with > that intent. Given that, I'm not sure the fixes tag is right; I think it > has never had the semantic you're after. > I did not do much thinking on the intended semantics. I based my interpretation on what you are saying (the usage is not aligned with the intent). Based on what you are are saying, I will change the patch description removing the "Fix" term. > I had thought the same was true for virt_addr_valid(), and that wasn't > expected to be called for VAs outside of the kernel VA range. Is it > actually safe to call that with NULL on other architectures? > I am not sure on this, did not do any testing outside of arm64. > I wonder if it's worth virt_addr_valid() having an explicit check for > the kernel VA range, instead. > I have no strong opinion either way even if personally I feel that modifying __is_lm_address() is more clear. Feel free to propose something. >> Fix the detection checking that it's actually a kernel address starting >> at PAGE_OFFSET. >> >> Fixes: f4693c2716b35 ("arm64: mm: extend linear region for 52-bit VA configurations") >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> Cc: Will Deacon <will@kernel.org> >> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> >> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> >> --- >> arch/arm64/include/asm/memory.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h >> index 18fce223b67b..e04ac898ffe4 100644 >> --- a/arch/arm64/include/asm/memory.h >> +++ b/arch/arm64/include/asm/memory.h >> @@ -249,7 +249,7 @@ static inline const void *__tag_set(const void *addr, u8 tag) >> /* >> * The linear kernel range starts at the bottom of the virtual address space. >> */ >> -#define __is_lm_address(addr) (((u64)(addr) & ~PAGE_OFFSET) < (PAGE_END - PAGE_OFFSET)) >> +#define __is_lm_address(addr) (((u64)(addr) ^ PAGE_OFFSET) < (PAGE_END - PAGE_OFFSET)) > > If we're going to make this stronger, can we please expand the comment > with the intended semantic? Otherwise we're liable to break this in > future. > Based on your reply on the above matter, if you agree, I am happy to extend the comment. > Thanks, > Mark. > -- Regards, Vincenzo
WARNING: multiple messages have this Message-ID (diff)
From: Vincenzo Frascino <vincenzo.frascino@arm.com> To: Mark Rutland <mark.rutland@arm.com> Cc: Andrey Konovalov <andreyknvl@google.com>, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Leon Romanovsky <leonro@mellanox.com>, Alexander Potapenko <glider@google.com>, Dmitry Vyukov <dvyukov@google.com>, Catalin Marinas <catalin.marinas@arm.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 1/2] arm64: Fix kernel address detection of __is_lm_address() Date: Thu, 21 Jan 2021 15:30:51 +0000 [thread overview] Message-ID: <95727b4c-4578-6eb5-b518-208482e8ba62@arm.com> (raw) In-Reply-To: <20210121151206.GI48431@C02TD0UTHF1T.local> On 1/21/21 3:12 PM, Mark Rutland wrote: > [adding Ard] > Thanks for this, it is related to his patch and I forgot to Cc: him directly. > On Thu, Jan 21, 2021 at 01:19:55PM +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). > > When it was added, __is_lm_address() was intended to distinguish valid > kernel virtual addresses (i.e. those in the TTBR1 address range), and > wasn't intended to do anything for addresses outside of this range. See > commit: > > ec6d06efb0bac6cd ("arm64: Add support for CONFIG_DEBUG_VIRTUAL") > > ... where it simply tests a bit. > > So I believe that it's working as intended (though this is poorly > documented), but I think you're saying that usage isn't aligned with > that intent. Given that, I'm not sure the fixes tag is right; I think it > has never had the semantic you're after. > I did not do much thinking on the intended semantics. I based my interpretation on what you are saying (the usage is not aligned with the intent). Based on what you are are saying, I will change the patch description removing the "Fix" term. > I had thought the same was true for virt_addr_valid(), and that wasn't > expected to be called for VAs outside of the kernel VA range. Is it > actually safe to call that with NULL on other architectures? > I am not sure on this, did not do any testing outside of arm64. > I wonder if it's worth virt_addr_valid() having an explicit check for > the kernel VA range, instead. > I have no strong opinion either way even if personally I feel that modifying __is_lm_address() is more clear. Feel free to propose something. >> Fix the detection checking that it's actually a kernel address starting >> at PAGE_OFFSET. >> >> Fixes: f4693c2716b35 ("arm64: mm: extend linear region for 52-bit VA configurations") >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> Cc: Will Deacon <will@kernel.org> >> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> >> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> >> --- >> arch/arm64/include/asm/memory.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h >> index 18fce223b67b..e04ac898ffe4 100644 >> --- a/arch/arm64/include/asm/memory.h >> +++ b/arch/arm64/include/asm/memory.h >> @@ -249,7 +249,7 @@ static inline const void *__tag_set(const void *addr, u8 tag) >> /* >> * The linear kernel range starts at the bottom of the virtual address space. >> */ >> -#define __is_lm_address(addr) (((u64)(addr) & ~PAGE_OFFSET) < (PAGE_END - PAGE_OFFSET)) >> +#define __is_lm_address(addr) (((u64)(addr) ^ PAGE_OFFSET) < (PAGE_END - PAGE_OFFSET)) > > If we're going to make this stronger, can we please expand the comment > with the intended semantic? Otherwise we're liable to break this in > future. > Based on your reply on the above matter, if you agree, I am happy to extend the comment. > Thanks, > Mark. > -- Regards, Vincenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-21 15:28 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-21 13:19 [PATCH v2 0/2] kasan: Fix metadata detection for KASAN_HW_TAGS Vincenzo Frascino 2021-01-21 13:19 ` Vincenzo Frascino 2021-01-21 13:19 ` [PATCH v2 1/2] arm64: Fix kernel address detection of __is_lm_address() Vincenzo Frascino 2021-01-21 13:19 ` Vincenzo Frascino 2021-01-21 15:12 ` Mark Rutland 2021-01-21 15:12 ` Mark Rutland 2021-01-21 15:30 ` Vincenzo Frascino [this message] 2021-01-21 15:30 ` Vincenzo Frascino 2021-01-21 15:49 ` Mark Rutland 2021-01-21 15:49 ` Mark Rutland 2021-01-21 16:02 ` Vincenzo Frascino 2021-01-21 16:02 ` Vincenzo Frascino 2021-01-21 17:43 ` Vincenzo Frascino 2021-01-21 17:43 ` Vincenzo Frascino 2021-01-21 13:19 ` [PATCH v2 2/2] kasan: Add explicit preconditions to kasan_report() Vincenzo Frascino 2021-01-21 13:19 ` Vincenzo Frascino 2021-01-21 17:20 ` Andrey Konovalov 2021-01-21 17:20 ` Andrey Konovalov 2021-01-22 14:32 ` Vincenzo Frascino 2021-01-22 14:32 ` Vincenzo Frascino
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=95727b4c-4578-6eb5-b518-208482e8ba62@arm.com \ --to=vincenzo.frascino@arm.com \ --cc=andreyknvl@google.com \ --cc=ardb@kernel.org \ --cc=aryabinin@virtuozzo.com \ --cc=catalin.marinas@arm.com \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=kasan-dev@googlegroups.com \ --cc=leonro@mellanox.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.