linux-kernel - Re: [PATCH v2] x86/boot: Rename overlapping memcpy() to memmove()

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jK68mnKmkc1X6zKd-Bkat8Wryb9ifHUQ5pVTKHP9CJLWQ@mail.gmail.com>
Date:	Thu, 28 Apr 2016 02:18:17 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Yinghai Lu <yinghai@...nel.org>, Baoquan He <bhe@...hat.com>,
	Borislav Petkov <bp@...e.de>, Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	"H.J. Lu" <hjl.tools@...il.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86/boot: Rename overlapping memcpy() to memmove()

On Thu, Apr 28, 2016 at 2:04 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Kees Cook <keescook@...omium.org> wrote:
> > +#define memmove              memmove
>
> Btw., what's the purpose of this define? If it's already defined then we should
> get a build warning. If it's not, we won't.

It's for the decompressor that checks for memmove existing already via
"ifdef memmove". If this isn't done here, we will end up with two
memmove implementations.

>> +void *memcpy(void *dest, const void *src, size_t n)
>
> btw., if there's any doubt about other overlapping uses, we could add this to
> memcpy():
>
>   WARN_ON_ONCE(dest > src && dest-src < n);
>
> or so? Does printk() work so early on?

It does not, but we could use either "error" or the new "warn". Should
we abort a boot in this case, or just warn about it? (Our
implementations of memcpy, fwiw, currently seem to support overlap, so
I would suggest warn.)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security