linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Patricia Alfonso <trishalfonso@google.com>,
	jdike@addtoit.com, richard@nod.at,
	anton.ivanov@cambridgegreys.com, aryabinin@virtuozzo.com,
	dvyukov@google.com, davidgow@google.com,
	brendanhiggins@google.com
Cc: linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
	kasan-dev@googlegroups.com
Subject: Re: [RFC PATCH] UML: add support for KASAN under x86_64
Date: Wed, 15 Jan 2020 19:48:13 +0100	[thread overview]
Message-ID: <dce24e66d89940c8998ccc2916e57877ccc9f6ae.camel@sipsolutions.net> (raw)
In-Reply-To: <20200115182816.33892-1-trishalfonso@google.com>

Hi Patricia,

On Wed, 2020-01-15 at 10:28 -0800, Patricia Alfonso wrote:
> Make KASAN run on User Mode Linux on x86_64.

Oh wow, awesome! Just what I always wanted :-)

I tried this before and failed miserably ... mostly I thought we
actually needed CONFIG_CONSTRUCTORS, which doesn't work (at least I hope
my patch for it was reverted?) - do you know what's up with that?

Couple questions, if you don't mind.

> +#ifdef CONFIG_X86_64
> +#define KASAN_SHADOW_SIZE 0x100000000000UL
> +#else
> +#error "KASAN_SHADOW_SIZE is not defined in this sub-architecture"
> +#endif

Is it even possible today to compile ARCH=um on anything but x86_64? If
yes, perhaps the above should be

	select HAVE_ARCH_KASAN if X86_64

or so? I assume KASAN itself has some dependencies though, but perhaps
ARM 64-bit or POWERPC 64-bit could possibly run into this, if not X86
32-bit.

> +++ b/arch/um/kernel/skas/Makefile
> @@ -5,6 +5,12 @@
>  
>  obj-y := clone.o mmu.o process.o syscall.o uaccess.o
>  
> +ifdef CONFIG_UML
> +# Do not instrument until after start_uml() because KASAN is not
> +# initialized yet
> +KASAN_SANITIZE	:= n
> +endif

Not sure I understand this, can anything in this file even get compiled
without CONFIG_UML?

> +++ b/kernel/Makefile
> @@ -32,6 +32,12 @@ KCOV_INSTRUMENT_kcov.o := n
>  KASAN_SANITIZE_kcov.o := n
>  CFLAGS_kcov.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
>  
> +ifdef CONFIG_UML
> +# Do not istrument kasan on panic because it can be called before KASAN

typo there - 'instrument'

> +# is initialized
> +KASAN_SANITIZE_panic.o := n
> +endif

but maybe UML shouldn't call panic() in such contexts, instead of this?
I've had some major trouble with calling into the kernel before things
are ready (or after we've started tearing things down), so that might be
a good thing overall anyway?

Could just do it this way and fix it later too though I guess.

> +++ b/lib/Makefile
> @@ -17,6 +17,16 @@ KCOV_INSTRUMENT_list_debug.o := n
>  KCOV_INSTRUMENT_debugobjects.o := n
>  KCOV_INSTRUMENT_dynamic_debug.o := n
>  
> +# Don't sanatize 

typo

> vsprintf or string functions in UM because they are used
> +# before KASAN is initialized from cmdline parsing cmdline and kstrtox are
> +# also called during uml initialization before KASAN is instrumented
> +ifdef CONFIG_UML
> +KASAN_SANITIZE_vsprintf.o := n
> +KASAN_SANITIZE_string.o := n
> +KASAN_SANITIZE_cmdline.o := n
> +KASAN_SANITIZE_kstrtox.o := n
> +endif

I guess this can't be avoided.


Very cool, I look forward to trying this out! :-)

Thanks,
johannes


  reply	other threads:[~2020-01-15 18:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 18:28 [RFC PATCH] UML: add support for KASAN under x86_64 Patricia Alfonso
2020-01-15 18:48 ` Johannes Berg [this message]
2020-01-15 22:56   ` Patricia Alfonso
2020-01-16  7:57     ` Johannes Berg
2020-01-16  8:03       ` Johannes Berg
2020-01-16  9:18         ` Dmitry Vyukov
2020-01-16  9:20           ` Johannes Berg
2020-01-16  9:23             ` Dmitry Vyukov
2020-01-17  9:59               ` Dmitry Vyukov
2020-01-17 10:03                 ` Dmitry Vyukov
2020-01-17 10:05                   ` Dmitry Vyukov
2020-02-06 18:33                     ` Patricia Alfonso
2020-02-06 18:21         ` Patricia Alfonso
2020-02-06 19:14           ` Johannes Berg
2020-01-16  8:24     ` Dmitry Vyukov
2020-01-16  8:44 ` Dmitry Vyukov
2020-02-11 23:48   ` Patricia Alfonso
2020-02-12  6:23     ` Dmitry Vyukov
2020-01-16  8:50 ` Dmitry Vyukov
2020-01-16  8:52 ` Dmitry Vyukov
2020-02-12  0:19   ` Patricia Alfonso
2020-02-12  6:24     ` Dmitry Vyukov
2020-02-12 22:25       ` Patricia Alfonso
2020-02-13  5:39         ` Dmitry Vyukov
2020-02-13 22:55           ` Patricia Alfonso
2020-01-16  9:09 ` Dmitry Vyukov

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=dce24e66d89940c8998ccc2916e57877ccc9f6ae.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=dvyukov@google.com \
    --cc=jdike@addtoit.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=trishalfonso@google.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).