From: Hsin-Yi Wang <hsinyi@chromium.org> To: Mike Rapoport <rppt@linux.ibm.com> Cc: Stephen Boyd <swboyd@chromium.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>, Rasmus Villemoes <linux@rasmusvillemoes.dk>, Architecture Mailman List <boot-architecture@lists.linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@suse.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Miles Chen <miles.chen@mediatek.com>, James Morse <james.morse@arm.com>, Andrew Murray <andrew.murray@arm.com> Subject: Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan() Date: Wed, 15 May 2019 18:34:06 +0800 [thread overview] Message-ID: <CAJMQK-hGyuM=+C0ZPUbUwMqH8zPoYPF43L8oMP=p8MUeXrco4g@mail.gmail.com> (raw) In-Reply-To: <20190515050059.GA4081@rapoport-lnx> On Wed, May 15, 2019 at 1:01 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > Why not just have fixmap_remap_fdt() that maps it as RW and reserves > > memblock once, and then call __fixmap_remap_fdt() with RO after > > early_init_dt_scan() or unflatten_device_tree() is called? Why the > > desire to call memblock_reserve() twice or even three times? > > There's no desire to call memblock_reserve() twice. It's just that leaving > the call for it in kaslr rather than in setup_arch() may end up with > unreserved FDT because kaslr was disabled or even compiled out. > > I've suggested to use fixmap_remap_fdt() everywhere because IMHO this > improves readability and allows to un-export __fixmap_remap_fdt(). > > -- > Sincerely yours, > Mike. > How about adding an arch hook that's not limited to be called at init (like fixmap_remap_fdt). In this way we don't have to change currently arm64 setup structure and only map fdt to RW before we need to modify it (and can map back to RO after write). Since it can be called after init, for CONFIG_KEXEC, we can also use it before updating fdt with a new seed. Does nothing by default, and for arm64 it can be like[1]. It's similar to __fixmap_remap_fdt on counting fdt size but using update_mapping_prot() (will flush the TLBs). And suppose fixmap_remap_fdt() is called at least once, region checking is skipped. diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 8080c9f489c3..e0fff8a009da 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -32,6 +32,7 @@ #include <linux/io.h> #include <linux/mm.h> #include <linux/vmalloc.h> +#include <linux/of_fdt.h> #include <asm/barrier.h> #include <asm/cputype.h> @@ -919,6 +920,22 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys) return dt_virt; } +extern phys_addr_t fdt_pointer; + +/* Should be called after fixmap_remap_fdt() is called. */ +void update_fdt_pgprot(pgprot_t prot) +{ + u64 dt_virt_base = __fix_to_virt(FIX_FDT); + int offset, size; + + offset = fdt_pointer % SWAPPER_BLOCK_SIZE; + size = fdt_totalsize((void *)dt_virt_base + offset); + + update_mapping_prot(round_down(fdt_pointer, SWAPPER_BLOCK_SIZE), + dt_virt_base, + round_up(offset + size, SWAPPER_BLOCK_SIZE), prot); +} + example use: update_fdt_pgprot(PAGE_KERNEL); fdt_delprop(initial_boot_params, node, "rng-seed"); update_fdt_pgprot(PAGE_KERNEL_RO); I tested on arm64 device and it works. But if this doesn't seems right, I'll probably just don't don't map fdt back to RO if kexec is set. Is this reasonable? Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Hsin-Yi Wang <hsinyi@chromium.org> To: Mike Rapoport <rppt@linux.ibm.com> Cc: Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Architecture Mailman List <boot-architecture@lists.linaro.org>, Michal Hocko <mhocko@suse.com>, Kees Cook <keescook@chromium.org>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Rasmus Villemoes <linux@rasmusvillemoes.dk>, linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>, Stephen Boyd <swboyd@chromium.org>, Miles Chen <miles.chen@mediatek.com>, Rob Herring <robh+dt@kernel.org>, James Morse <james.morse@arm.com>, Andrew Murray <andrew.murray@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Frank Rowand <frowand.list@gmail.com>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan() Date: Wed, 15 May 2019 18:34:06 +0800 [thread overview] Message-ID: <CAJMQK-hGyuM=+C0ZPUbUwMqH8zPoYPF43L8oMP=p8MUeXrco4g@mail.gmail.com> (raw) In-Reply-To: <20190515050059.GA4081@rapoport-lnx> On Wed, May 15, 2019 at 1:01 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > Why not just have fixmap_remap_fdt() that maps it as RW and reserves > > memblock once, and then call __fixmap_remap_fdt() with RO after > > early_init_dt_scan() or unflatten_device_tree() is called? Why the > > desire to call memblock_reserve() twice or even three times? > > There's no desire to call memblock_reserve() twice. It's just that leaving > the call for it in kaslr rather than in setup_arch() may end up with > unreserved FDT because kaslr was disabled or even compiled out. > > I've suggested to use fixmap_remap_fdt() everywhere because IMHO this > improves readability and allows to un-export __fixmap_remap_fdt(). > > -- > Sincerely yours, > Mike. > How about adding an arch hook that's not limited to be called at init (like fixmap_remap_fdt). In this way we don't have to change currently arm64 setup structure and only map fdt to RW before we need to modify it (and can map back to RO after write). Since it can be called after init, for CONFIG_KEXEC, we can also use it before updating fdt with a new seed. Does nothing by default, and for arm64 it can be like[1]. It's similar to __fixmap_remap_fdt on counting fdt size but using update_mapping_prot() (will flush the TLBs). And suppose fixmap_remap_fdt() is called at least once, region checking is skipped. diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 8080c9f489c3..e0fff8a009da 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -32,6 +32,7 @@ #include <linux/io.h> #include <linux/mm.h> #include <linux/vmalloc.h> +#include <linux/of_fdt.h> #include <asm/barrier.h> #include <asm/cputype.h> @@ -919,6 +920,22 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys) return dt_virt; } +extern phys_addr_t fdt_pointer; + +/* Should be called after fixmap_remap_fdt() is called. */ +void update_fdt_pgprot(pgprot_t prot) +{ + u64 dt_virt_base = __fix_to_virt(FIX_FDT); + int offset, size; + + offset = fdt_pointer % SWAPPER_BLOCK_SIZE; + size = fdt_totalsize((void *)dt_virt_base + offset); + + update_mapping_prot(round_down(fdt_pointer, SWAPPER_BLOCK_SIZE), + dt_virt_base, + round_up(offset + size, SWAPPER_BLOCK_SIZE), prot); +} + example use: update_fdt_pgprot(PAGE_KERNEL); fdt_delprop(initial_boot_params, node, "rng-seed"); update_fdt_pgprot(PAGE_KERNEL_RO); I tested on arm64 device and it works. But if this doesn't seems right, I'll probably just don't don't map fdt back to RO if kexec is set. Is this reasonable? Thanks! _______________________________________________ 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:[~2019-05-15 10:34 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-13 0:38 [PATCH v2 1/2] fdt: add support for rng-seed Hsin-Yi Wang 2019-05-13 0:38 ` Hsin-Yi Wang 2019-05-13 0:38 ` Hsin-Yi Wang 2019-05-13 0:38 ` [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan() Hsin-Yi Wang 2019-05-13 0:38 ` Hsin-Yi Wang 2019-05-13 8:58 ` Mike Rapoport 2019-05-13 8:58 ` Mike Rapoport 2019-05-13 11:14 ` Hsin-Yi Wang 2019-05-13 11:14 ` Hsin-Yi Wang 2019-05-13 11:14 ` Hsin-Yi Wang 2019-05-14 15:42 ` Mike Rapoport 2019-05-14 15:42 ` Mike Rapoport 2019-05-14 15:42 ` Mike Rapoport 2019-05-15 10:24 ` Hsin-Yi Wang 2019-05-15 10:24 ` Hsin-Yi Wang 2019-05-15 10:24 ` Hsin-Yi Wang 2019-05-15 20:11 ` Ard Biesheuvel 2019-05-15 20:11 ` Ard Biesheuvel 2019-05-15 20:11 ` Ard Biesheuvel 2019-05-16 11:07 ` Mike Rapoport 2019-05-16 11:07 ` Mike Rapoport 2019-05-16 11:07 ` Mike Rapoport 2019-05-14 21:05 ` Stephen Boyd 2019-05-14 21:05 ` Stephen Boyd 2019-05-14 21:05 ` Stephen Boyd 2019-05-15 5:00 ` Mike Rapoport 2019-05-15 5:00 ` Mike Rapoport 2019-05-15 5:00 ` Mike Rapoport 2019-05-15 10:34 ` Hsin-Yi Wang [this message] 2019-05-15 10:34 ` Hsin-Yi Wang 2019-05-15 10:34 ` Hsin-Yi Wang 2019-05-13 8:42 ` [PATCH v2 1/2] fdt: add support for rng-seed Mike Rapoport 2019-05-13 8:42 ` Mike Rapoport 2019-05-13 8:42 ` Mike Rapoport 2019-05-13 13:14 ` Rob Herring 2019-05-13 13:14 ` Rob Herring 2019-05-13 13:14 ` Rob Herring 2019-05-15 9:07 ` Hsin-Yi Wang 2019-05-15 9:07 ` Hsin-Yi Wang 2019-05-15 9:07 ` Hsin-Yi Wang
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='CAJMQK-hGyuM=+C0ZPUbUwMqH8zPoYPF43L8oMP=p8MUeXrco4g@mail.gmail.com' \ --to=hsinyi@chromium.org \ --cc=akpm@linux-foundation.org \ --cc=andrew.murray@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=boot-architecture@lists.linaro.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=james.morse@arm.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@rasmusvillemoes.dk \ --cc=mark.rutland@arm.com \ --cc=mhocko@suse.com \ --cc=miles.chen@mediatek.com \ --cc=robh+dt@kernel.org \ --cc=rppt@linux.ibm.com \ --cc=swboyd@chromium.org \ --cc=will.deacon@arm.com \ /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.