From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933021AbdCGQj1 (ORCPT ); Tue, 7 Mar 2017 11:39:27 -0500 Received: from mail-qk0-f177.google.com ([209.85.220.177]:33235 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932759AbdCGQid (ORCPT ); Tue, 7 Mar 2017 11:38:33 -0500 MIME-Version: 1.0 In-Reply-To: References: <1eb0b1ba-3847-9bdc-8f4a-adcd34de3486@gmail.com> From: Alexander Potapenko Date: Tue, 7 Mar 2017 17:05:08 +0100 Message-ID: Subject: Re: kasan behavior when built with unsupported compiler To: Dmitry Vyukov Cc: Nikolay Borisov , Andrey Ryabinin , LKML , kasan-dev , Kees Cook 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v27GdVAX025575 On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov wrote: > On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov > wrote: >> Hello, >> >> I've been chasing a particular UAF as reported by kasan >> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >> thing which I took notice of rather lately is that I was building my >> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >> the following string: >> >> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >> -fsanitize=kernel-address is not supported by compiler >> >> >> Nevertheless, the kernel compiles and when I boot it I see the kasan >> splats as per the referenced thread. If, however, I build the kernel >> with a newer compiler version 5.4.0 kasan no longer complains. >> >> >> At this point I'm wondering whether the splats can be due to old >> compiler being used e.g. false positives or are they genuine splats and >> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >> being able to use CONFIG_KASAN it is still working since I'm seeing the >> splats. Is this valid behavior ? > > > Hi, > > Re the message that kasan is not supported while it's still enabled in the end. > I think it's an issue related to gcc plugins. Originally kasan was > supported with 5.0+ thus the message. However, later we extended this > support to 4.5+ with gcc plugins. However, that confusing message from > build system was not fixed. So yes, it's confusing and it's something > to fix, but mostly you can just ignore it. > > Re false positives with 4.7. By default I would assume that it is true > positive. Should be easy to check with manual printfs. > > Re why 5.4 does not detect it. Difficult to say. > If you confirm that it's a real bug and provide repro instructions, > then I can recheck it with latest gcc. If it's a real bug and the > latest gcc does not detect it, then we need to look more closely at > it. I afraid 5.4 won't be fixed. > It's also possible that it's a false positive in the old compiler (I > think there were some bugs). If so, I would recommend switching to a > newer compiler. I wonder if there's actual KASAN instrumentation in the kernel in question built with GCC 4.7. If there's none, there's little point in investigating this further, as the tool is anyway barely usable. Note that the report originates from something like copy_to_user() (or hard to tell the exact place - Nikolay, could you please symbolize the report?), i.e. it could be triggered even without KASAN instrumentation. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg