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=-13.3 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,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 1324CC433E0 for ; Thu, 18 Mar 2021 21:39:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFC8664F38 for ; Thu, 18 Mar 2021 21:39:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231137AbhCRVip (ORCPT ); Thu, 18 Mar 2021 17:38:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230506AbhCRVi0 (ORCPT ); Thu, 18 Mar 2021 17:38:26 -0400 Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97B4BC06175F for ; Thu, 18 Mar 2021 14:38:24 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id l4so2366332vsc.7 for ; Thu, 18 Mar 2021 14:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vLPqaFCjOxJqP96ilPAU1cPfZQuKxpOHXRuDS0s7Vr4=; b=qKVpWtCjskEKfxSobzVob96NxKhzoHpA0zkVpey6v9nz5hqX4fwpWRs2r3Xv0LtQVY G16K6pLlLiiOgiA9WlvBYuNv+dkBxVQoBMTZmRC3drafHcUHKnQM/tG/M+cxNlkBKFlD 6s0+yKEf1+/y0f7FoLfouj1leYGLXXX0BHvTCWQ+suw1xpi/HPjaWWJGI7rE5Zq4hjN+ KeG6ltSdPXps4+kFCWvGrU0ia0VmTHM2GBqcg/2BbR/sCeCZJbCtvjlsmF4re7pImMHk IhFvMOnUBJEqxCQDOIJTiaQI5tXqy8l13Wdqav4qDmK3cuJjAHbGFKOiSQWrw4vDipzM ux1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vLPqaFCjOxJqP96ilPAU1cPfZQuKxpOHXRuDS0s7Vr4=; b=ZG6qr7NiR9rzlZyl1aTPbhy9kft3vw5y2aVPtbmuGaBjnx+dQpXALqxufgdL8rs0d6 O15C+1xL88R30GECGLr8upsEm6dYHcXt9zeAlChYtZNrLEvEkesBUzdUD73qS+4bntmL +kLL96ZuchsOUTtRFdX4/ppENpDJUqiXB/WnfbxP+GfAVvdFDQcqtiA9heix26+FgMJs wHGRLijbPTH6HEwjJS15EEC7qFu5Qru4SbE/2LHLsrBXOvtlgH+95BzEmSHnrAtQrmWg +oxMYKicxFj93QUJ8o7y9t4BSplU4Br3CE9I33C0kfCyFkKYaWFtyP2npYlggpcs4mHe sCgQ== X-Gm-Message-State: AOAM533bPETMagacqxtiI2rtGZKfKZZMiw//Wb5uQXtv/iikK3UABvd/ QmLaBRLSY+pRRzpRw489IPNo5KLCh80BQb8onjKfUA== X-Google-Smtp-Source: ABdhPJyaMaWSU8mQS4gTjUoMCHt/hL7J7EWOKPoWt/RxfzbbDBNbfggOD5G6oZscrzSei7ViS8Oslpe0+7Gv7JZE5Pk= X-Received: by 2002:a67:2803:: with SMTP id o3mr1141643vso.36.1616103503542; Thu, 18 Mar 2021 14:38:23 -0700 (PDT) MIME-Version: 1.0 References: <20210318171111.706303-1-samitolvanen@google.com> <20210318171111.706303-6-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Thu, 18 Mar 2021 14:38:12 -0700 Message-ID: Subject: Re: [PATCH v2 05/17] workqueue: use WARN_ON_FUNCTION_MISMATCH To: Nick Desaulniers Cc: Kees Cook , Nathan Chancellor , Masahiro Yamada , Will Deacon , Jessica Yu , Arnd Bergmann , Tejun Heo , "Paul E. McKenney" , Christoph Hellwig , bpf , linux-hardening@vger.kernel.org, linux-arch , Linux ARM , Linux Kbuild mailing list , PCI , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Mar 18, 2021 at 11:50 AM Nick Desaulniers wrote: > > On Thu, Mar 18, 2021 at 10:11 AM Sami Tolvanen wrote: > > > > With CONFIG_CFI_CLANG, a callback function passed to > > __queue_delayed_work from a module points to a jump table entry > > defined in the module instead of the one used in the core kernel, > > which breaks function address equality in this check: > > > > WARN_ON_ONCE(timer->function != delayed_work_timer_fn); > > > > Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning > > when CFI and modules are both enabled. > > Does __cficanonical help with such comparisons? Or would that be a > very invasive change, if the concern was to try to keep these checks > in place for CONFIG_CFI_CLANG? The last time I checked, Clang ignored the __cficanonical attribute in header files, which means it would still generate a local jump table entry in each module for such functions, and the comparison here would fail. We could avoid the issue by using __cficanonical for the callback function *and* using __va_function() when we take the function address in modules, but that feels way too invasive for this particular use case. Sami