From: Michael Tretter <m.tretter@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH 1/2] ARM: mmu64: allow to disable null pointer trap on zero page
Date: Thu, 15 Oct 2020 10:40:34 +0200 [thread overview]
Message-ID: <20201015084034.GE5487@pengutronix.de> (raw)
In-Reply-To: <c69bf9f0-f051-7b48-dac9-75cfc2686994@pengutronix.de>
On Thu, 15 Oct 2020 10:14:41 +0200, Ahmad Fatoum wrote:
> On 10/15/20 9:33 AM, Michael Tretter wrote:
> > On Wed, 14 Oct 2020 18:29:47 +0200, Ahmad Fatoum wrote:
> >> On 10/14/20 5:08 PM, Michael Tretter wrote:
> >>> Barebox uses the zero page to trap NULL pointer dereferences. However,
> >>> if the SDRAM starts at address 0x0, this makes the first page of the
> >>> SDRAM inaccessible and makes it impossible to load images to offset 0x0
> >>> in the SDRAM.
> >>>
> >>> Trapping NULL pointer dereferences on such systems is still desirable.
> >>> Therefore, add a function to disable the traps if accessing the zero
> >>> page is necessary and to re-enable the traps after the access is done.
> >>
> >> Can't we map the (phy_addr_t)0 at some higher virtual address and
> >> change uimage to use phys_to_virt() ?
> >
> > To which virt would you map (phy_addr_t)0?
>
> You are on a 64-bit system. Just choose something > 4G that's suitable for
> your ZynqMP?
This would introduce very platform specific handling and diverge from the
shared mmu_64 code. I would rather go for a more general solution.
What about 32 bit ARM systems? Currently, the zero page is simply mapped on
such systems and NULL pointers will never trap.
>
> > This would break the general virt =
> > phys assumption in Barebox. It might work for some cases, but might break in
> > unexpected ways in other. Therefore, I deem it saver to stay with virt = phys
> > and allow to disable the trap, if necessary.
>
> Can you be more specific what kind of problems do you foresee? You map the zero
> page unaccessible already, so any code that would object to having the page 0
> and 1 not be contiguous in memory would already have problems to access page 0.
For example, memtest accesses page 0 and just remaps it.
Michael
>
> >
> > Michael
> >
> >>
> >> Something like
> >>
> >> static inline void *phys_to_virt(unsigned long phys)
> >> {
> >> if (!IS_ENABLED(CONFIG_ARM_MACH_CUSTOM_MAPPING) || !arm_mach_phys_to_virt)
> >> return (void *)phys;
> >> return arm_mach_phys_to_virt(phys);
> >> }
> >>
> >>
> >>>
> >>> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
> >>> ---
> >>> arch/arm/cpu/Kconfig | 1 +
> >>> arch/arm/cpu/mmu_64.c | 13 ++++++++++++-
> >>> include/zero_page.h | 40 ++++++++++++++++++++++++++++++++++++++++
> >>> lib/Kconfig | 3 +++
> >>> 4 files changed, 56 insertions(+), 1 deletion(-)
> >>> create mode 100644 include/zero_page.h
> >>>
> >>> diff --git a/arch/arm/cpu/Kconfig b/arch/arm/cpu/Kconfig
> >>> index f9f52a625260..ca3bd98962e2 100644
> >>> --- a/arch/arm/cpu/Kconfig
> >>> +++ b/arch/arm/cpu/Kconfig
> >>> @@ -89,6 +89,7 @@ config CPU_V8
> >>> select ARM_EXCEPTIONS
> >>> select GENERIC_FIND_NEXT_BIT
> >>> select ARCH_HAS_STACK_DUMP
> >>> + select ARCH_HAS_ZERO_PAGE
> >>>
> >>> config CPU_XSC3
> >>> bool
> >>> diff --git a/arch/arm/cpu/mmu_64.c b/arch/arm/cpu/mmu_64.c
> >>> index 7e9ae84810f6..bd15807f9160 100644
> >>> --- a/arch/arm/cpu/mmu_64.c
> >>> +++ b/arch/arm/cpu/mmu_64.c
> >>> @@ -10,6 +10,7 @@
> >>> #include <init.h>
> >>> #include <mmu.h>
> >>> #include <errno.h>
> >>> +#include <zero_page.h>
> >>> #include <linux/sizes.h>
> >>> #include <asm/memory.h>
> >>> #include <asm/pgtable64.h>
> >>> @@ -168,6 +169,16 @@ static void mmu_enable(void)
> >>> set_cr(get_cr() | CR_M | CR_C | CR_I);
> >>> }
> >>>
> >>> +void zero_page_disable(void)
> >>> +{
> >>> + create_sections(0x0, 0x0, PAGE_SIZE, CACHED_MEM);
> >>> +}
> >>> +
> >>> +void zero_page_enable(void)
> >>> +{
> >>> + create_sections(0x0, 0x0, PAGE_SIZE, 0x0);
> >>> +}
> >>> +
> >>> /*
> >>> * Prepare MMU for usage enable it.
> >>> */
> >>> @@ -194,7 +205,7 @@ void __mmu_init(bool mmu_on)
> >>> create_sections(bank->start, bank->start, bank->size, CACHED_MEM);
> >>>
> >>> /* Make zero page faulting to catch NULL pointer derefs */
> >>> - create_sections(0x0, 0x0, 0x1000, 0x0);
> >>> + zero_page_enable();
> >>>
> >>> mmu_enable();
> >>> }
> >>> diff --git a/include/zero_page.h b/include/zero_page.h
> >>> new file mode 100644
> >>> index 000000000000..d8dd07cfe959
> >>> --- /dev/null
> >>> +++ b/include/zero_page.h
> >>> @@ -0,0 +1,40 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0-only */
> >>> +#ifndef __ZERO_PAGE_H
> >>> +#define __ZERO_PAGE_H
> >>> +
> >>> +#include <common.h>
> >>> +
> >>> +#if defined CONFIG_ARCH_HAS_ZERO_PAGE
> >>> +
> >>> +/*
> >>> + * zero_page_enable - enable null pointer trap
> >>> + */
> >>> +void zero_page_enable(void);
> >>> +
> >>> +/*
> >>> + * zero_page_disable - disable null pointer trap
> >>> + *
> >>> + * Disable the null pointer trap on the zero page if access to the zero page
> >>> + * is actually required. Disable the trap with care and re-enable it
> >>> + * immediately after the access to properly trap null pointers.
> >>> + */
> >>> +void zero_page_disable(void);
> >>> +
> >>> +#else
> >>> +
> >>> +static inline void zero_page_enable(void)
> >>> +{
> >>> +}
> >>> +
> >>> +static inline void zero_page_disable(void)
> >>> +{
> >>> +}
> >>> +
> >>> +#endif
> >>> +
> >>> +static inline bool zero_page_contains(unsigned long addr)
> >>> +{
> >>> + return addr < PAGE_SIZE;
> >>> +}
> >>> +
> >>> +#endif /* __ZERO_PAGE_H */
> >>> diff --git a/lib/Kconfig b/lib/Kconfig
> >>> index 887f50ff003f..e5831ecdb9a7 100644
> >>> --- a/lib/Kconfig
> >>> +++ b/lib/Kconfig
> >>> @@ -182,6 +182,9 @@ config ARCH_HAS_STACK_DUMP
> >>> config ARCH_HAS_DATA_ABORT_MASK
> >>> bool
> >>>
> >>> +config ARCH_HAS_ZERO_PAGE
> >>> + bool
> >>> +
> >>> config HAVE_EFFICIENT_UNALIGNED_ACCESS
> >>> bool
> >>>
> >>>
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | Michael Tretter |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2020-10-15 8:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 15:08 Michael Tretter
2020-10-14 15:08 ` [PATCH 2/2] uimage: disable zero page when loading to SDRAM at address 0x0 Michael Tretter
2020-10-14 16:33 ` Ahmad Fatoum
2020-10-15 7:40 ` Michael Tretter
2020-10-15 8:35 ` Sascha Hauer
2020-10-15 9:12 ` Ahmad Fatoum
2020-10-14 16:29 ` [PATCH 1/2] ARM: mmu64: allow to disable null pointer trap on zero page Ahmad Fatoum
[not found] ` <20201015073331.GA29491@pengutronix.de>
2020-10-15 8:14 ` Ahmad Fatoum
2020-10-15 8:40 ` Michael Tretter [this message]
2020-10-15 8:44 ` Sascha Hauer
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=20201015084034.GE5487@pengutronix.de \
--to=m.tretter@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox