Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753852AbcDVH4R (ORCPT ); Fri, 22 Apr 2016 03:56:17 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36354 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751465AbcDVH4P (ORCPT ); Fri, 22 Apr 2016 03:56:15 -0400 Date: Fri, 22 Apr 2016 09:56:11 +0200 From: Ingo Molnar To: Kees Cook Cc: Yinghai Lu , Baoquan He , Ingo Molnar , x86@kernel.org, Andrew Morton , Andrey Ryabinin , Dmitry Vyukov , "H.J. Lu" , Josh Poimboeuf , Borislav Petkov , Andy Lutomirski , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/5] x86, boot: Make memcpy handle overlaps Message-ID: <20160422075610.GD7352@gmail.com> References: <1461185746-8017-1-git-send-email-keescook@chromium.org> <1461185746-8017-5-git-send-email-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461185746-8017-5-git-send-email-keescook@chromium.org> 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 Content-Length: 1659 Lines: 48 * Kees Cook wrote: > Two uses of memcpy (screen scrolling and ELF parsing) were handling > overlapping memory areas. While there were no explicitly noticed bugs > here (yet), it is best to fix this so that the copying will always be > safe. > > Instead of making a new memmove function that might collide with other > memmove definitions in the decompressors, this just makes the compressed > boot's copy of memcpy overlap safe. Btw., I changed all mentions of function calls to include a '()', i.e.: Subject: x86/boot: Make memcpy() handle overlaps From: Kees Cook Date: Wed, 20 Apr 2016 13:55:45 -0700 Two uses of memcpy() (screen scrolling and ELF parsing) were handling overlapping memory areas. While there were no explicitly noticed bugs here (yet), it is best to fix this so that the copying will always be safe. Instead of making a new memmove() function that might collide with other memmove() definitions in the decompressors, this just makes the compressed boot code's copy of memcpy() overlap-safe. Please try to do this in future changelogs and patch titles, all references to function calls should use parentheses, and all references to variables or parameters should be escaped with '...' when it's not abundantly clear what they are - this makes for much easier reading. So just to mention an extreme (made up) example, which of these two commit titles is less confusing to read: Change out parameter of function to buffer to avoid confusion or: Change 'out' parameter of function() to 'buffer' to avoid confusion ? I know which one I'd pick! ;-) Thanks, Ingo