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: <f41cd250b90d4eb883ea5ff245718200@AcuMS.aculab.com>
Date: Thu, 9 May 2024 21:23:29 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...ux-foundation.org>, Kees Cook
	<keescook@...omium.org>
CC: Justin Stitt <justinstitt@...gle.com>, Peter Zijlstra
	<peterz@...radead.org>, Mark Rutland <mark.rutland@....com>,
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"llvm@...ts.linux.dev" <llvm@...ts.linux.dev>
Subject: RE: [RFC] Mitigating unexpected arithmetic overflow

...
> I think that would be a completely different area that might be worth
> looking at: instrumenting implicit casts for "drops bits". I'm afraid
> that it's just *so* common than we might not be able to do that
> sanely.

Things like:
	buf[0] = val;
	buf[1] = val >>= 8;
	buf[2] = val >>= 8;
	buf[3] = val >>= 8;
for writing a value little-endian and potentially misaligned.
Really doesn't want any annotation.

I've also seen code like:
	buf[0] = (unsigned char)(val & 0xff);
not only ugly by it got compiled to:
	val &= 0xff // for the &
	val &= 0xff // for the cast
	byte write to memory.
Modern gcc doesn't do that, but...

There are some spurious casts that drop bits.
I found plenty of dubious min_t(u8/u16,...) examples.
(Well they are dubious, some are just a lot more dubious than others.)
The problem is that every one needs careful inspection just in case
the strange behaviour is required like min_t(u8, val - 1, lo_lim - 1)
which treats lo_lim of zero as 'not a limit' and I think was ok.

A slow, concerted effort to remove min_t() calls wouldn't be a bad thing.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ