linux-kernel - Re: [PATCH 1/2] vmlinux.lds.h: allow people to set a smaller rootfs alignment

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:	Wed, 9 Jun 2010 03:42:55 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Milton Miller <miltonm@....com>
Cc:	linux-kernel@...r.kernel.org, Tim Abbott <tabbott@...lice.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/2] vmlinux.lds.h: allow people to set a smaller rootfs 
	alignment

On Wed, Jun 9, 2010 at 03:20, Milton Miller wrote:
> On Sat,  5 Jun 2010 at around 14:14:45 -0400, Mike Frysinger wrote:
>> Add a new INIT_RAMFS() define to compliment the existing INIT_RAM_FS, but
>> this one lets people control the alignment.
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 48c5299..9ca268f 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -619,14 +619,15 @@
>>               VMLINUX_SYMBOL(__security_initcall_end) = .;
>>
>>  #ifdef CONFIG_BLK_DEV_INITRD
>> -#define INIT_RAM_FS                                                  \
>> -     . = ALIGN(PAGE_SIZE);                                           \
>> +#define INIT_RAMFS(align)                                            \
>> +     . = ALIGN(align);                                               \
>>       VMLINUX_SYMBOL(__initramfs_start) = .;                          \
>>       *(.init.ramfs)                                                  \
>>       VMLINUX_SYMBOL(__initramfs_end) = .;
>>  #else
>> -#define INIT_RAM_FS
>> +#define INIT_RAMFS(align)
>>  #endif
>> +#define INIT_RAM_FS INIT_RAMFS(PAGE_SIZE)
>
> [ and patch 2/2 calls the new macro with align 4, for only blackfin ].
>
> Mike,
> As you identified, the alignment for the __initramfs is too large.
>
> As can be seen by the grammer of the INIT_RAM_FS in [1], the section
> itself always requires alignment of exactly 4 [2].
>
> I realize it requires a bit more auditing and cordination, but we
> should really just change the macro to align to 4.
>
> [1] Documentation/early-userspace/buffer-format.txt,
> [2] for the general case; as compressed fragments are aligin(1)

the back story is to bring the alignment back to the way it was before
for Blackfin systems, not to drop it down to some min value.  so dont
credit me with too much here ;).

if we look at the alignments before the unification, we can easily see
why Tim was a bit cautious and started the common value at PAGE_SIZE:
alpha: PAGE_SIZE
arm: 32
avr32: 32
blackfin: 4
cris: none (so default from the input sections == 4?)
frv: 4096 (== PAGE_SIZE?)
h8300: 4
ia64: none (so default from the input sections == 4?)
m32r: 4096 (== PAGE_SIZE?)
m68k: 8192 (== 2x PAGE_SIZE?)
microblaze: 4096 (== PAGE_SIZE?)
mips: PAGE_SIZE
mn10300: PAGE_SIZE
parisc: PAGE_SIZE
powerpc: PAGE_SIZE
s390: 0x100
score: PAGE_SIZE
sh: PAGE_SIZE
sparc: PAGE_SIZE
x86: PAGE_SIZE
xtensa: 4096 (== PAGE_SIZE?)

i have no problem changing the default to 4 since it works fine on
Blackfin systems.  your analysis of the source alignment also seems
reasonable ... i assume that the 8 byte fields in the source cpio
arent referenced directly, otherwise it'd cause problems on 64bit
systems that require 64bit values to be naturally aligned.

beyond that, i dont see why any larger alignment values would be
required since this source archive isnt executed directly.  it gets
expanded into a ramfs and then freed with the rest of the init stuff.
-mike
--
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/