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 59E59C61DA4 for ; Thu, 9 Mar 2023 11:10:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC92B6B0071; Thu, 9 Mar 2023 06:10:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7942280001; Thu, 9 Mar 2023 06:10:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D41A26B0075; Thu, 9 Mar 2023 06:10:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C6F366B0071 for ; Thu, 9 Mar 2023 06:10:05 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8AF26C084C for ; Thu, 9 Mar 2023 11:10:05 +0000 (UTC) X-FDA: 80549090370.17.5EC5ABF Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf13.hostedemail.com (Postfix) with ESMTP id A99452001C for ; Thu, 9 Mar 2023 11:10:03 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Tbn0PJXv; spf=pass (imf13.hostedemail.com: domain of elver@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=elver@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=1678360203; 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=sHADsOZhE0a7TvE3AcZTPLBcjUVYE5zGjZn3DjfnMYk=; b=Prgl7Mf04x4MosGfNCXH1VpnPo9K2f7AHR0g3lRm+i8bSpMrXxhC4yUm9NYkxxamb5fK2p 9tXiCX6J9QLIRMzQivfHQgPnyBrULuxhtsqXvjO+JKk+YzRE1LyzlOgswZm7iJiph93ohC RmLU+AJvPkREfv9Zi7XNsoaVI5rPkNU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Tbn0PJXv; spf=pass (imf13.hostedemail.com: domain of elver@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678360203; a=rsa-sha256; cv=none; b=3zKPTNqL9a1C9lew8pt2GrykLIz2+F7gzlXOyL4H4LTDVv/iXrkpOa2O1+/yVilZQxXEtO RK9VATnJDcWsed0ySmG/db2zxxOaOg7F+eUkm/1tgIfjR0wvGzXR/EmD76yc6U2sTyojKh nkqXG2M/olkgAomfGLD5LzAhTo5hsZY= Received: by mail-vs1-f52.google.com with SMTP id f23so1215648vsa.13 for ; Thu, 09 Mar 2023 03:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678360202; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sHADsOZhE0a7TvE3AcZTPLBcjUVYE5zGjZn3DjfnMYk=; b=Tbn0PJXvrbLYEE1IHpIxs4Fi7EVSZhswVSAsGnPycMroxj688/6XN76SvwwfGGIJdJ +fO7+iIAV5NO6vDvRGmj++0cUP5tL+mkFSPfpG2coMQ04g2aOuvfzsicRzy6E6fhYzW3 hI2efMFHapqPLtYHBjPsFVEOrl+Fw88CWff55SMDMsC0hMzMbg7ZYHDb4Q0vlhFALsyV B1LX7QqCRETp9R4kYdD7tFS+1KWbNgG0HLPdDtid7MyAJul9eAnEKtOTGu3UjAxddln4 lhgnXqZzxY2AYwUSvSmQ7te/HBtgIBidGcPAKxay7WHIlUho6sXIIzjNVhPbvcE+V/0H ZVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678360202; 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=sHADsOZhE0a7TvE3AcZTPLBcjUVYE5zGjZn3DjfnMYk=; b=jXbGKvx9Huq1cqS+W2C8QFRtWNOL9D0FolmEFj7OMVAI22sjfxOVuPECtm0tH9JjNU LhiunDTtzqkzFhD2OzMty0sAJ2yuhhoMbqngyQDZIcDHC0oJGIoCO+JEmy5cGlxQFZQe p75SgQF4UHLSLW/Rxy+uFX7o0rG5xm6XV98Beg5jYzdV1fzosfQZprCfkqnU/hxoXqNE PeSf8heGakrCcr7Mv6gU6KGQQj3b/biMV+ozQjSpiLN3GEMCm2nmSVqxSobLU0n7eh44 QrCB/vzIdzNX5csc4RxmojQ/1UQpoqJ9bzrNYJ6nWW714tBIPjTPx+Po1+Np1FQMIQq9 PxdA== X-Gm-Message-State: AO0yUKX4A/vsTKV61lP11cC08Qgb18IFccgsQwrzl+9YBH5/wOGCb+wU 0Pk+XOIzArL5QzZlnIW25FEuClyglI89rAwGC/a9sA== X-Google-Smtp-Source: AK7set/HSM9pFRwqx+oE+U+5fDrK1oJ++btyhJQ14pL2r7vOVZZ8ghChTJ7FBqMN73v+DZpAQvxVU43poPiIEJ1gz0M= X-Received: by 2002:a67:ce0a:0:b0:416:e50f:8215 with SMTP id s10-20020a67ce0a000000b00416e50f8215mr14235184vsl.4.1678360202503; Thu, 09 Mar 2023 03:10:02 -0800 (PST) MIME-Version: 1.0 References: <1678349122-19279-1-git-send-email-quic_zhenhuah@quicinc.com> <706340ef-1745-c1e4-be4d-358d5db4c05e@quicinc.com> In-Reply-To: <706340ef-1745-c1e4-be4d-358d5db4c05e@quicinc.com> From: Marco Elver Date: Thu, 9 Mar 2023 12:09:22 +0100 Message-ID: Subject: Re: [PATCH] mm,kfence: decouple kfence from page granularity mapping judgement To: Zhenhua Huang Cc: catalin.marinas@arm.com, will@kernel.org, glider@google.com, dvyukov@google.com, akpm@linux-foundation.org, robin.murphy@arm.com, mark.rutland@arm.com, jianyong.wu@arm.com, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, quic_pkondeti@quicinc.com, quic_guptap@quicinc.com, quic_tingweiz@quicinc.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A99452001C X-Stat-Signature: 4rjt1aci8r8gysx6cnadyzjb5rcdx3if X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678360203-619321 X-HE-Meta: U2FsdGVkX18WmxS2btvbB1vVQXw30x5VOI+OGNP4aC6riDS6u/OI434K7NeSzYAcke1IU1vb9fwTTwXl+amjlEy01NzyXOJCZF84Fr5L5UsnmK/SuBwamMWPt37eLNQ5uDcrg8oTxMZSGLZyK5ySobSUYXAr8qmJ0RfRRD/XRHkfASFrcW/aF1L84ofFyy8QFEfR9cOfdwWTL+I8jiDkqveNyYXShHTKvA9aVO5GI3os6hM+7PpqIDaf3BsMwkK0uI3orczLe4KPORc536nz8moPi9FksPstFP4dppQd1opnP4IsRJLaeYwrg+93LuBIStNWjlMhvJFD5J7XekhyFooV4lizY5SXPPGYINqtxN9PLYpEI1iakR2Icyl0/d0zHA1qb4SYe0M3/QPd8ghEcllKGwt7clJSSGRUAO09EeXFxIIqLsKAKOJaPmQGbRt3Dev1fx2TAQCZHVs+I5aWxXa1iNBsWeIBqh11RDeDw9qNLb7+v7ajNfBWnANp9JDqybEcJr5lxndSw1sbhTmZjcxwnrY1vhkLc/oc0w5UyLnhWe5HYDdZZvym1DoppJNINX2hNYYYJTW7waa6IECaTK1kwtpzRNoIXkLQh3BplZrvs0CToF118loJNCS73JNNTvXJ15HqE6fDNv68zGwyV8yylqdqwlRXvo5/AUJDTHskJudYtBPviGA0gQAyzlZ9hSvq0hiJH0EDNTFetzfwwB8NdvZR+MuSz/qXT3hwvORxljLgv0HZDlFL0KqrD4Sas8WyRxxxSETfPKtT18mPYA/rVV6bB4IOwo/4Fx9PmMNkZuyBI7gHnXs9MAiu4wutCNvlDLGKOeKFJ/yhFAZ3JhK/CntvOuZdnNloB+ArVw79+gwkhOHMHyFs/y33kv6T/fb5VgFLi5665i8ny2CqektXe1OvqIEYnZPMma5FPqq5tP3zV3fkxNjCrhMmeCXhHWCmToaTx2lwr9Stnwn rqSpvhyz D7LBjZNxOIMMlPPUcrMWau3WzIjatwTZPQvM72SGcUKou1NBq5dRhLa1yxUinV/Ojp3TAUS89JUSvMfuJePao5J1cNwjFxjW6snyxlrDodB7om7SBTzjj3CL4CLK5lknbuwM0Lc0xf23Zs43F9/eOKAKgMo2DGNr1t5TBHPmUVEbtyn1X8lWySc4BuECFZqeT7la/Fov4gMXZMWSEk1hOpc8/dk8WHsKm9uIM56Z1tClOij+j6FcznB2i77f+jsmuFRd9WOuSivxWn0f6j06TQJ7jwTG+5PQjogbXl7MCLZz5o/m9SWh11q9FCcFjL0kzjU/n/QoV8TRnQSCUUFTaDZFuaX90TCPTjfvPcdD0FZj3hLVJ4FsQkuZKlRcaG2G12jWOmAVBJSaEBlrmsTlbumcvXIhO9jv2BV3C4c7Atj4/NA0= 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 Thu, 9 Mar 2023 at 12:04, Zhenhua Huang wrote: > > Thanks Marco. > > On 2023/3/9 18:33, Marco Elver wrote: > > On Thu, 9 Mar 2023 at 09:05, Zhenhua Huang wrote: > >> > >> Kfence only needs its pool to be mapped as page granularity, previous > >> judgement was a bit over protected. Decouple it from judgement and do > >> page granularity mapping for kfence pool only [1]. > >> > >> To implement this, also relocate the kfence pool allocation before the > >> linear mapping setting up, kfence_alloc_pool is to allocate phys addr, > >> __kfence_pool is to be set after linear mapping set up. > >> > >> LINK: [1] https://lore.kernel.org/linux-arm-kernel/1675750519-1064-1-git-send-email-quic_zhenhuah@quicinc.com/T/ > >> Suggested-by: Mark Rutland > >> Signed-off-by: Zhenhua Huang > >> --- > >> arch/arm64/mm/mmu.c | 24 ++++++++++++++++++++++++ > >> arch/arm64/mm/pageattr.c | 5 ++--- > >> include/linux/kfence.h | 10 ++++++++-- > >> init/main.c | 1 - > >> mm/kfence/core.c | 18 ++++++++++++++---- > >> 5 files changed, 48 insertions(+), 10 deletions(-) > >> > >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > >> index 6f9d889..bd79691 100644 > >> --- a/arch/arm64/mm/mmu.c > >> +++ b/arch/arm64/mm/mmu.c > >> @@ -24,6 +24,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #include > >> #include > >> @@ -532,6 +533,9 @@ static void __init map_mem(pgd_t *pgdp) > >> phys_addr_t kernel_end = __pa_symbol(__init_begin); > >> phys_addr_t start, end; > >> int flags = NO_EXEC_MAPPINGS; > >> +#ifdef CONFIG_KFENCE > >> + phys_addr_t kfence_pool = 0; > >> +#endif > >> u64 i; > >> > >> /* > >> @@ -564,6 +568,12 @@ static void __init map_mem(pgd_t *pgdp) > >> } > >> #endif > >> > >> +#ifdef CONFIG_KFENCE > >> + kfence_pool = kfence_alloc_pool(); > >> + if (kfence_pool) > >> + memblock_mark_nomap(kfence_pool, KFENCE_POOL_SIZE); > >> +#endif > >> + > >> /* map all the memory banks */ > >> for_each_mem_range(i, &start, &end) { > >> if (start >= end) > >> @@ -608,6 +618,20 @@ static void __init map_mem(pgd_t *pgdp) > >> } > >> } > >> #endif > >> + > >> + /* Kfence pool needs page-level mapping */ > >> +#ifdef CONFIG_KFENCE > >> + if (kfence_pool) { > >> + __map_memblock(pgdp, kfence_pool, > >> + kfence_pool + KFENCE_POOL_SIZE, > >> + pgprot_tagged(PAGE_KERNEL), > >> + NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); > >> + memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE); > >> + /* kfence_pool really mapped now */ > >> + kfence_set_pool(kfence_pool); > >> + } > >> +#endif > >> + > >> } > >> > >> void mark_rodata_ro(void) > >> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c > >> index 79dd201..61156d0 100644 > >> --- a/arch/arm64/mm/pageattr.c > >> +++ b/arch/arm64/mm/pageattr.c > >> @@ -22,12 +22,11 @@ bool rodata_full __ro_after_init = IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED > >> bool can_set_direct_map(void) > >> { > >> /* > >> - * rodata_full, DEBUG_PAGEALLOC and KFENCE require linear map to be > >> + * rodata_full and DEBUG_PAGEALLOC require linear map to be > >> * mapped at page granularity, so that it is possible to > >> * protect/unprotect single pages. > >> */ > >> - return (rodata_enabled && rodata_full) || debug_pagealloc_enabled() || > >> - IS_ENABLED(CONFIG_KFENCE); > >> + return (rodata_enabled && rodata_full) || debug_pagealloc_enabled(); > >> } > >> > >> static int change_page_range(pte_t *ptep, unsigned long addr, void *data) > >> diff --git a/include/linux/kfence.h b/include/linux/kfence.h > >> index 726857a..0252e74 100644 > >> --- a/include/linux/kfence.h > >> +++ b/include/linux/kfence.h > >> @@ -61,7 +61,12 @@ static __always_inline bool is_kfence_address(const void *addr) > >> /** > >> * kfence_alloc_pool() - allocate the KFENCE pool via memblock > >> */ > >> -void __init kfence_alloc_pool(void); > >> +phys_addr_t __init kfence_alloc_pool(void); > >> + > >> +/** > >> + * kfence_set_pool() - KFENCE pool mapped and can be used > >> + */ > >> +void __init kfence_set_pool(phys_addr_t addr); > >> > >> /** > >> * kfence_init() - perform KFENCE initialization at boot time > >> @@ -223,7 +228,8 @@ bool __kfence_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *sla > >> #else /* CONFIG_KFENCE */ > >> > >> static inline bool is_kfence_address(const void *addr) { return false; } > >> -static inline void kfence_alloc_pool(void) { } > >> +static inline phys_addr_t kfence_alloc_pool(void) { return (phys_addr_t)NULL; } > >> +static inline void kfence_set_pool(phys_addr_t addr) { } > >> static inline void kfence_init(void) { } > >> static inline void kfence_shutdown_cache(struct kmem_cache *s) { } > >> static inline void *kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags) { return NULL; } > >> diff --git a/init/main.c b/init/main.c > >> index 4425d17..9aaf217 100644 > >> --- a/init/main.c > >> +++ b/init/main.c > >> @@ -839,7 +839,6 @@ static void __init mm_init(void) > >> */ > >> page_ext_init_flatmem(); > >> init_mem_debugging_and_hardening(); > >> - kfence_alloc_pool(); > > > > This breaks other architectures. > > Nice catch. Thanks! > > > > >> report_meminit(); > >> kmsan_init_shadow(); > >> stack_depot_early_init(); > >> diff --git a/mm/kfence/core.c b/mm/kfence/core.c > >> index 5349c37..dd5cdd5 100644 > >> --- a/mm/kfence/core.c > >> +++ b/mm/kfence/core.c > >> @@ -809,15 +809,25 @@ static void toggle_allocation_gate(struct work_struct *work) > >> > >> /* === Public interface ===================================================== */ > >> > >> -void __init kfence_alloc_pool(void) > >> +phys_addr_t __init kfence_alloc_pool(void) > >> { > > > > You could just return here: > > > > if (__kfence_pool) > > return; /* Initialized earlier by arch init code. */ > > Yeah. > > > > > ... and see my comments below. > > > >> + phys_addr_t kfence_pool; > >> if (!kfence_sample_interval) > >> - return; > >> + return 0; > >> > >> - __kfence_pool = memblock_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); > >> + kfence_pool = memblock_phys_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); > >> > >> - if (!__kfence_pool) > >> + if (!kfence_pool) { > >> pr_err("failed to allocate pool\n"); > >> + return 0; > >> + } > >> + > >> + return kfence_pool; > >> +} > >> + > >> +void __init kfence_set_pool(phys_addr_t addr) > >> +{ > >> + __kfence_pool = phys_to_virt(addr); > >> } > > > > I would suggest leaving kfence_alloc_pool() to return nothing (with > > the addition above), and just set __kfence_pool as before. > > __kfence_pool itself is exported by include/linux/kfence.h, so if you > > call kfence_alloc_pool() in arm64 earlier, you can access > > __kfence_pool to get the allocated pool. > > Shall we add one new function like arm64_kfence_alloc_pool() ? The > reason is linear mapping at that time not set up and we must alloc phys > addr based on memblock. We can't use common kfence_alloc_pool().. Ah right - well, you can initialize __kfence_pool however you like within arm64 init code. Just teaching kfence_alloc_pool() to do nothing if it's already initialized should be enough. Within arch/arm64/mm/mmu.c it might be nice to factor out some bits into a helper like arm64_kfence_alloc_pool(), but would just stick to whatever is simplest. Thanks, -- Marco