lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 13 Apr 2021 10:14:29 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will@...nel.org>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>
Subject: Re: linux-next: manual merge of the akpm-current tree with the arm64
 tree

On Tue, Apr 13, 2021 at 06:59:36PM +1000, Stephen Rothwell wrote:
> diff --cc lib/test_kasan.c
> index 785e724ce0d8,bf9225002a7e..000000000000
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@@ -78,33 -83,30 +83,35 @@@ static void kasan_test_exit(struct kuni
>    * fields, it can reorder or optimize away the accesses to those fields.
>    * Use READ/WRITE_ONCE() for the accesses and compiler barriers around the
>    * expression to prevent that.
> +  *
> +  * In between KUNIT_EXPECT_KASAN_FAIL checks, fail_data.report_found is kept as
> +  * false. This allows detecting KASAN reports that happen outside of the checks
> +  * by asserting !fail_data.report_found at the start of KUNIT_EXPECT_KASAN_FAIL
> +  * and in kasan_test_exit.
>    */
> - #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do {		\
> - 	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&			\
> - 	    !kasan_async_mode_enabled())			\
> - 		migrate_disable();				\
> - 	WRITE_ONCE(fail_data.report_expected, true);		\
> - 	WRITE_ONCE(fail_data.report_found, false);		\
> - 	kunit_add_named_resource(test,				\
> - 				NULL,				\
> - 				NULL,				\
> - 				&resource,			\
> - 				"kasan_data", &fail_data);	\
> - 	barrier();						\
> - 	expression;						\
> - 	barrier();						\
> - 	if (kasan_async_mode_enabled())				\
> - 		kasan_force_async_fault();			\
> - 	barrier();						\
> - 	KUNIT_EXPECT_EQ(test,					\
> - 			READ_ONCE(fail_data.report_expected),	\
> - 			READ_ONCE(fail_data.report_found));	\
> - 	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&			\
> - 	    !kasan_async_mode_enabled()) {			\
> - 		if (READ_ONCE(fail_data.report_found))		\
> - 			kasan_enable_tagging_sync();		\
> - 		migrate_enable();				\
> - 	}							\
> + #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do {			\
>  -	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS))				\
> ++	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&				\
> ++	    !kasan_async_mode_enabled())				\
> + 		migrate_disable();					\
> + 	KUNIT_EXPECT_FALSE(test, READ_ONCE(fail_data.report_found));	\
> + 	WRITE_ONCE(fail_data.report_expected, true);			\
> + 	barrier();							\
> + 	expression;							\
> + 	barrier();							\
> ++	if (kasan_async_mode_enabled())					\
> ++		kasan_force_async_fault();				\
> ++	barrier();							\
> + 	KUNIT_EXPECT_EQ(test,						\
> + 			READ_ONCE(fail_data.report_expected),		\
> + 			READ_ONCE(fail_data.report_found));		\
>  -	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS)) {				\
> ++	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&				\
> ++	    !kasan_async_mode_enabled()) {				\
> + 		if (READ_ONCE(fail_data.report_found))			\
>  -			kasan_enable_tagging();				\
> ++			kasan_enable_tagging_sync();			\
> + 		migrate_enable();					\
> + 	}								\
> + 	WRITE_ONCE(fail_data.report_found, false);			\
> + 	WRITE_ONCE(fail_data.report_expected, false);			\
>   } while (0)
>   
>   #define KASAN_TEST_NEEDS_CONFIG_ON(test, config) do {			\

Thanks Stephen. The resolution looks correct.

Andrew, if you'd rather I dropped the MTE async mode support from the
arm64 tree please let me know. Thanks.

https://lore.kernel.org/r/20210315132019.33202-1-vincenzo.frascino@arm.com/

-- 
Catalin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ