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-next>] [day] [month] [year] [list]
Date:	Tue, 17 Oct 2006 01:50:25 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: [RFC] typechecking for get_unaligned/put_unaligned

	What kind of typechecking do we want for those?

AFAICS, current constraints are
	* {put,get}_unaligned() should be passed a pointer to object; void *
is not acceptable
	* sizeof(*ptr) should be one of 1, 2, 4, 8
	* assignment of val to *ptr should be valid C.

Questions:
	a) do we want all of the above to be enforced on all targets?
	b) do we really want to allow use of that when sizeof(*ptr) is 1?
It's almost certainly a sloppy code (and I don't see any instances in
the tree), but I might be missing some potentially valid use in macros.
	c) how about gradually switching to linux/unaligned.h?  In this
case we can do it nicely; start with mutual #include in asm/unaligned.h
and linux/unaligned.h (in the beginning of each), then switch users
and once they'd been all gone for a while, have asm/unaligned.h contain
#ifndef __LINUX_UNALGINED_H__
#error include linux/unaligned.h instead
#endif
instead of
#include <linux/unaligned.h>
	d) any objections to having asm/unaligned.h defining
__{get,put}_unaligned{2,4,8} and linux/unaligned.h doing __builtin_choose_expr()
to pick the right one?  AFAICS, that should not have any bad effects on the
generated code and it would allow to put all typechecking in one place.
Helpers in question would take pointers to u{16,32,64} and value of the
same type.  Even the targets doing a simple assignment in all cases would
get the same code generated, AFAICS...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists