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