linux-kernel - Re: Issues with capability bits and meta-data in kdbus

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]

Date:	Fri, 24 Apr 2015 10:52:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Olaf Hering <olaf@...fle.de>
Cc:	Havoc Pennington <hp@...ox.com>,
	Michele Curti <michele.curti@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Andy Lutomirski <luto@...capital.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: Issues with capability bits and meta-data in kdbus

On Fri, Apr 24, 2015 at 7:32 AM, Olaf Hering <olaf@...fle.de> wrote:
> On Wed, Apr 22, Linus Torvalds wrote:
>
>> Conditional byte order is worse than silly - it's terminally stupid.
>
>> In other words, think networking, which statically just decided to use
>> big-endian. Sure, that was the wrong choice in the end, but even
>
> Why was that wrong? Any pointers to further details?

Just because BE is effectively dead these days.  Every BE architecture
is either gone, or is slowly (or not so slowly) converting to LE.

But more importantly, even when you pick the byte order that history
then relegates to the the losing position, and you end up doing byte
swappign on most machines, that is *still* better than conditionally
*not* doing byte swapping.

So even today, by all means make your protocols or disk images use
big-endian byte formats. But do it unconditionally. Don't make the
mistake of encoding the byte order as part of the data, and then
dynamically switching things (or not) around.

In fact, even today a BE byte order can make sense, if only exactly
because of network byte order - thanks to network byte order, there
are all those nice mostly-portable and often well-optimized "ntohl()"
functions available to you. So rather than introduce your own helper
functions for LE byte order access, you may be better off just using
BE because of existing network infrastructure.

                        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/