linux-kernel - RE: [PATCH V2 4/4] riscv: mm: Optimize TASK

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]

Message-ID: <794c14d6c979495e869d7ba03a935e3b@AcuMS.aculab.com>
Date: Sun, 24 Dec 2023 14:37:54 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Guo Ren' <guoren@...nel.org>
CC: Leonardo Bras <leobras@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "paul.walmsley@...ive.com"
	<paul.walmsley@...ive.com>, "palmer@...belt.com" <palmer@...belt.com>,
	"alexghiti@...osinc.com" <alexghiti@...osinc.com>, "charlie@...osinc.com"
	<charlie@...osinc.com>, "xiao.w.wang@...el.com" <xiao.w.wang@...el.com>,
	"david@...hat.com" <david@...hat.com>, "panqinglin2020@...as.ac.cn"
	<panqinglin2020@...as.ac.cn>, "rick.p.edgecombe@...el.com"
	<rick.p.edgecombe@...el.com>, "willy@...radead.org" <willy@...radead.org>,
	"bjorn@...osinc.com" <bjorn@...osinc.com>, "conor.dooley@...rochip.com"
	<conor.dooley@...rochip.com>, "cleger@...osinc.com" <cleger@...osinc.com>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>, Guo Ren
	<guoren@...ux.alibaba.com>
Subject: RE: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition

From: Guo Ren
> Sent: 24 December 2023 01:24
...
> > One possibility would be to save the task's max user address
> > in the task structure itself - that would save all the conditionals
> > at a cost of an extra value in the task structure.

> It would still cause memory load operation, although it is $tp->xxx.

All the (mispredicted) branches are likely to cause more of a
problem than a load from the current task structure.

> If we want to gain observability benefits, "just check (ptr | (ptr +
> len)) < 0)" is better.

If you can guarantee a faulting page between user and kernel addresses
and assume (check) that the accesses are 'reasonably sequential'
then you only need to check the base address.
That is likely hard for 32bit but easier for 64bit (except arm64)
because A63 and A62 have to match.
Unless you have some hardware address masking which makes it much
more likely that 'random values' will be valid addresses.
(Someone remind me why that is a good idea unless the high bits
are validated by the hardware.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)