[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <PAXPR04MB83042668CE3A29542EF18657EBBD9@PAXPR04MB8304.eurprd04.prod.outlook.com>
Date: Fri, 1 Jul 2022 06:32:29 +0000
From: Zhipeng Wang <zhipeng.wang_1@....com>
To: Sami Tolvanen <samitolvanen@...gle.com>,
Wolfram Sang <wsa@...nel.org>,
Kees Cook <keescook@...omium.org>
CC: "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH] i2c: core: Disable i2c_generic_scl_recovery
callback checks with CFI
Hi,
I tested this change on kernel 5.15 and it works. Thanks.
BRs,
Zhipeng
-----Original Message-----
From: Sami Tolvanen <samitolvanen@...gle.com>
Sent: 2022年6月30日 23:55
To: Wolfram Sang <wsa@...nel.org>; Zhipeng Wang <zhipeng.wang_1@....com>; Kees Cook <keescook@...omium.org>
Cc: linux-i2c@...r.kernel.org; LKML <linux-kernel@...r.kernel.org>
Subject: [EXT] Re: [PATCH] i2c: core: Disable i2c_generic_scl_recovery callback checks with CFI
Caution: EXT Email
On Wed, Jun 29, 2022 at 12:29 PM Wolfram Sang <wsa@...nel.org> wrote:
>
> On Tue, Jun 28, 2022 at 10:41:55AM +0800, Zhipeng Wang wrote:
> > CONFIG_CFI_CLANG breaks cross-module function address equality,
> > which breaks i2c_generic_scl_recovery as it compares a locally taken
> > function address to a one passed from a different module. Remove
> > these sanity checks for now.
>
> Can't we better fix a) the code or b) CFI?
Yes, we're working on fixing CFI:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20220610233513.1798771-1-samitolvanen%40google.com%2F&data=05%7C01%7Czhipeng.wang_1%40nxp.com%7Cc9599657c9d64ae43bd108da5ab0eb0a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637922013151312330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=djDZ8gNPGnIKz7DfX4w3psZf44zHnph7FflOLa%2F4Qnk%3D&reserved=0
In the meantime, the possible workarounds are all more or less hacky.
Perhaps a slightly less intrusive alternative would be to add a __cficanonical attribute to i2c_generic_scl_recovery and use the
function_nocfi() macro when referencing it elsewhere?
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index d43db2c3876e..dda93c5471f0 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -197,6 +197,11 @@ static int i2c_generic_bus_free(struct i2c_adapter *adap)
#define RECOVERY_NDELAY 5000
#define RECOVERY_CLK_CNT 9
+#ifdef CONFIG_CFI_CLANG
+#undef i2c_generic_scl_recovery
+#endif
+
+__cficanonical
int i2c_generic_scl_recovery(struct i2c_adapter *adap) {
struct i2c_bus_recovery_info *bri = adap->bus_recovery_info; diff --git a/include/linux/i2c.h b/include/linux/i2c.h index fbda5ada2afc..7310cbdbd940 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -663,6 +663,10 @@ int i2c_recover_bus(struct i2c_adapter *adap);
/* Generic recovery routines */
int i2c_generic_scl_recovery(struct i2c_adapter *adap);
+#ifdef CONFIG_CFI_CLANG
+#define i2c_generic_scl_recovery
+function_nocfi(i2c_generic_scl_recovery)
+#endif
+
/**
* struct i2c_adapter_quirks - describe flaws of an i2c adapter
* @flags: see I2C_AQ_* for possible flags and read below
Kees, any thoughts on the least terrible path forward here?
Zhipeng, if you want to test this on an older kernel, please note that you'll also need to cherry-pick commit e6f3b3c9c109ed57230996cf4a4c1b8ae7e36a81.
Sami
Powered by blists - more mailing lists