linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0610161847210.3962@g5.osdl.org>
Date:	Mon, 16 Oct 2006 18:50:54 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Al Viro <viro@....linux.org.uk>
cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [RFC] typechecking for get_unaligned/put_unaligned

On Tue, 17 Oct 2006, Al Viro wrote:
>
> 	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.

Have we ever really had any problems with this?

I think that as far as typing, we should just make sure that 
[get|put]_unaligned() has the same behaviour as a dereference. Sure, 
checking the size might be worth it, but it doesn't sound like we'd 
actually find any real bugs (ie wrong sizes should just result in compile 
or link errors on architectures where you need special code for it).

> 	c) how about gradually switching to linux/unaligned.h?

I'd prefer not to, if only because it's an unnecessary compile-time 
overhead for nice sane architectures like x86, which don't need any of the 
unaligned crap.

Since x86[-64] is clearly the main architecture, dis-optimizing for that 
one sounds like a bad idea.

		Linus
-
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/