lkml.org 
[lkml]   [2022]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH AUTOSEL 5.19 05/58] arm64: kernel: drop unnecessary PoC cache clean+invalidate
On Mon, 8 Aug 2022 at 03:31, Sasha Levin <sashal@kernel.org> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> [ Upstream commit 2e945851e26836c0f2d34be3763ddf55870e49fe ]
>
> Some early boot code runs before the virtual placement of the kernel is
> finalized, and we used to go back to the very start and recreate the ID
> map along with the page tables describing the virtual kernel mapping,
> and this involved setting some global variables with the caches off.
>
> In order to ensure that global state created by the KASLR code is not
> corrupted by the cache invalidation that occurs in that case, we needed
> to clean those global variables to the PoC explicitly.
>
> This is no longer needed now that the ID map is created only once (and
> the associated global variable updates are no longer repeated). So drop
> the cache maintenance that is no longer necessary.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Link: https://lore.kernel.org/r/20220624150651.1358849-9-ardb@kernel.org
> Signed-off-by: Will Deacon <will@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

NAK

This patch *must* *not* be backported. It will break the boot.

And again, *please* stop spamming people with broken backports like this.

Can you explain why it is justified to use a bot to generate hundreds
of patches, and leave it to overloaded maintainers to spot the ones
that are broken? Is it because your time is more valuable than mine?

I have already asked (and you have already agreed) to disregard all
patches authored by me from this broken-by-design process. But here we
are, with yet another set of broken patches queued up all the way back
to v5.15.

So please, don't use AUTOSEL on *any* patch that was authored by me. I
understand the concept of a -stable kernel. I known what cc:stable
means. I know that a fixes: tag means. I don't need help from your
bot, it is only causing grief.

Thanks,
Ard.


> ---
> arch/arm64/kernel/kaslr.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
> index 418b2bba1521..d5542666182f 100644
> --- a/arch/arm64/kernel/kaslr.c
> +++ b/arch/arm64/kernel/kaslr.c
> @@ -13,7 +13,6 @@
> #include <linux/pgtable.h>
> #include <linux/random.h>
>
> -#include <asm/cacheflush.h>
> #include <asm/fixmap.h>
> #include <asm/kernel-pgtable.h>
> #include <asm/memory.h>
> @@ -72,9 +71,6 @@ u64 __init kaslr_early_init(void)
> * we end up running with module randomization disabled.
> */
> module_alloc_base = (u64)_etext - MODULES_VSIZE;
> - dcache_clean_inval_poc((unsigned long)&module_alloc_base,
> - (unsigned long)&module_alloc_base +
> - sizeof(module_alloc_base));
>
> /*
> * Try to map the FDT early. If this fails, we simply bail,
> @@ -174,13 +170,6 @@ u64 __init kaslr_early_init(void)
> module_alloc_base += (module_range * (seed & ((1 << 21) - 1))) >> 21;
> module_alloc_base &= PAGE_MASK;
>
> - dcache_clean_inval_poc((unsigned long)&module_alloc_base,
> - (unsigned long)&module_alloc_base +
> - sizeof(module_alloc_base));
> - dcache_clean_inval_poc((unsigned long)&memstart_offset_seed,
> - (unsigned long)&memstart_offset_seed +
> - sizeof(memstart_offset_seed));
> -
> return offset;
> }
>
> --
> 2.35.1
>

\
 
 \ /
  Last update: 2022-08-08 11:06    [W:0.192 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site