linux-kernel - [RFC] typechecking for get_unaligned/put

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]

Message-ID: <20061017005025.GF29920@ftp.linux.org.uk>
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/