linux-kernel - Re: [RFC] Documentation about unaligned memory access

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: <200711250027.25221.vda.linux@googlemail.com>
Date:	Sun, 25 Nov 2007 00:27:25 -0800
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Daniel Drake <dsd@...too.org>
Cc:	linux-kernel@...r.kernel.org, davem@...emloft.net,
	kune@...ne-taler.de, johannes@...solutions.net
Subject: Re: [RFC] Documentation about unaligned memory access

On Thursday 22 November 2007 16:15, Daniel Drake wrote:
> In summary: if your code causes unaligned memory accesses to happen, your
> code will not work on some platforms, and will perform *very* badly on
> others.

Although understanding alignment is important, there is another
extreme - what I call "sadistic alignment". It's when data is being
aligned even if it will definitely run on an arch which doesn't require
this (arch/x86/*), or data being aligned to ridiculously large boundary.

Like gcc aligning any char array bigger that 31 byte to 32 bytes.
Bytes, not bits. Try to compile this with -O2:

static char s1[] = "12345678901234567890123456789012";
static char s2[] = "12345678901234567890123456789012";
void f(char*);
void g() {
    f(s1);
    f(s2);
}

$ hexdump -Cv t.o
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  01 00 03 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  38 01 00 00 00 00 00 00  34 00 00 00 00 00 28 00  |8.......4.....(.|
00000030  0a 00 07 00 55 89 e5 83  ec 08 c7 04 24 40 00 00  |....U.......$@..|
00000040  00 e8 fc ff ff ff c7 04  24 00 00 00 00 e8 fc ff  |........$.......|
00000050  ff ff c9 c3 00 00 00 00  00 00 00 00 00 00 00 00  |................|  <=== HERE
00000060  31 32 33 34 35 36 37 38  39 30 31 32 33 34 35 36  |1234567890123456|
00000070  37 38 39 30 31 32 33 34  35 36 37 38 39 30 31 32  |7890123456789012|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  <=== HERE
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|  <=== HERE
000000a0  31 32 33 34 35 36 37 38  39 30 31 32 33 34 35 36  |1234567890123456|
000000b0  37 38 39 30 31 32 33 34  35 36 37 38 39 30 31 32  |7890123456789012|
000000c0  00 00 00 00 00 47 43 43  3a 20 28 47 4e 55 29 20  |.....GCC: (GNU) |
000000d0  34 2e 30 2e 33 20 28 55  62 75 6e 74 75 20 34 2e  |4.0.3 (Ubuntu 4.|
000000e0  30 2e 33 2d 31 75 62 75  6e 74 75 35 29 00 00 2e  |0.3-1ubuntu5)...|
000000f0  73 79 6d 74 61 62 00 2e  73 74 72 74 61 62 00 2e  |symtab..strtab..|

43 bytes wasted!

Thankfully, it is fixed in later gcc versions.

Please do not succumb to "alignment scare" in your doc.
--
vda
-
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/