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 3F914C43381 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 038D764F59 for ; Thu, 18 Mar 2021 21:39:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231983AbhCRVio (ORCPT ); Thu, 18 Mar 2021 17:38:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231236AbhCRVi0 (ORCPT ); Thu, 18 Mar 2021 17:38:26 -0400 Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB892C061761 for ; Thu, 18 Mar 2021 14:38:24 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id k14so2372764vsb.6 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=sBVhFMDUttQLyQJScJ57PYetHkontjHs9UKjQ4iUjGl9NT8rI2X9zJSjdgH0y9PNwo 2CkiG13vEvkHqQ9+XatEZT89bG3K9r3knzMupr0oOKptWdFbAPLB7vGXLstSiKjALyh9 d+eP2fTayo6ye+zLWXlTctFC2sYYthd83r3+CeJqVMAyWJ9PGAHkUQS3OwNm186AG0P3 XSDKChDqaH84OXGlCRYco4GeOX5Swh4lOQNi35TBg5czAY6rJ07F9bJn+ThdbUPM6e1R VBnBmATyP081h2upXiiEdoFDvOp4BgwUQXQAXT2Jb/S2LZmvwHf7H04FTAMJB8iXN+pK 6R1Q== X-Gm-Message-State: AOAM533WOf6sncKvW3WBy2b6L+4Ai+kHiOTd9U2fQtGjeAmWYztp5NHg DFkjkizUBBdScZ5tLBHs9c9O3yzkP8dN4NdeazGkdQ== 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: linux-pci@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