| Message ID | 20221102161906.2781508-1-nathan@kernel.org |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp9523wru;
Wed, 2 Nov 2022 09:25:15 -0700 (PDT)
X-Google-Smtp-Source:
AMsMyM4pg8Kmg46klbk9C3Y7NnxOdHk43dfmq6448q8kbJ3tCs6mhQijK7/kTpdlLggffkn6T+Yh
X-Received: by 2002:a17:90a:d244:b0:213:aa62:7a91 with SMTP id
o4-20020a17090ad24400b00213aa627a91mr24440952pjw.101.1667406315059;
Wed, 02 Nov 2022 09:25:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1667406315; cv=none;
d=google.com; s=arc-20160816;
b=tuIHNxi+g2eDh8nehSncUT3pCIj4ZA+pmwD6XTF566SVsJ6edmcY2+n5rt+H4ChBa4
kd6UZVDEMCNf+OkJbTEAJvZfYZPb856JnKxG4ZAp2p0HMydKAkGiUWqLmslsLvm9pC6N
YmvD6ebLNxmZ68qIvnSaMSeqpmF5LldTkrX74SQ/6GurDKRky/dgIVwuNRnF2oBA7vNc
UY64b8zMtiHWywZuTunpA3OOIGNfv7EuIHJutZ6dwNYgfG5upp5Zwt16vxUCu0b0JBHB
kusSw/+Te16z//KS3RCIPFTFj5Po7z+x80QqftvuKUbxIPzdVBdfQrv1Tmw4cxVrVEsF
fvLQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:message-id:date:subject:cc:to:from:dkim-signature;
bh=SUFB8VcGiP6agYdEcbV967/WbraLjaIFTEkJOVVet/8=;
b=pI4kdN0M82xpgZJzDxNq1oljXfkDh76/iJLuHMxD8LyFuay2L6rSryuL3aTaJcY2kv
u7ddrBx+jR19epXbz2bz/81vZDQhup13NbF1xJbH8tHct2PpoV9BXHj8jjdDlMHP7cLz
erchyt4XVK4XA8w69pxJSTsEgTbt7c0iMTO6OzXg6MAOrZRmg9WV59g1Q96VARTb0YJL
8ENQ0ldZcqrSy2e7620yP1Okuih93oLcMHXbgd4seiYMeeGhHCmnsT6QG3O4+VuA9dY3
UYPy22cGLDFMBFo48mXJZqiP6KBDeSV9LCgMG32tEwm7NEPHxuPkgKpl3dJ2nugLJpHa
oAbw==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@kernel.org header.s=k20201202 header.b=aDP0qW4z;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
n13-20020a170902d2cd00b00186bb2e85c4si18474785plc.429.2022.11.02.09.24.57;
Wed, 02 Nov 2022 09:25:15 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
dkim=pass header.i=@kernel.org header.s=k20201202 header.b=aDP0qW4z;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S231767AbiKBQYg (ORCPT <rfc822;yves.mi.zy@gmail.com> + 99 others);
Wed, 2 Nov 2022 12:24:36 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44604 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S231754AbiKBQYJ (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Wed, 2 Nov 2022 12:24:09 -0400
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65238FD6;
Wed, 2 Nov 2022 09:19:18 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ams.source.kernel.org (Postfix) with ESMTPS id AA2A7B8236B;
Wed, 2 Nov 2022 16:19:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94C2BC433D6;
Wed, 2 Nov 2022 16:19:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1667405955;
bh=fzJ4CnsGQWbTXfboP1sPJL+W4uTxIl+/qSJ9/kCCSe0=;
h=From:To:Cc:Subject:Date:From;
b=aDP0qW4zK1VPnYvuwnPkhvje0RhOPlsbsorxPBBAYSqcHAtE2fKCrfx3/P8IKjC4c
WpMQLDhKwXirS0C4xaTtKwcnHJOYcNt0iv9kODbB7ERWC6hH9lwSXg7/dfMZiKqa5o
8WKYgFbvKozUfEKWYH7qJBFkBCK38KJW+UaYV/DnataywfWNlJZ9a+8HGjM57H1agJ
hgPw1sR1WwrJoCEKkRSp2ZIvh6mCQB+iIDXbRaVHIihg2Bz8PnpytnQqt1EaCCRFXV
4ogoixf+jS6G6z9/X7eZ0VHXiC6NZHaGhXJImCqpQFKvbIdW6it0QPx4ZuWql1xaaV
U5CStX3Vbm9fQ==
From: Nathan Chancellor <nathan@kernel.org>
To: James Smart <james.smart@broadcom.com>,
Ram Vegesna <ram.vegesna@broadcom.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
Nick Desaulniers <ndesaulniers@google.com>,
Tom Rix <trix@redhat.com>, Kees Cook <keescook@chromium.org>,
Sami Tolvanen <samitolvanen@google.com>, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org, patches@lists.linux.dev,
Nathan Chancellor <nathan@kernel.org>
Subject: [PATCH] scsi: elx: libefc: Fix second parameter type in state
callbacks
Date: Wed, 2 Nov 2022 09:19:06 -0700
Message-Id: <20221102161906.2781508-1-nathan@kernel.org>
X-Mailer: git-send-email 2.38.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1748402244544193784?=
X-GMAIL-MSGID: =?utf-8?q?1748402244544193784?=
|
| Series |
scsi: elx: libefc: Fix second parameter type in state callbacks
|
|
Commit Message
Nathan Chancellor
Nov. 2, 2022, 4:19 p.m. UTC
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/scsi/elx/libefc/efc_node.c:811:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict]
ctx->current_state = state;
^ ~~~~~
drivers/scsi/elx/libefc/efc_node.c:878:21: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict]
node->nodedb_state = state;
^ ~~~~~
drivers/scsi/elx/libefc/efc_node.c:905:6: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' from 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') [-Werror,-Wincompatible-function-pointer-types-strict]
pf = node->nodedb_state;
^ ~~~~~~~~~~~~~~~~~~
drivers/scsi/elx/libefc/efc_device.c:455:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict]
node->nodedb_state = __efc_d_init;
^ ~~~~~~~~~~~~
drivers/scsi/elx/libefc/efc_sm.c:41:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict]
ctx->current_state = state;
^ ~~~~~
The type of the second parameter in the prototypes of ->current_state()
and ->nodedb_state() ('u32') does not match the implementations, which
have a second parameter type of 'enum efc_sm_event'. Update the
prototypes to have the correct second parameter type, clearing up all
the warnings and CFI failures.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/scsi/elx/libefc/efclib.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
Comments
On Wed, Nov 02, 2022 at 09:19:06AM -0700, Nathan Chancellor wrote: > With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), > indirect call targets are validated against the expected function > pointer prototype to make sure the call target is valid to help mitigate > ROP attacks. If they are not identical, there is a failure at run time, > which manifests as either a kernel panic or thread getting killed. A > proposed warning in clang aims to catch these at compile time, which > reveals: > > drivers/scsi/elx/libefc/efc_node.c:811:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] > ctx->current_state = state; > ^ ~~~~~ > drivers/scsi/elx/libefc/efc_node.c:878:21: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] > node->nodedb_state = state; > ^ ~~~~~ > drivers/scsi/elx/libefc/efc_node.c:905:6: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' from 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') [-Werror,-Wincompatible-function-pointer-types-strict] > pf = node->nodedb_state; > ^ ~~~~~~~~~~~~~~~~~~ > > drivers/scsi/elx/libefc/efc_device.c:455:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] > node->nodedb_state = __efc_d_init; > ^ ~~~~~~~~~~~~ > > drivers/scsi/elx/libefc/efc_sm.c:41:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] > ctx->current_state = state; > ^ ~~~~~ > > The type of the second parameter in the prototypes of ->current_state() > and ->nodedb_state() ('u32') does not match the implementations, which > have a second parameter type of 'enum efc_sm_event'. Update the > prototypes to have the correct second parameter type, clearing up all > the warnings and CFI failures. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1750 > Reported-by: Sami Tolvanen <samitolvanen@google.com> > Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org>
Nathan, > With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), > indirect call targets are validated against the expected function > pointer prototype to make sure the call target is valid to help > mitigate ROP attacks. If they are not identical, there is a failure at > run time, which manifests as either a kernel panic or thread getting > killed. A proposed warning in clang aims to catch these at compile > time, which reveals: Applied to 6.2/scsi-staging, thanks!
On Wed, 2 Nov 2022 09:19:06 -0700, Nathan Chancellor wrote: > With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), > indirect call targets are validated against the expected function > pointer prototype to make sure the call target is valid to help mitigate > ROP attacks. If they are not identical, there is a failure at run time, > which manifests as either a kernel panic or thread getting killed. A > proposed warning in clang aims to catch these at compile time, which > reveals: > > [...] Applied to 6.2/scsi-queue, thanks! [1/1] scsi: elx: libefc: Fix second parameter type in state callbacks https://git.kernel.org/mkp/scsi/c/3d75e766b58a
diff --git a/drivers/scsi/elx/libefc/efclib.h b/drivers/scsi/elx/libefc/efclib.h index dde20891c2dd..57e338612812 100644 --- a/drivers/scsi/elx/libefc/efclib.h +++ b/drivers/scsi/elx/libefc/efclib.h @@ -58,10 +58,12 @@ enum efc_node_send_ls_acc { #define EFC_LINK_STATUS_UP 0 #define EFC_LINK_STATUS_DOWN 1 +enum efc_sm_event; + /* State machine context header */ struct efc_sm_ctx { void (*current_state)(struct efc_sm_ctx *ctx, - u32 evt, void *arg); + enum efc_sm_event evt, void *arg); const char *description; void *app; @@ -365,7 +367,7 @@ struct efc_node { int prev_evt; void (*nodedb_state)(struct efc_sm_ctx *ctx, - u32 evt, void *arg); + enum efc_sm_event evt, void *arg); struct timer_list gidpt_delay_timer; u64 time_last_gidpt_msec;