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]

Message-ID: <CA+55aFwvz7ssxGQNZPrLO2nP60TuaWXu=yx0LzN82cQDCD1+pQ@mail.gmail.com>
Date:	Wed, 22 Apr 2015 14:48:38 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Havoc Pennington <hp@...ox.com>
Cc:	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 Wed, Apr 22, 2015 at 1:02 PM, Havoc Pennington <hp@...ox.com> wrote:
>  * the byte order marker in every message is silly

It's worse than that.

Conditional byte order is worse than silly - it's terminally stupid.

This is not a "per connection" thing or a "every message"; thing. It's
more fundamental than that. Protocols that have dynamic byte orders
are pure and utter crap.

The only sane model is to specify one fixed byte order. Seriously.
It's equally portable, it generates better code - even on
architectures that then have to unconditionally do byte order swapping
- and it's simpler to add static type checks for etc. It's literally
less code and faster to do a "bswap" instruction than to do a
conditional test of some variable (even if you can then avoid the
bswap dynamically),

In other words, think networking, which statically just decided to use
big-endian. Sure, that was the wrong choice in the end, but even
picking the wrong endianness - but picking it statically - is better
than the horrible mistake of thinking that you should have some
variable byte order.

              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/