Re: [PATCH 2/2] riscv: Support CONFIG_STRICT_DEVMEM

From: Nick Kossifidis <mick@ics.forth.gr>
To: Zong Li <zong.li@sifive.com>
Cc: Nick Kossifidis <mick@ics.forth.gr>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] riscv: Support CONFIG_STRICT_DEVMEM
Date: Wed, 17 Jun 2020 08:28:17 +0300	[thread overview]
Message-ID: <6e6cf39ae6ed91bbe086adbade5786cb@mailhost.ics.forth.gr> (raw)
In-Reply-To: <CANXhq0pMutK0+hHchQPOaZLqm9B-=MTKv8Xig4hM71_B=5+2bg@mail.gmail.com>

Στις 2020-06-17 04:56, Zong Li έγραψε:
> On Tue, Jun 16, 2020 at 8:27 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2020-06-16 10:45, Zong Li έγραψε:
>> > Implement the 'devmem_is_allowed()' interface for RISC-V, like some of
>> > other architectures have done. It will be called from
>> > range_is_allowed()
>> > when userpsace attempts to access /dev/mem.
>> >
>> > Access to exclusive IOMEM and kernel RAM is denied unless
>> > CONFIG_STRICT_DEVMEM is set to 'n'.
>> >
>> > Test it by devmem, the result as follows:
>> >
>> >  - CONFIG_STRICT_DEVMEM=y
>> >       $ devmem 0x10010000
>> >       0x00000000
>> >       $ devmem 0x80200000
>> >       0x0000106F
>> >
>> >  - CONFIG_STRICT_DEVMEM is not set
>> >       $ devmem 0x10010000
>> >       devmem: mmap: Operation not permitted
>> >       $ devmem 0x80200000
>> >       devmem: mmap: Operation not permitted
>> >
>> > Signed-off-by: Zong Li <zong.li@sifive.com>
>> > ---
>> >  arch/riscv/Kconfig          |  1 +
>> >  arch/riscv/include/asm/io.h |  2 ++
>> >  arch/riscv/mm/init.c        | 19 +++++++++++++++++++
>> >  3 files changed, 22 insertions(+)
>> >
>> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> > index 128192e14ff2..ffd7841ede4c 100644
>> > --- a/arch/riscv/Kconfig
>> > +++ b/arch/riscv/Kconfig
>> > @@ -16,6 +16,7 @@ config RISCV
>> >       select ARCH_HAS_BINFMT_FLAT
>> >       select ARCH_HAS_DEBUG_VIRTUAL if MMU
>> >       select ARCH_HAS_DEBUG_WX
>> > +     select ARCH_HAS_DEVMEM_IS_ALLOWED
>> >       select ARCH_HAS_GCOV_PROFILE_ALL
>> >       select ARCH_HAS_GIGANTIC_PAGE
>> >       select ARCH_HAS_MMIOWB
>> > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
>> > index 3835c3295dc5..04ac65ab93ce 100644
>> > --- a/arch/riscv/include/asm/io.h
>> > +++ b/arch/riscv/include/asm/io.h
>> > @@ -147,4 +147,6 @@ __io_writes_outs(outs, u64, q, __io_pbr(),
>> > __io_paw())
>> >
>> >  #include <asm-generic/io.h>
>> >
>> > +extern int devmem_is_allowed(unsigned long pfn);
>> > +
>> >  #endif /* _ASM_RISCV_IO_H */
>> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> > index bbe816e03b2f..5e7e61519acc 100644
>> > --- a/arch/riscv/mm/init.c
>> > +++ b/arch/riscv/mm/init.c
>> > @@ -517,6 +517,25 @@ void mark_rodata_ro(void)
>> >  }
>> >  #endif
>> >
>> > +#ifdef CONFIG_STRICT_DEVMEM
>> > +#include <linux/ioport.h>
>> > +/*
>> > + * devmem_is_allowed() checks to see if /dev/mem access to a certain
>> > address
>> > + * is valid. The argument is a physical page number.
>> > + *
>> > + * Disallow access to system RAM as well as device-exclusive MMIO
>> > regions.
>> > + * This effectively disable read()/write() on /dev/mem.
>> > + */
>> > +int devmem_is_allowed(unsigned long pfn)
>> > +{
>> > +     if (iomem_is_exclusive(pfn << PAGE_SHIFT))
>> > +             return 0;
>> > +     if (!page_is_ram(pfn))
>> > +             return 1;
>> > +     return 0;
>> > +}
>> > +#endif
>> > +
>> >  void __init resource_init(void)
>> >  {
>> >       struct memblock_region *region;
>> 
>> This shouldn't be part of /mm/init.c, it has nothing to do with memory
>> initialization, I suggest we move it to another file like mmap.c on
> 
> Let me move it, thanks.
> 
>> arm/arm64. Also before using iomem_is_exclusive we should probably 
>> also
>> mark any reserved regions with the no-map attribute as busy|exclusive,
>> reserved-memory regions are not necessarily part of the main memory so
>> the page_is_ram check may pass and iomem_is_exclusive won't do any 
>> good.
> 
> What do you think if we mark the reserved region in
> kdump_resource_init, and change the kdump_resource_init to a more
> generic name for initializing resources?

Sounds good to me, I'll work on this within the week. Do you agree with 
marking the no-map reserved-memory regions as exclusive ?