Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1616417 > unrolled thread

[PATCH v2] bug: further enhance use of CHECK_DATA_CORRUPTION

Started byKees Cook <keescook@chromium.org>
First post2017-04-05 00:20 +0200
Last post2017-04-05 00:20 +0200
Articles 4 — 1 participant

Back to article view | Back to linux.kernel


Contents

  [PATCH v2] bug: further enhance use of CHECK_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-04-05 00:20 +0200
    [PATCH v2 5/7] bug: Enable DEBUG_SG under BUG_ON_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-04-05 00:20 +0200
    [PATCH v2 3/7] bug: Use WARN_ONCE() for CHECK_DATA_CORRUPTION() Kees Cook <keescook@chromium.org> - 2017-04-05 00:20 +0200
    [PATCH v2 2/7] bug: Improve unlikely() in data corruption check Kees Cook <keescook@chromium.org> - 2017-04-05 00:20 +0200

#1616417 — [PATCH v2] bug: further enhance use of CHECK_DATA_CORRUPTION

FromKees Cook <keescook@chromium.org>
Date2017-04-05 00:20 +0200
Subject[PATCH v2] bug: further enhance use of CHECK_DATA_CORRUPTION
Message-ID<tsEXT-2s7-5@gated-at.bofh.it>
This continues in applying the CHECK_DATA_CORRUPTION tests where
appropriate, and pulling similar CONFIGs under the same check. Most
notably, this adds the checks to refcount_t so that system builders can
Oops their kernels when encountering a potential refcounter attack. (And
so now the LKDTM tests for refcount issues pass correctly.)

The series depends on the changes in -next made to lib/refcount.c,
so it might be easiest if this goes through the locking tree...

v2 is a rebase to -next and adjusts to using WARN_ONCE() instead of WARN().

-Kees

v1 was here: https://lkml.org/lkml/2017/3/6/720

[toc] | [next] | [standalone]


#1616418 — [PATCH v2 5/7] bug: Enable DEBUG_SG under BUG_ON_DATA_CORRUPTION

FromKees Cook <keescook@chromium.org>
Date2017-04-05 00:20 +0200
Subject[PATCH v2 5/7] bug: Enable DEBUG_SG under BUG_ON_DATA_CORRUPTION
Message-ID<tsEXU-2s7-25@gated-at.bofh.it>
In reply to#1616417
Similar to CONFIG_DEBUG_CREDENTIALS, CONFIG_DEBUG_SG already handles
calling BUG, and performs inexpensive checks. This enables it under
CONFIG_BUG_ON_DATA_CORRUPTION.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 lib/Kconfig.debug | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9a1b6b56cef4..45bfc0be38fc 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1268,7 +1268,7 @@ config DEBUG_PI_LIST
 
 config DEBUG_SG
 	bool "Debug SG table operations"
-	depends on DEBUG_KERNEL
+	depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
 	help
 	  Enable this to turn on checks on scatter-gather tables. This can
 	  help find problems with drivers that do not properly initialize
@@ -1998,6 +1998,7 @@ config BUG_ON_DATA_CORRUPTION
 	bool "Trigger a BUG when data corruption is detected"
 	select DEBUG_CREDENTIALS
 	select DEBUG_LIST
+	select DEBUG_SG
 	help
 	  This option enables several inexpensive data corruption checks.
 	  Most of these checks normally just WARN and try to further avoid
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1616421 — [PATCH v2 3/7] bug: Use WARN_ONCE() for CHECK_DATA_CORRUPTION()

FromKees Cook <keescook@chromium.org>
Date2017-04-05 00:20 +0200
Subject[PATCH v2 3/7] bug: Use WARN_ONCE() for CHECK_DATA_CORRUPTION()
Message-ID<tsEXU-2s7-29@gated-at.bofh.it>
In reply to#1616417
Since users of CHECK_DATA_CORRUPTION() should be failing safe, the
condition that triggers a WARN() may recur. This would mean a logging
DoS of the system, so switch to WARN_ONCE() instead. (Those wanting
per-instance notifications should already be building with
CONFIG_BUG_ON_DATA_CORRUPTION so there is no change in that case.)

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index b6cfcb7f778f..c011438a7c6c 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -136,7 +136,7 @@ static inline __must_check bool check_data_corruption(bool v) { return v; }
 				pr_err(fmt, ##__VA_ARGS__);		 \
 				BUG();					 \
 			} else						 \
-				WARN(1, fmt, ##__VA_ARGS__);		 \
+				WARN_ONCE(1, fmt, ##__VA_ARGS__);	 \
 		}							 \
 		unlikely(corruption);					 \
 	}))
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1616424 — [PATCH v2 2/7] bug: Improve unlikely() in data corruption check

FromKees Cook <keescook@chromium.org>
Date2017-04-05 00:20 +0200
Subject[PATCH v2 2/7] bug: Improve unlikely() in data corruption check
Message-ID<tsEXU-2s7-33@gated-at.bofh.it>
In reply to#1616417
This improves the compiler branch-hinting used in CHECK_DATA_CORRUPTION(),
similar to how it is done in WARN_ON() and friends.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/bug.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index db1e41c69bac..b6cfcb7f778f 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -130,15 +130,15 @@ static inline enum bug_trap_type report_bug(unsigned long bug_addr,
 static inline __must_check bool check_data_corruption(bool v) { return v; }
 #define CHECK_DATA_CORRUPTION(condition, fmt, ...)			 \
 	check_data_corruption(({					 \
-		bool corruption = unlikely(condition);			 \
-		if (corruption) {					 \
+		bool corruption = !!(condition);			 \
+		if (unlikely(corruption)) {				 \
 			if (IS_ENABLED(CONFIG_BUG_ON_DATA_CORRUPTION)) { \
 				pr_err(fmt, ##__VA_ARGS__);		 \
 				BUG();					 \
 			} else						 \
 				WARN(1, fmt, ##__VA_ARGS__);		 \
 		}							 \
-		corruption;						 \
+		unlikely(corruption);					 \
 	}))
 
 #endif	/* _LINUX_BUG_H */
-- 
2.7.4

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web