Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp301330pxb; Wed, 20 Oct 2021 23:02:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbEgWo/303sGmzuxqoaDhAAbecLjQ49c9ao/wdwr4haRcz87gYcbI9KajId5ND58XSeEIa X-Received: by 2002:aa7:9099:0:b0:44c:a3b5:ca52 with SMTP id i25-20020aa79099000000b0044ca3b5ca52mr3849482pfa.85.1634796163802; Wed, 20 Oct 2021 23:02:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634796163; cv=none; d=google.com; s=arc-20160816; b=gCw6JgJPTXOAHfo5He8P851d8+aVqnTZT5P1tRL/j1v0+3w7s8EISiQ883HlWFITbk x0dsEEqdfWJuaOVBCgrwiTlMg4BzHko6T7PXfXRgg71SbmRIaKMAz4A8WiRCKJ1erQSm ZGCWTBcOhBdHyb/AuEDATJsjQIkVRt66guy4LsM+diiZuYwMtfhJ1ja4mEE+dl4Y1G5j JD4cURV2M4TbFq2ryWk2XYVLxfan0i4xvqIo7drK1d9OyjY8AHnqBH/yTWSzkLudqaZN RWR1Xim1CHBIVE/zRv39o9aGEHWKf1rLSZ+Q7+MGOhb37s9uNwZIpPOuEasASj3g90bt di9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=xTVsi87T0lDEPgn8Tsk62laBFA4FkXChR4d7SeUQje8=; b=lggOGye//6SO7hRmhaBqdQ37Dra36YyfC0hX9ZNv9A8EG/j9YczenHSFO76ImeeNl6 kDC0ZoljYsjlzkKHZxyd80VKk4bwVjUqab4uoZWYvNpXZt6j1xztdFpwXrR6L7dLHEtz 9aFSUT4ryl8ZT/v8rQlxskg0hjX278rud+QyxePuLZRYGecW8tdrKnMAaoyRjsN6InPM 8n12/8CanGnbVSqOpKGc7qx8alVijPqCcjTWKclj5QDzU4Z+y9HVRPHlbSjZzgey4Tkl efKQinIbQav9GLGfC1rfNscblo0CWfQRy3LE68RKcCsmTs4x3FIvsKKwAz4RLUB7CFa+ Iq8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="tHM/UYL4"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d5si3805083plr.252.2021.10.20.23.02.30; Wed, 20 Oct 2021 23:02:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="tHM/UYL4"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229597AbhJUGD3 (ORCPT + 99 others); Thu, 21 Oct 2021 02:03:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbhJUGD1 (ORCPT ); Thu, 21 Oct 2021 02:03:27 -0400 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80839C061749 for ; Wed, 20 Oct 2021 23:01:12 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id r6so12506030oiw.2 for ; Wed, 20 Oct 2021 23:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xTVsi87T0lDEPgn8Tsk62laBFA4FkXChR4d7SeUQje8=; b=tHM/UYL427rxn2tWoiTDXd3iQU9Vke57HC8n9OC5xFSWoVyx3H19wemimQ2tb9JgS5 O48FSxpozzSGE3zWCEfm7lI5xW+pkbJw7X8J76GrAU8IvvHyy5myTDlKMJb3LyVUsbql ScqdyvZztT1r5Fg6yBOBmi6ux0phlBlJulSKvqsZ8dzhH7Mxf+cwFxjpn2qOsl/ZhtCH zCmqZo/TkkQroeaRE5mn+01i8Sw30eWgkDtNMn3vMdJ9NzIccHKFQX+OtYFncQU0VFh0 QM0EnDM9wrGPiIKr4JCGt0Q66ezaRLNPuAXHD8TR8IbTNmtkYZhnwlJeQ3P5MvS8n3yS Lw5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xTVsi87T0lDEPgn8Tsk62laBFA4FkXChR4d7SeUQje8=; b=nSvj+VN+zj5GWU+bMCkrwyKfS7AURagFucJxQ/IbQ8+lhrpXu7v2oGEpk1htAilroE kaNmp/inbGXw+zeBWzQgJkK9XnZUaoudPoYAfNfHyC2uepzC49nZu6GR3278b5p9qxIk sSlrrYKV8A84eQioclnd5yyyNxuWxIbFv912vj6y8p7G4iuFxKjqP7gFFQ81oYX0Th6Z F9VjHE+oDIobcLHsbLlH394/R1xZpErgjfMq/MfF5j3XvbuIiHpUNL89oDSkcaRQMG4u 293jIH1EGauiCcZhWlJcinM3ogVMPsbqz3N5FdXVXDPsMT/HHjAPLV+uKTsbySxVVZyk Pc4w== X-Gm-Message-State: AOAM5333XSDcYspkrmyi+Zey+9ROxGryh+52RzmbsH+QTzUj3Gi0ZdDW 8dT6rSnawB2sR4oQBUYKjdZMjwzxQGIBx7bcxE0kIQ== X-Received: by 2002:a05:6808:118c:: with SMTP id j12mr2641330oil.65.1634796071409; Wed, 20 Oct 2021 23:01:11 -0700 (PDT) MIME-Version: 1.0 References: <20211020200039.170424-1-keescook@chromium.org> In-Reply-To: <20211020200039.170424-1-keescook@chromium.org> From: Marco Elver Date: Thu, 21 Oct 2021 08:00:00 +0200 Message-ID: Subject: Re: [PATCH] compiler-gcc.h: Define __SANITIZE_ADDRESS__ under hwaddress sanitizer To: Kees Cook Cc: Miguel Ojeda , Arnd Bergmann , Nathan Chancellor , Nick Desaulniers , Andrew Morton , Will Deacon , Arvind Sankar , Masahiro Yamada , llvm@lists.linux.dev, Ard Biesheuvel , Luc Van Oostenryck , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Andrey Konovalov , kasan-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Oct 2021 at 22:00, Kees Cook wrote: > When Clang is using the hwaddress sanitizer, it sets __SANITIZE_ADDRESS__ > explicitly: > > #if __has_feature(address_sanitizer) || __has_feature(hwaddress_sanitizer) > /* Emulate GCC's __SANITIZE_ADDRESS__ flag */ > #define __SANITIZE_ADDRESS__ > #endif Hmm, the comment is a little inaccurate if hwaddress sanitizer is on, but I certainly wouldn't want compiler-clang.h to start emulating gcc here and start defining __SANITIZE_HWADDRESS__ if the places where we check it are the same as __SANITIZE_ADDRESS__. So this patch is the right approach. > Once hwaddress sanitizer was added to GCC, however, a separate define > was created, __SANITIZE_HWADDRESS__. The kernel is expecting to find > __SANITIZE_ADDRESS__ in either case, though, and the existing string > macros break on supported architectures: > > #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ > !defined(__SANITIZE_ADDRESS__) > > where as other architectures (like arm32) have no idea about hwaddress > sanitizer and just check for __SANITIZE_ADDRESS__: > > #if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__) arm32 doesn't support KASAN_SW_TAGS, so I think the bit about arm32 is irrelevant. Only arm64 can, and the reason that arm64 doesn't check against "defined(CONFIG_KASAN)" is because we also have KASAN_HW_TAGS (no compiler instrumentation). > This would lead to compiler foritfy self-test warnings when building > with CONFIG_KASAN_SW_TAGS=y: > > warning: unsafe memmove() usage lacked '__read_overflow2' symbol in lib/test_fortify/read_overflow2-memmove.c > warning: unsafe memcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-memcpy.c > ... > > Sort this out by also defining __SANITIZE_ADDRESS__ in GCC under the > hwaddress sanitizer. > > Suggested-by: Arnd Bergmann > Cc: Nathan Chancellor > Cc: Nick Desaulniers > Cc: Miguel Ojeda > Cc: Andrew Morton > Cc: Marco Elver > Cc: Will Deacon > Cc: Arvind Sankar > Cc: Masahiro Yamada > Cc: llvm@lists.linux.dev > Signed-off-by: Kees Cook Other than that, Reviewed-by: Marco Elver Thanks! > --- > I'm intending to take this via my overflow series, since that is what introduces > the compile-test regression tests (which found this legitimate bug). :) > > -Kees > --- > include/linux/compiler-gcc.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h > index 6f24eb8c5dda..ccbbd31b3aae 100644 > --- a/include/linux/compiler-gcc.h > +++ b/include/linux/compiler-gcc.h > @@ -121,6 +121,14 @@ > #define __no_sanitize_coverage > #endif > > +/* > + * Treat __SANITIZE_HWADDRESS__ the same as __SANITIZE_ADDRESS__ in the kernel, > + * matching the defines used by Clang. > + */ > +#ifdef __SANITIZE_HWADDRESS__ > +#define __SANITIZE_ADDRESS__ > +#endif > + > /* > * Turn individual warnings and errors on and off locally, depending > * on version. > -- > 2.30.2 >