Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752855AbdLSWYQ (ORCPT ); Tue, 19 Dec 2017 17:24:16 -0500 Received: from mail-oi0-f51.google.com ([209.85.218.51]:41352 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750859AbdLSWYM (ORCPT ); Tue, 19 Dec 2017 17:24:12 -0500 X-Google-Smtp-Source: ACJfBotjV8h992mlJOcBtX4OMPZryo3F/J5o2wS8KJ8q94V8I4czi5HOSvGKIfpSYeIx0D2GpGyR4Q== Subject: Re: BUG: bad usercopy in memdup_user To: Linus Torvalds , Matthew Wilcox Cc: "Tobin C. Harding" , Dmitry Vyukov , Kees Cook , Tetsuo Handa , Linux-MM , syzbot , David Windsor , keun-o.park@darkmatter.ae, LKML , Mark Rutland , Ingo Molnar , syzkaller-bugs@googlegroups.com, Will Deacon References: <001a113e9ca8a3affd05609d7ccf@google.com> <6a50d160-56d0-29f9-cfed-6c9202140b43@I-love.SAKURA.ne.jp> <20171219083746.GR19604@eros> <20171219132246.GD13680@bombadil.infradead.org> From: Laura Abbott Message-ID: <595380a4-7d3c-5ed6-2158-d8acff42906b@redhat.com> Date: Tue, 19 Dec 2017 14:24:08 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1956 Lines: 51 On 12/19/2017 01:36 PM, Linus Torvalds wrote: > On Tue, Dec 19, 2017 at 5:22 AM, Matthew Wilcox wrote: >> >> Could we have a way to know that the printed address is hashed and not just >> a pointer getting completely scrogged? Perhaps prefix it with ... a hash! >> So this line would look like: > > The problem with that is that it will break tools that parse things. > > So no, it won't work. > > When we find something like this, we should either remove it, fix the > permissions, or switch to %px. > > In this case, there's obviously no permission issue: it's an error > report. So it's either "remove it, or switch to %px". > > I'm personally not clear on whether the pointer really makes any sense > at all. But if it does, it should just be changed to %px, since it's a > bug report. > > But honestly, what do people expect that the pointer value will > actually tell you if it is unhashed? > > I suspect that an "offset and size within the kernel object" value > might make sense. But what does the _pointer_ tell you? > > I've noticed this with pretty much every report. People get upset > about the hashing, but don't seem to actually be able to ever tell > what the f*ck they would use the non-hashed pointer value for. > > I've asked for this before: whenever somebody complains about the > hashing, you had better tell exactly what the unhashed value would > have given you, and how it would have helped debug the problem. > > Because if you can't tell that, then dammit, then we should just > _remove_ the stupid %p. > > Instead, people ask for "can I get everything unhashed" even when they > can't give a reason for it. > > Linus > It's most useful in the "I really have no idea what's going on" case. Sometimes just narrowing down if a pointer was kernel or vmalloc or kmap or whatever is the only starting point. I agree that size plus offset from object would be helpful. Thanks, Laura