Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754249AbdLTEFZ (ORCPT ); Tue, 19 Dec 2017 23:05:25 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:46934 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754136AbdLTEFY (ORCPT ); Tue, 19 Dec 2017 23:05:24 -0500 X-Google-Smtp-Source: ACJfBovbN24pDnS43f0NRcXMQQsva/mtWbilQdeOdP0UIHAjwy1+z7ca4ejj/V4JyTfKloRENn0NiiwycbT1C0bvOUI= MIME-Version: 1.0 In-Reply-To: <20171220035043.GA14980@bombadil.infradead.org> References: <001a113e9ca8a3affd05609d7ccf@google.com> <6a50d160-56d0-29f9-cfed-6c9202140b43@I-love.SAKURA.ne.jp> <20171219083746.GR19604@eros> <20171219132246.GD13680@bombadil.infradead.org> <20171219214849.GU21978@ZenIV.linux.org.uk> <20171220035043.GA14980@bombadil.infradead.org> From: Linus Torvalds Date: Tue, 19 Dec 2017 20:05:22 -0800 X-Google-Sender-Auth: u8-IULECjfhDdr6lAzNOIvcyLuI Message-ID: Subject: Re: BUG: bad usercopy in memdup_user To: Matthew Wilcox Cc: Al Viro , "Tobin C. Harding" , Dmitry Vyukov , Kees Cook , Tetsuo Handa , Linux-MM , syzbot , David Windsor , keun-o.park@darkmatter.ae, Laura Abbott , LKML , Mark Rutland , Ingo Molnar , syzkaller-bugs@googlegroups.com, Will Deacon Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2695 Lines: 74 On Tue, Dec 19, 2017 at 7:50 PM, Matthew Wilcox wrote: > On Tue, Dec 19, 2017 at 09:48:49PM +0000, Al Viro wrote: >> Well, for example seeing a 0xfffffffffffffff4 where a pointer to object >> must have been is a pretty strong hint to start looking for a way for >> that ERR_PTR(-ENOMEM) having ended up there... Something like >> 0x6e69622f7273752f is almost certainly a misplaced "/usr/bin", i.e. a >> pathname overwriting whatever it ends up in, etc. And yes, I have run >> into both of those in real life. >> >> Debugging the situation when crap value has ended up in place of a >> pointer is certainly a case where you do want to see what exactly has >> ended up in there... > > Linus, how would you feel about printing ERR_PTRs without molestation? Stop this stupidity already. Guys, seriously. You're making idiotic arguments that have nothing to do with reality. If you actually have an invalid pointer that causes an oops (whether it's an ERR_PTR or something like 0x6e69622f7273752f or something like the list poison values etc), WE ALREADY PRINT OUT THE WHOLE UNHASHED POINTER VALUE This "but but but some pointers are magic and shouldn't be hashed" stuff is *garbage*. You're making shit up. You don't have a single actual real-life example that you can point to that is relevant. Again, I've seen those bad pointer oopses myself. Yes, the magic values are relevant, and should be printed out. BUT THEY ALREADY ARE PRINTED OUT. Christ. So let me repeat: - don't change %p behavior. - don't use "I was confused" as an argument. Yes, things changed, and yes, it clearly caused confusion, but that is temporary and is not an argument for making magic changes. - don't make up some garbage theoretical example: give a hard example of output that actually didn't have enough information. And yes, we'll just replace the %p with %px when that last situation holds. Really. Really really. But it needs to be a real example, not a "what if" that doesn't make sense. Not some pet theory that doesn't hold water. This whole "what if it was a poison pointer" argument is a _prime_ example of pure and utter garbage. If we have an oops, and it was due a poison value or an err-pointer that we dereferenced, we will *see* the poison value. It will be right there in the register state. It will be right there in the bad address. It will be quite visible. And yes, we had a few cases where the hashing actually did hide the values, and I've been applying patches to turn those from %p to %px. But it had better be actual real cases, and real thought out situations. Not "let's just randomly pick values that we don't hash". Linus