From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753196AbcHZNzj (ORCPT ); Fri, 26 Aug 2016 09:55:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36688 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753086AbcHZNzh (ORCPT ); Fri, 26 Aug 2016 09:55:37 -0400 Date: Fri, 26 Aug 2016 08:55:33 -0500 From: Josh Poimboeuf To: Kees Cook Cc: Linus Torvalds , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , "x86@kernel.org" , LKML , Andy Lutomirski , Steven Rostedt , Brian Gerst , Peter Zijlstra , Frederic Weisbecker , Byungchul Park , Nilay Vaish Subject: Re: [PATCH 2/2] mm/usercopy: enable usercopy size checking for modern versions of gcc Message-ID: <20160826135533.odypm5rb7irjk3x5@treble> References: <20160823160629.pgnwzl65zji5l76w@treble> <20160825204759.fxgbdodqpl55fnji@treble> <20160826032729.pbubh5imtpocwjc7@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 26 Aug 2016 13:55:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 26, 2016 at 09:42:42AM -0400, Kees Cook wrote: > On Thu, Aug 25, 2016 at 11:27 PM, Josh Poimboeuf wrote: > > On Thu, Aug 25, 2016 at 10:14:36PM -0400, Kees Cook wrote: > >> Okay, right. __builtin_object_size() is totally fine, I absolutely > >> misspoke: it's the resolution of const value ranges. I wouldn't expect > >> gcc to warn here, though, since "copy + 1" isn't a const value... > > > > Look at the code again :-) > > > > __copy_to_user_overflow(), which does the "provably correct" warning, is > > "called" when the copy size is non-const (and the object size is const). > > So "copy + 1" being non-const is consistent with the warning. > > Right, yes. Man, this is hard to read. All the names are the same. ;) Yeah, agreed. The code is way too cryptic. > So this will trigger when the object size is known but the copy length > is non-const? Right. > When I played with re-enabling this in the past, I didn't hit very > many false positives. I sent a bunch of patches a few months back for > legitimate problems that this warning pointed out, so I'm a bit > cautious to just entirely drop it. Ah, I didn't realize that. We should definitely keep DEBUG_STRICT_USER_COPY_CHECKS then. Though it would be *really* nice to find a way to associate some kind of whitelist with it to separate the wheat from all the chaff. -- Josh