lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPAsAGzjNyMjFaFc4zzhjpRFi0=v7-HSAzDje7O195UGkAE8LA@mail.gmail.com>
Date:	Fri, 9 Oct 2015 17:34:42 +0300
From:	Andrey Ryabinin <ryabinin.a.a@...il.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>, Yury <yury.norov@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Salter <msalter@...hat.com>,
	Will Deacon <will.deacon@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexey Klimov <klimov.linux@...il.com>,
	Alexander Potapenko <glider@...gle.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	David Keitel <dkeitel@...eaurora.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v6 0/6] KASAN for arm64

2015-10-09 15:42 GMT+03:00 Mark Rutland <mark.rutland@....com>:
> On Fri, Oct 09, 2015 at 01:18:09PM +0300, Andrey Ryabinin wrote:
>> 2015-10-09 12:48 GMT+03:00 Mark Rutland <mark.rutland@....com>:
>> > On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote:
>> > [...]
>> >
>> >> I thought the EFI stub isolation patches create a copy of mem*() functions in the stub,
>> >> but they are just create aliases with __efistub_ prefix.
>> >>
>> >> We only need to create some more aliases for KASAN.
>> >> The following patch on top of the EFI stub isolation series works for me.
>> >>
>> >>
>> >> Signed-off-by: Andrey Ryabinin <ryabinin.a.a@...il.com>
>> >> ---
>> >>  arch/arm64/kernel/image.h | 6 ++++++
>> >>  1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
>> >> index e083af0..6eb8fee 100644
>> >> --- a/arch/arm64/kernel/image.h
>> >> +++ b/arch/arm64/kernel/image.h
>> >> @@ -80,6 +80,12 @@ __efistub_strcmp           = __pi_strcmp;
>> >>  __efistub_strncmp            = __pi_strncmp;
>> >>  __efistub___flush_dcache_area        = __pi___flush_dcache_area;
>> >>
>> >> +#ifdef CONFIG_KASAN
>> >> +__efistub___memcpy           = __pi_memcpy;
>> >> +__efistub___memmove          = __pi_memmove;
>> >> +__efistub___memset           = __pi_memset;
>> >> +#endif
>> >
>> > Ard's v4 stub isolation series has these aliases [1], as the stub
>> > requires these aliases regardless of KASAN in order to link.
>>
>> Stub isolation series has __efistub_memcpy, not __efistub___memcpy
>> (two additional '_').
>
> Ah, I see, sorry for my sloppy reading.
>
>> The thing is, KASAN provides own implementation of memcpy() which
>> checks memory before access.
>> The original 'memcpy()' becomes __memcpy(), so we could still use it.
>
> Ok.
>
>> In code that not instrumented by KASAN (like the EFI stub) we replace
>> KASAN's memcpy() with the original __mempcy():
>> #define memcpy() __memcpy()
>
> I'm a little confused by this. Surely that doesn't override implicit
> calls generated by the compiler, leaving us with a mixture of calls to
> memcpy and __memcpy?
>
> That doesn't matter for the stub, as both __efistub_mem* and
> __efistub___mem* would point at __pe_mem*, but doesn't that matter for
> other users that shouldn't be instrumented?
>
> Is that not a problem, or do we inhibit/override that somehow?
>

You are right, GCC could emit memcpy() call. It's just not a problem so far.
The amount of not instrumented code is fairly small (some low-level
x86 code, kasan internals and slub allocator).

The purpose of these defines is to not spread kasan-specific details
across unrelated code.
E.g. there are a lot of memcpy()/memset() calls in slub that used to
access object's redzone or
freed objects. So it simpler to redefine memset, rather then somehow
mangle that code.

>> So with CONFIG_KASAN=y the EFI stub uses __memcpy, thus we need to
>> create the __efistub___memcpy alias.
>
> Ok, that makes sense to me.
>
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ