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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d1136c07-191e-443f-b462-c18ee2c217e3@roeck-us.net>
Date: Sun, 11 Feb 2024 10:54:25 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] regmap: kunit: Ensure that changed bytes are actually
 different

On Sun, Feb 11, 2024 at 04:58:17PM +0000, Mark Brown wrote:
> During the cache sync test we verify that values we expect to have been
> written only to the cache do not appear in the hardware. This works most
> of the time but since we randomly generate both the original and new values
> there is a low probability that these values may actually be the same.
> Wrap get_random_bytes() to ensure that the values are different, there
> are other tests which should have similar verification that we actually
> changed something.
> 
> While we're at it refactor the test to use three changed values rather
> than attempting to use one of them twice, that just complicates checking
> that our new values are actually new.
> 
> We use random generation to try to avoid data dependencies in the tests.
> 
> Reported-by: Guenter Roeck <linux@...ck-us.net>
> Signed-off-by: Mark Brown <broonie@...nel.org>

Reviewed-by: Guenter Roeck <linux@...ck-us.net>
Tested-by: Guenter Roeck <linux@...ck-us.net>

Minor comment below.

> +
> +	/*
> +	 * The value written via _write() was translated by the core,
> +	 * translate the original copy for comparison purposes.
> +	 */
> +	if (config.val_format_endian == REGMAP_ENDIAN_BIG)
> +		val[2] = cpu_to_be16(val[2]);
> +	else
> +		val[2] = cpu_to_le16(val[2]);
>  	
>  	/* The values should not appear in the "hardware" */
> -	KUNIT_EXPECT_MEMNEQ(test, &hw_buf[2], val, sizeof(val));
> -	KUNIT_EXPECT_MEMNEQ(test, &hw_buf[6], val, sizeof(u16));
> +	KUNIT_EXPECT_MEMNEQ(test, &hw_buf[2], &val[0], sizeof(val));

I kept those two checks separate on purpose because a non-equal check
will "succeed" if a single byte is different. That means the above check
will "pass" if one of regmap_raw_write() or regmap_write() works but
the other is broken.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ