linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Nick Hu <nickhu@andestech.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	"Alan Quey-Liang Kao(高魁良)" <alankao@andestech.com>,
	"atish.patra@wdc.com" <atish.patra@wdc.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"離職Zong Zong-Xian Li(李宗憲)" <zong@andestech.com>,
	"alexios.zavras@intel.com" <alexios.zavras@intel.com>,
	"Anup.Patel@wdc.com" <Anup.Patel@wdc.com>,
	"glider@google.com" <glider@google.com>,
	"green.hu@gmail.com" <green.hu@gmail.com>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"aryabinin@virtuozzo.com" <aryabinin@virtuozzo.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"deanbo422@gmail.com" <deanbo422@gmail.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"dvyukov@google.com" <dvyukov@google.com>
Subject: Re: [PATCH 2/2] riscv: Add KASAN support
Date: Wed, 14 Aug 2019 15:44:18 +0800	[thread overview]
Message-ID: <20190814074417.GA21929@andestech.com> (raw)
In-Reply-To: <20190812151050.GJ26897@infradead.org>

Hi Christoph,

Thanks for your reply. I will answer one by one.

Hi Alexander,

Would you help me for the question about SOFTIRQENTRY_TEXT?

On Mon, Aug 12, 2019 at 11:10:50PM +0800, Christoph Hellwig wrote:
> > 2. KASAN can't debug the modules since the modules are allocated in VMALLOC
> > area. We mapped the shadow memory, which corresponding to VMALLOC area,
> > to the kasan_early_shadow_page because we don't have enough physical space
> > for all the shadow memory corresponding to VMALLOC area.
> 
> How do other architectures solve this problem?
> 
Other archs like arm64 and x86 allocate modules in their module region.

> > @@ -54,6 +54,8 @@ config RISCV
> >  	select EDAC_SUPPORT
> >  	select ARCH_HAS_GIGANTIC_PAGE
> >  	select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
> > +	select GENERIC_STRNCPY_FROM_USER if KASAN
> 
> Is there any reason why we can't always enabled this?  Also just
> enabling the generic efficient strncpy_from_user should probably be
> a separate patch.
> 
You're right, always enable it would be better.

> > +	select HAVE_ARCH_KASAN if MMU
> 
> Based on your cover letter this should be if MMU && 64BIT
> 
> >  #define __HAVE_ARCH_MEMCPY
> >  extern asmlinkage void *memcpy(void *, const void *, size_t);
> > +extern asmlinkage void *__memcpy(void *, const void *, size_t);
> >  
> >  #define __HAVE_ARCH_MEMMOVE
> >  extern asmlinkage void *memmove(void *, const void *, size_t);
> > +extern asmlinkage void *__memmove(void *, const void *, size_t);
> > +
> > +#define memcpy(dst, src, len) __memcpy(dst, src, len)
> > +#define memmove(dst, src, len) __memmove(dst, src, len)
> > +#define memset(s, c, n) __memset(s, c, n)
> 
> This looks weird and at least needs a very good comment.  Also
> with this we effectively don't need the non-prefixed prototypes
> anymore.  Also you probably want to split the renaming of the mem*
> routines into a separate patch with a proper changelog.
> 
I made some mistakes on this porting, this would be better:

#define __HAVE_ARCH_MEMSET
extern asmlinkage void *memset(void *, int, size_t);
extern asmlinkage void *__memset(void *, int, size_t);

#define __HAVE_ARCH_MEMCPY
extern asmlinkage void *memcpy(void *, const void *, size_t);
extern asmlinkage void *__memcpy(void *, const void *, size_t);

#define __HAVE_ARCH_MEMMOVE
extern asmlinkage void *memmove(void *, const void *, size_t);
extern asmlinkage void *__memmove(void *, const void *, size_t);

#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)

#define memcpy(dst, src, len) __memcpy(dst, src, len)
#define memmove(dst, src, len) __memmove(dst, src, len)
#define memset(s, c, n) __memset(s, c, n)

#endif

> >  #include <asm/tlbflush.h>
> >  #include <asm/thread_info.h>
> >  
> > +#ifdef CONFIG_KASAN
> > +#include <asm/kasan.h>
> > +#endif
> 
> Any good reason to not just always include the header?
>
Nope, I would remove the '#ifdef CONFIG_KASAN', and do the logic in the header
instead.

> > +
> >  #ifdef CONFIG_DUMMY_CONSOLE
> >  struct screen_info screen_info = {
> >  	.orig_video_lines	= 30,
> > @@ -64,12 +68,17 @@ void __init setup_arch(char **cmdline_p)
> >  
> >  	setup_bootmem();
> >  	paging_init();
> > +
> >  	unflatten_device_tree();
> 
> spurious whitespace change.
> 
> > diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
> > index 23cd1a9..9700980 100644
> > --- a/arch/riscv/kernel/vmlinux.lds.S
> > +++ b/arch/riscv/kernel/vmlinux.lds.S
> > @@ -46,6 +46,7 @@ SECTIONS
> >  		KPROBES_TEXT
> >  		ENTRY_TEXT
> >  		IRQENTRY_TEXT
> > +		SOFTIRQENTRY_TEXT
> 
> Hmm.  What is the relation to kasan here?  Maybe we should add this
> separately with a good changelog?
> 
There is a commit for it:

Author: Alexander Potapenko <glider@google.com>
Date:   Fri Mar 25 14:22:05 2016 -0700

    arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections

    KASAN needs to know whether the allocation happens in an IRQ handler.
    This lets us strip everything below the IRQ entry point to reduce the
    number of unique stack traces needed to be stored.

    Move the definition of __irq_entry to <linux/interrupt.h> so that the
    users don't need to pull in <linux/ftrace.h>.  Also introduce the
    __softirq_entry macro which is similar to __irq_entry, but puts the
    corresponding functions to the .softirqentry.text section.

After reading the patch I understand that soft/hard IRQ entries should be
separated for KASAN to work, but why?

Alexender, do you have any comments on this?

> > +++ b/arch/riscv/mm/kasan_init.c
> > @@ -0,0 +1,102 @@
> > +// SPDX-License-Identifier: GPL-2.0
> 
> This probably also wants a copyright statement.
> 
> > +	// init for swapper_pg_dir
> 
> Please use /* */ style comments.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-08-14  7:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07  7:19 [PATCH 0/2] KASAN support for RISC-V Nick Hu
2019-08-07  7:19 ` [PATCH 1/2] riscv: Add memmove string operation Nick Hu
2019-08-12 15:04   ` Christoph Hellwig
2019-08-13 23:50     ` Palmer Dabbelt
2019-08-14  2:22       ` Paul Walmsley
2019-08-14  3:27         ` Nick Hu
2019-08-14 17:03           ` Paul Walmsley
2019-08-15  3:12             ` Nick Hu
2019-08-15 18:27               ` Paul Walmsley
2019-08-19  6:29                 ` Nick Hu
2019-08-14 18:33         ` Palmer Dabbelt
2019-08-22 15:59   ` Andrey Ryabinin
2019-08-27  9:07     ` Nick Hu
2019-08-27  9:33       ` Andrey Ryabinin
2019-08-28  3:06         ` Nick Hu
2019-08-07  7:19 ` [PATCH 2/2] riscv: Add KASAN support Nick Hu
2019-08-12 15:10   ` Christoph Hellwig
2019-08-14  7:44     ` Nick Hu [this message]
2019-08-22 17:08       ` Andrey Ryabinin
2019-09-03 15:08       ` Daniel Axtens
2019-09-04  2:24         ` Nick Hu

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=20190814074417.GA21929@andestech.com \
    --to=nickhu@andestech.com \
    --cc=Anup.Patel@wdc.com \
    --cc=alankao@andestech.com \
    --cc=alexios.zavras@intel.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=aryabinin@virtuozzo.com \
    --cc=atish.patra@wdc.com \
    --cc=deanbo422@gmail.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=green.hu@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=tglx@linutronix.de \
    --cc=zong@andestech.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: 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;
as well as URLs for NNTP newsgroup(s).