linux-kernel - Re: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE

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: <ZXyGbhJqzNxbd3ay@yury-ThinkPad>
Date: Fri, 15 Dec 2023 09:01:34 -0800
From: Yury Norov <yury.norov@...il.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: catalin.marinas@....com, will@...nel.org, pcc@...gle.com,
	andreyknvl@...il.com, andriy.shevchenko@...ux.intel.com,
	aleksander.lobakin@...el.com, linux@...musvillemoes.dk,
	alexandru.elisei@....com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, eugenis@...gle.com,
	syednwaris@...il.com, william.gray@...aro.org
Subject: Re: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP

On Fri, Dec 15, 2023 at 08:35:43AM -0800, Yury Norov wrote:
> On Fri, Dec 15, 2023 at 04:19:27PM +0100, Alexander Potapenko wrote:
> > >
> > > That looks weird... You're casting address of a 'data' to a bitmap
> > > instead of 'data'. At the 1st glance it makes little sense because
> > > 'data' is passed as parameter. Moreover, in mte_is_compressed()
> > > you pass 'data', not '&data'. Can you please comment on your
> > > intention?
> > 
> > Although `data` is a void*, it actually contains 64 bits of compressed
> > data, so we pass &data to mte_bitmap_read() to read its contents.
> > Perhaps I'd better make `data` an unsigned long to avoid confusion.
>  
> Still don't understand. Let's consider this example:
> 
> yury:linux$ cat tst.c
> #include <stdio.h>
> 
> unsigned long data[1] = {0xabc};
> 
> void foo(unsigned long *data)
> {
> 	printf("foo:  *data\t%lx\n", (unsigned long)*data);
> 	printf("foo:   data\t%lx\n",  (unsigned long)data);
> 	printf("foo:  &data\t%lx\n", (unsigned long)&data);
> }
> 
> void bar(unsigned long *data)
> {
> 	volatile unsigned long x[100];
> 
> 	printf("bar:  *data\t%lx\n", (unsigned long)*data);
> 	printf("bar:   data\t%lx\n",  (unsigned long)data);
> 	printf("bar:  &data\t%lx\n", (unsigned long)&data);
> }
> 
> int main(int argc, char *argv[])
> {
> 
> 	foo(data);
> 	bar(data);
> 
> 	printf("main: *data\t%lx\n", (unsigned long)*data);
> 	printf("main:  data\t%lx\n",  (unsigned long)data);
> 	printf("main: &data\t%lx\n", (unsigned long)&data);
> 
> 	return 0;
> }
> yury:linux$ gcc tst.c -O0
> yury:linux$ ./a.out
> foo:  *data	abc
> foo:   data	555b2cef9010
> foo:  &data	7fff39d6e5f8
> bar:  *data	abc
> bar:   data	555b2cef9010
> bar:  &data	7fff39d6e2c8
> main: *data	abc
> main:  data	555b2cef9010
> main: &data	555b2cef9010
> 
> Data and *data have their meaning across scope boundary: a pointer and
> a content. The &data is pretty much a random number - a pointer to
> somewhere on a function's stack. Isn't?

OK, I read now. Your 'void *data' is not a pointer, but an actual data.
Very confusing indeed... Maybe add a comment for that cast?