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 11:00:50 -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 10:52 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

Side note: even if you pick the "wrong" byte order, an unconditional
byte ordering choice can often avoid the bswap, just because many
operations are byte order independent.

For example, you can still test specific bits in bitfields etc. If you
have a constant mask you want to check, instead of converting the
field to the CPU byte order at runtime, convert that constant _mask_
to the data byte order at compile-time, and use it without any dynamic
byte swapping of the data.

And generally, avoid byte swapping until you really need it. Some
people seem to think that if the data is in one particular byte order
on disk, you should byteswap as you read it in, and as you write it
out. No, it's often best to actually keep it in the original format,
and only byte swap when actually using the value. Then you can mmap
files and not generate extra copies, or - as per above - you may be
able to structure your code to never need the byte swap at all.

So this is why (for example) the kernel byte swapping helper functions
do odd things like this:

  #define __swab32(x)                             \
          (__builtin_constant_p((__u32)(x)) ?     \
          ___constant_swab32(x) :                 \
          __fswab32(x))

just because the "___constant_swab32()" is designed to do everything
at compile-time.

                   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/