From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752818AbcD2HU7 (ORCPT ); Fri, 29 Apr 2016 03:20:59 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34792 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752588AbcD2HUG (ORCPT ); Fri, 29 Apr 2016 03:20:06 -0400 Date: Fri, 29 Apr 2016 09:20:02 +0200 From: Ingo Molnar To: Kees Cook Cc: Lasse Collin , One Thousand Gnomes , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , LKML , Yinghai Lu , Baoquan He , Borislav Petkov Subject: Re: [PATCH v4] x86/boot: Warn on future overlapping memcpy() use Message-ID: <20160429072002.GD28320@gmail.com> References: <20160429001822.GA15625@www.outflux.net> <20160429064343.GB28320@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kees Cook wrote: > On Thu, Apr 28, 2016 at 11:43 PM, Ingo Molnar wrote: > > > > * Kees Cook wrote: > > > >> If an overlapping memcpy() is ever attempted, we should at least report > >> it, in case it might lead to problems, so it could be changed to a > >> memmove() call instead. > >> > >> Suggested-by: Ingo Molnar > >> Signed-off-by: Kees Cook > >> --- > >> v4: > >> - use __memcpy not memcpy since we've already done the check. > >> v3: > >> - call memmove in addition to doing the warning > >> v2: > >> - warn about overlapping region > >> --- > >> arch/x86/boot/compressed/string.c | 16 +++++++++++++--- > >> 1 file changed, 13 insertions(+), 3 deletions(-) > > > > Applied, thanks Kees! > > > > Btw., can we now also remove the memmove() hack from lib/decompress_unxz.c? > > I'll let Lasse answer for sure, but I don't think so. The original commit says: > > The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and > memzero() (memset(ptr, 0, size)), which aren't available in all > arch-specific pre-boot environments. I'm including simple versions in > decompress_unxz.c, but a cleaner solution would naturally be nicer. I see, so non-x86 architectures might not have the proper runtime environment implemented, right? Fair enough! Thanks, Ingo