linux-kernel - Re: [BUG] SLOB breaks Crypto

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: <20100518.154059.139137292.davem@davemloft.net>
Date:	Tue, 18 May 2010 15:40:59 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	lethal@...ux-sh.org
Cc:	penberg@...helsinki.fi, mpm@...enic.com,
	herbert@...dor.apana.org.au, ken@...elabs.ch, geert@...ux-m68k.org,
	michael-dev@...i-braun.de, linux-kernel@...r.kernel.org,
	linux-crypto@...r.kernel.org, anemo@....ocn.ne.jp
Subject: Re: [BUG] SLOB breaks Crypto

From: Paul Mundt <lethal@...ux-sh.org>
Date: Wed, 19 May 2010 07:35:10 +0900

> On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote:
>> So one of two things should happen:
>> 
>> 1) SLOB conforms to SLAB/SLUB in it's test
>> 
>> 2) SLAB/SLUB conforms to SLOB in it's test
>> 
>> And yes this is an either-or, you can't say they are both valid.
> 
> I don't see any reason to punish SLOB for the assumptions that SLAB/SLUB
> arbitrarily took up, presumably on an architecture that should have
> specified its own alignment requirements and simply couldn't be bothered.
> Making SLAB redzoning work with arbitrary alignment is another matter
> entirely, and something that should probably be revisited.
> 
> Anything that assumes more than BYTES_PER_WORD is simply broken and
> should be reverted.

You can't make the default different in each allocator, PERIOD.

If you can't know what the default is, how in the world can you know
if you need to override it?  You can't.  It's a guess, and you can't
say otherwise.

All of the CPP tests like the one used by linux/crypto.h are
ludicrious.  It should absolutely be not necessary for any code to
duplicate this kind of calculation.

Instead, this sequence should be in linux/slab.h, and be used
universally by slab, slub, slob and anything that wants to know the
allocators alignment guarentees.

I don't even know of a 32-bit chip outside of x86 that doesn't
potentially emit alignment requiring 64-bit memory operations for
64-bit objects.  So what SLOB is doing with a different default is
even more strange.  And I bet you that even without the requirement,
x86 runs faster with 64-bit alignment of 64-bit objects.
--
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/