From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BAD8BC433E2 for ; Wed, 16 Sep 2020 18:53:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D11120809 for ; Wed, 16 Sep 2020 18:53:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PUU8fv2n" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727923AbgIPSxi (ORCPT ); Wed, 16 Sep 2020 14:53:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727271AbgIPSIt (ORCPT ); Wed, 16 Sep 2020 14:08:49 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4559FC0086CF for ; Wed, 16 Sep 2020 06:40:38 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id z9so3103834wmk.1 for ; Wed, 16 Sep 2020 06:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uEjVdCuhEoV9lb5ls6kMmq0ECr43Rh1pbVRxVP/xc0E=; b=PUU8fv2nYs0tjxbo5vnP2us18PfVb1Xunkump0q2oq1WUGUGx/Lcgus2dW8plEctBu Qs795uckGKFqlBwaeJHxNgTa+zHUOIdMlaH3B20/ByLXLBl1QewIY26uQl3s6wxgl40X y7Sl4VoAKpf9y+O370S6csA9+tABN6AXQ9HcHeTZqbP97j+ZCcAFKfcYEXVp30f3T7oT AKvU83SX8xyIW8vmTdkzt38dQ3ZZvj9WB+i6K2xhG2tMsoEdmckLp5IrXXlCBCOLWG47 PpIwBYRZreCvfOOlJ031bSRstEvlHX/qqXpdEFTM3AnwGbd4Y0lA6o8uLVziWP/yTVL3 MYZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uEjVdCuhEoV9lb5ls6kMmq0ECr43Rh1pbVRxVP/xc0E=; b=dpjAJVMe+qkNgc6Q+MqZKKUmxrfVbt2ewbEwBdLvwhlsVWUsZ4CrF1t2SwfPBD1QhQ LSXcARBVrcSzmZPhewIJ8KlkBRqSrMafzgmk88ByfshQ1NKfQvnxgiA2U3/0/FKg8/q+ RflRM4MWdgWNylkFYHaAmzn9RCv7gfEosGW0EFq5EI8pCIlFZXK0sVICzNCObwh0njR6 YGDAJmm9z4hTEk31RvK0YWJTs3zLDOabMi8vvrxAjKdc1gHWi24jXBrHA/TM57HGfuPS 4EYKZMvLm/4s7H1jdHSP1JgEzjQL87GZQzuHHSX8F3whe/4WV7uULQfz2VqICoi891kp AZrg== X-Gm-Message-State: AOAM532HMbcVq5tTls1ltS+ocrPTKKcnVlfkh+Xn+R3nYpPDVLYJQa7Z gkDPrNyljc3Ip61VqNUEzVgObQ== X-Google-Smtp-Source: ABdhPJwkYqBdHOlcj/6E3C/Hg3AY0p7Pq+MV0hPCUD7Q9dFfXQXlMg4ViJJ/8esSCNDeaapoa/urtw== X-Received: by 2002:a1c:7714:: with SMTP id t20mr5048312wmi.55.1600263636710; Wed, 16 Sep 2020 06:40:36 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id o16sm31108612wrp.52.2020.09.16.06.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 06:40:35 -0700 (PDT) Date: Wed, 16 Sep 2020 15:40:29 +0200 From: Marco Elver To: George Popescu Cc: Kees Cook , maz@kernel.org, Catalin Marinas , Will Deacon , Masahiro Yamada , Michal Marek , Linux ARM , kvmarm@lists.cs.columbia.edu, LKML , Linux Kbuild mailing list , clang-built-linux , james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, Nathan Chancellor , Nick Desaulniers , David Brazdil , broonie@kernel.org, Fangrui Song , Andrew Scull , Andrew Morton , Dmitry Vyukov , Thomas Gleixner , Arnd Bergmann , kasan-dev@googlegroups.com, andreyknvl@google.com, glider@google.com Subject: Re: [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang Message-ID: <20200916134029.GA1146904@elver.google.com> References: <20200914172750.852684-1-georgepope@google.com> <20200914172750.852684-7-georgepope@google.com> <202009141509.CDDC8C8@keescook> <20200915102458.GA1650630@google.com> <20200915120105.GA2294884@google.com> <20200916074027.GA2946587@google.com> <20200916121401.GA3362356@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200916121401.GA3362356@google.com> User-Agent: Mutt/1.14.4 (2020-06-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 16, 2020 at 12:14PM +0000, George Popescu wrote: > On Wed, Sep 16, 2020 at 10:32:40AM +0200, Marco Elver wrote: > > On Wed, 16 Sep 2020 at 09:40, George Popescu wrote: > > > On Tue, Sep 15, 2020 at 07:32:28PM +0200, Marco Elver wrote: > > > > On Tue, 15 Sep 2020 at 14:01, George Popescu wrote: > > > > > On Tue, Sep 15, 2020 at 01:18:11PM +0200, Marco Elver wrote: > > > > > > On Tue, 15 Sep 2020 at 12:25, George Popescu wrote: > > > > > > > On Mon, Sep 14, 2020 at 03:13:14PM -0700, Kees Cook wrote: > > > > > > > > On Mon, Sep 14, 2020 at 05:27:42PM +0000, George-Aurelian Popescu wrote: > > > > > > > > > From: George Popescu > > > > > > > > > > > > > > > > > > When the kernel is compiled with Clang, UBSAN_BOUNDS inserts a brk after > > > > > > > > > the handler call, preventing it from printing any information processed > > > > > > > > > inside the buffer. > > > > > > > > > For Clang -fsanitize=bounds expands to -fsanitize=array-bounds and > > > > > > > > > -fsanitize=local-bounds, and the latter adds a brk after the handler > > > > > > > > > call > > > > > > > > > > > > > > > This would mean losing the local-bounds coverage. I tried to test it without > > > > > > > local-bounds and with a locally defined array on the stack and it works fine > > > > > > > (the handler is called and the error reported). For me it feels like > > > > > > > --array-bounds and --local-bounds are triggered for the same type of > > > > > > > undefined_behaviours but they are handling them different. > > > > > > > > > > > > Does -fno-sanitize-trap=bounds help? [...] > > Your full config would be good, because it includes compiler version etc. > My full config is: Thanks. Yes, I can reproduce, and the longer I keep digging I start wondering why we have local-bounds at all. It appears that local-bounds finds a tiny subset of the issues that KASAN finds: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131021/091536.html http://llvm.org/viewvc/llvm-project?view=revision&revision=193205 fsanitize=undefined also does not include local-bounds: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks And the reason is that we do want to enable KASAN and UBSAN together; but local-bounds is useless overhead if we already have KASAN. I'm inclined to say that what you propose is reasonable (but the commit message needs to be more detailed explaining the relationship with KASAN) -- but I have no idea if this is going to break somebody's usecase (e.g. find some OOB bugs, but without KASAN -- but then why not use KASAN?!) I'll ask some more people on LLVM side. Thanks, -- Marco From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E4EDC433E2 for ; Wed, 16 Sep 2020 15:12:01 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D35DE22450 for ; Wed, 16 Sep 2020 15:12:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="PUU8fv2n" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D35DE22450 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 06B8E4B41C; Wed, 16 Sep 2020 11:12:00 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QYLmbiU1Tbe; Wed, 16 Sep 2020 11:11:58 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B0BB94B31D; Wed, 16 Sep 2020 11:11:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4AEDE4B46B for ; Wed, 16 Sep 2020 09:40:39 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75DKXt23Wlhq for ; Wed, 16 Sep 2020 09:40:38 -0400 (EDT) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id EB6204B46C for ; Wed, 16 Sep 2020 09:40:37 -0400 (EDT) Received: by mail-wm1-f65.google.com with SMTP id e11so2276100wme.0 for ; Wed, 16 Sep 2020 06:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uEjVdCuhEoV9lb5ls6kMmq0ECr43Rh1pbVRxVP/xc0E=; b=PUU8fv2nYs0tjxbo5vnP2us18PfVb1Xunkump0q2oq1WUGUGx/Lcgus2dW8plEctBu Qs795uckGKFqlBwaeJHxNgTa+zHUOIdMlaH3B20/ByLXLBl1QewIY26uQl3s6wxgl40X y7Sl4VoAKpf9y+O370S6csA9+tABN6AXQ9HcHeTZqbP97j+ZCcAFKfcYEXVp30f3T7oT AKvU83SX8xyIW8vmTdkzt38dQ3ZZvj9WB+i6K2xhG2tMsoEdmckLp5IrXXlCBCOLWG47 PpIwBYRZreCvfOOlJ031bSRstEvlHX/qqXpdEFTM3AnwGbd4Y0lA6o8uLVziWP/yTVL3 MYZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uEjVdCuhEoV9lb5ls6kMmq0ECr43Rh1pbVRxVP/xc0E=; b=GXrMs1+1Z/rqKdVFDM5BQhRzGUBQJYQRQV27zLGOvDN/2uyBLy7msDPmOx2vXiSbDI 0kguw/WV6iFLJgZho7yz8ZkeeXflhX1l1FlJb2gCfzxg9FdchVShcVDE816fivpL0iRm BDQY1Nlhx1eVk70jCN0BUfmG8AEyKT8GnyxyN72rOKjPY/n6MgVW+IXw0naU2Bzjuzrt 0w4vW/Z9zbXEAYe9Fa42D8cv7z8WIOYki0wv5LKtXdW9OvtzYBgc/t1JoPKXJpeOzjYz RR7n9EBKHJEi9oj7nmPTPdfwGhNzG+DLal/v5dAoDejeUoCs141C1x1IjwBPy5urmS4M LV+Q== X-Gm-Message-State: AOAM530FPzDUtdMbkYG2NAD5j0Ic2ooFiiFb/2MT61QfPU2EDte2poue lR6VVgtvUghPdjmuXMfe42MG2g== X-Google-Smtp-Source: ABdhPJwkYqBdHOlcj/6E3C/Hg3AY0p7Pq+MV0hPCUD7Q9dFfXQXlMg4ViJJ/8esSCNDeaapoa/urtw== X-Received: by 2002:a1c:7714:: with SMTP id t20mr5048312wmi.55.1600263636710; Wed, 16 Sep 2020 06:40:36 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id o16sm31108612wrp.52.2020.09.16.06.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 06:40:35 -0700 (PDT) Date: Wed, 16 Sep 2020 15:40:29 +0200 From: Marco Elver To: George Popescu Subject: Re: [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang Message-ID: <20200916134029.GA1146904@elver.google.com> References: <20200914172750.852684-1-georgepope@google.com> <20200914172750.852684-7-georgepope@google.com> <202009141509.CDDC8C8@keescook> <20200915102458.GA1650630@google.com> <20200915120105.GA2294884@google.com> <20200916074027.GA2946587@google.com> <20200916121401.GA3362356@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200916121401.GA3362356@google.com> User-Agent: Mutt/1.14.4 (2020-06-18) X-Mailman-Approved-At: Wed, 16 Sep 2020 11:11:57 -0400 Cc: Thomas Gleixner , Catalin Marinas , glider@google.com, Will Deacon , kvmarm@lists.cs.columbia.edu, Fangrui Song , maz@kernel.org, Masahiro Yamada , kasan-dev@googlegroups.com, clang-built-linux , Linux ARM , Kees Cook , Arnd Bergmann , Linux Kbuild mailing list , andreyknvl@google.com, broonie@kernel.org, Nathan Chancellor , Dmitry Vyukov , Michal Marek , Nick Desaulniers , LKML , Andrew Morton X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Wed, Sep 16, 2020 at 12:14PM +0000, George Popescu wrote: > On Wed, Sep 16, 2020 at 10:32:40AM +0200, Marco Elver wrote: > > On Wed, 16 Sep 2020 at 09:40, George Popescu wrote: > > > On Tue, Sep 15, 2020 at 07:32:28PM +0200, Marco Elver wrote: > > > > On Tue, 15 Sep 2020 at 14:01, George Popescu wrote: > > > > > On Tue, Sep 15, 2020 at 01:18:11PM +0200, Marco Elver wrote: > > > > > > On Tue, 15 Sep 2020 at 12:25, George Popescu wrote: > > > > > > > On Mon, Sep 14, 2020 at 03:13:14PM -0700, Kees Cook wrote: > > > > > > > > On Mon, Sep 14, 2020 at 05:27:42PM +0000, George-Aurelian Popescu wrote: > > > > > > > > > From: George Popescu > > > > > > > > > > > > > > > > > > When the kernel is compiled with Clang, UBSAN_BOUNDS inserts a brk after > > > > > > > > > the handler call, preventing it from printing any information processed > > > > > > > > > inside the buffer. > > > > > > > > > For Clang -fsanitize=bounds expands to -fsanitize=array-bounds and > > > > > > > > > -fsanitize=local-bounds, and the latter adds a brk after the handler > > > > > > > > > call > > > > > > > > > > > > > > > This would mean losing the local-bounds coverage. I tried to test it without > > > > > > > local-bounds and with a locally defined array on the stack and it works fine > > > > > > > (the handler is called and the error reported). For me it feels like > > > > > > > --array-bounds and --local-bounds are triggered for the same type of > > > > > > > undefined_behaviours but they are handling them different. > > > > > > > > > > > > Does -fno-sanitize-trap=bounds help? [...] > > Your full config would be good, because it includes compiler version etc. > My full config is: Thanks. Yes, I can reproduce, and the longer I keep digging I start wondering why we have local-bounds at all. It appears that local-bounds finds a tiny subset of the issues that KASAN finds: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131021/091536.html http://llvm.org/viewvc/llvm-project?view=revision&revision=193205 fsanitize=undefined also does not include local-bounds: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks And the reason is that we do want to enable KASAN and UBSAN together; but local-bounds is useless overhead if we already have KASAN. I'm inclined to say that what you propose is reasonable (but the commit message needs to be more detailed explaining the relationship with KASAN) -- but I have no idea if this is going to break somebody's usecase (e.g. find some OOB bugs, but without KASAN -- but then why not use KASAN?!) I'll ask some more people on LLVM side. Thanks, -- Marco _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0A1EC433E2 for ; Wed, 16 Sep 2020 13:42:12 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 565E022247 for ; Wed, 16 Sep 2020 13:42:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="gRs8JhIL"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="PUU8fv2n" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 565E022247 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gRbsIO4vaEZeRfZ+L4bWWpg3+kmum2ByYQ00kygPk+w=; b=gRs8JhIL0GLJloxAfpbiFd3fR AI+65zgxWZnyqae9YwLuYCWP0tg/1XIDsqXZQQ+lGyMUAC9d0tqm8C7NYSbOLvCxISB2aU9HcWKwK NPw2Rw4QQd3JAQGYNRXk0hVIUe0+4jyXW93YNdD8rpU31bD3/LqGZtHHi7isA5Nkmptf6UPROlBe9 Ced9Q0Ms/zpslsHe0PUne9bGvD7LwtbAdxY8oinDuOohxr5aCyyWkmsVtszqhVtHlp+EdEYz2HUSr TXpnmC0Rlyc3zl6NFkUqCdHYXS9ZrMi0dK3giDqoFV1pgAh83kN4GSM4v0elO4BsbwVeDe+YDTlrp ebnm23aPw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIXfu-00066j-PZ; Wed, 16 Sep 2020 13:40:42 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIXfr-00065n-VO for linux-arm-kernel@lists.infradead.org; Wed, 16 Sep 2020 13:40:40 +0000 Received: by mail-wm1-x343.google.com with SMTP id k18so3077671wmj.5 for ; Wed, 16 Sep 2020 06:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uEjVdCuhEoV9lb5ls6kMmq0ECr43Rh1pbVRxVP/xc0E=; b=PUU8fv2nYs0tjxbo5vnP2us18PfVb1Xunkump0q2oq1WUGUGx/Lcgus2dW8plEctBu Qs795uckGKFqlBwaeJHxNgTa+zHUOIdMlaH3B20/ByLXLBl1QewIY26uQl3s6wxgl40X y7Sl4VoAKpf9y+O370S6csA9+tABN6AXQ9HcHeTZqbP97j+ZCcAFKfcYEXVp30f3T7oT AKvU83SX8xyIW8vmTdkzt38dQ3ZZvj9WB+i6K2xhG2tMsoEdmckLp5IrXXlCBCOLWG47 PpIwBYRZreCvfOOlJ031bSRstEvlHX/qqXpdEFTM3AnwGbd4Y0lA6o8uLVziWP/yTVL3 MYZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uEjVdCuhEoV9lb5ls6kMmq0ECr43Rh1pbVRxVP/xc0E=; b=GmKu9x9ZjZLvv0hgLgbDAh8UAGYt+ZFwuNhZpzdbGoWl5w1QlmSePE4ekMn/fT2C9e H5jAddw3ury9kHj6oezJrkEI8ZvDQw8e0PaeGeFwMXG0m1D0/qQVZboWtHNaNik0H7eP dFVv1QO2iTGUckwTydoZ7X0JCdSTYaMEnJoqC9wLYv2UI8Rj/GDE28JPeNzmqsCq5T/O eYM9jndcKxgQi1hmq2rjLS0wFAqFhcC6gUhGpvsHF6D+sHIgutoq82iymHBXHZGLoiNy zV9/N7hGi8FyBqnDUKw+v0+dezuuYioSvxBwZP2RuM0ujlzwh/Btajve+EwsnqPzj7HW NEeA== X-Gm-Message-State: AOAM533474rdxu3NAkIjKzDbDtf+34J6hZkRdnyevOzFyRwEaNW4cyV3 GspCV/RcdbPrFMfuivgRgTZcuA== X-Google-Smtp-Source: ABdhPJwkYqBdHOlcj/6E3C/Hg3AY0p7Pq+MV0hPCUD7Q9dFfXQXlMg4ViJJ/8esSCNDeaapoa/urtw== X-Received: by 2002:a1c:7714:: with SMTP id t20mr5048312wmi.55.1600263636710; Wed, 16 Sep 2020 06:40:36 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id o16sm31108612wrp.52.2020.09.16.06.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 06:40:35 -0700 (PDT) Date: Wed, 16 Sep 2020 15:40:29 +0200 From: Marco Elver To: George Popescu Subject: Re: [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang Message-ID: <20200916134029.GA1146904@elver.google.com> References: <20200914172750.852684-1-georgepope@google.com> <20200914172750.852684-7-georgepope@google.com> <202009141509.CDDC8C8@keescook> <20200915102458.GA1650630@google.com> <20200915120105.GA2294884@google.com> <20200916074027.GA2946587@google.com> <20200916121401.GA3362356@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200916121401.GA3362356@google.com> User-Agent: Mutt/1.14.4 (2020-06-18) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200916_094040_050151_258ABE63 X-CRM114-Status: GOOD ( 25.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Gleixner , Catalin Marinas , glider@google.com, Will Deacon , kvmarm@lists.cs.columbia.edu, Fangrui Song , maz@kernel.org, Masahiro Yamada , suzuki.poulose@arm.com, kasan-dev@googlegroups.com, clang-built-linux , Linux ARM , David Brazdil , julien.thierry.kdev@gmail.com, Kees Cook , Arnd Bergmann , Linux Kbuild mailing list , andreyknvl@google.com, broonie@kernel.org, Andrew Scull , Nathan Chancellor , Dmitry Vyukov , Michal Marek , Nick Desaulniers , LKML , james.morse@arm.com, Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 16, 2020 at 12:14PM +0000, George Popescu wrote: > On Wed, Sep 16, 2020 at 10:32:40AM +0200, Marco Elver wrote: > > On Wed, 16 Sep 2020 at 09:40, George Popescu wrote: > > > On Tue, Sep 15, 2020 at 07:32:28PM +0200, Marco Elver wrote: > > > > On Tue, 15 Sep 2020 at 14:01, George Popescu wrote: > > > > > On Tue, Sep 15, 2020 at 01:18:11PM +0200, Marco Elver wrote: > > > > > > On Tue, 15 Sep 2020 at 12:25, George Popescu wrote: > > > > > > > On Mon, Sep 14, 2020 at 03:13:14PM -0700, Kees Cook wrote: > > > > > > > > On Mon, Sep 14, 2020 at 05:27:42PM +0000, George-Aurelian Popescu wrote: > > > > > > > > > From: George Popescu > > > > > > > > > > > > > > > > > > When the kernel is compiled with Clang, UBSAN_BOUNDS inserts a brk after > > > > > > > > > the handler call, preventing it from printing any information processed > > > > > > > > > inside the buffer. > > > > > > > > > For Clang -fsanitize=bounds expands to -fsanitize=array-bounds and > > > > > > > > > -fsanitize=local-bounds, and the latter adds a brk after the handler > > > > > > > > > call > > > > > > > > > > > > > > > This would mean losing the local-bounds coverage. I tried to test it without > > > > > > > local-bounds and with a locally defined array on the stack and it works fine > > > > > > > (the handler is called and the error reported). For me it feels like > > > > > > > --array-bounds and --local-bounds are triggered for the same type of > > > > > > > undefined_behaviours but they are handling them different. > > > > > > > > > > > > Does -fno-sanitize-trap=bounds help? [...] > > Your full config would be good, because it includes compiler version etc. > My full config is: Thanks. Yes, I can reproduce, and the longer I keep digging I start wondering why we have local-bounds at all. It appears that local-bounds finds a tiny subset of the issues that KASAN finds: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131021/091536.html http://llvm.org/viewvc/llvm-project?view=revision&revision=193205 fsanitize=undefined also does not include local-bounds: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks And the reason is that we do want to enable KASAN and UBSAN together; but local-bounds is useless overhead if we already have KASAN. I'm inclined to say that what you propose is reasonable (but the commit message needs to be more detailed explaining the relationship with KASAN) -- but I have no idea if this is going to break somebody's usecase (e.g. find some OOB bugs, but without KASAN -- but then why not use KASAN?!) I'll ask some more people on LLVM side. Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel