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]

Date:	Tue, 18 May 2010 14:20:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	penberg@...helsinki.fi
Cc:	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: Pekka Enberg <penberg@...helsinki.fi>
Date: Wed, 19 May 2010 00:15:46 +0300

> On Tue, May 18, 2010 at 11:59 PM, David Miller <davem@...emloft.net> wrote:
>> From: Matt Mackall <mpm@...enic.com>
>> Date: Tue, 18 May 2010 14:33:55 -0500
>>
>>> SLOB honors ARCH_KMALLOC_MINALIGN. If your arch has alignment
>>> requirements, I recommend you set it.
>>
>> I recommend that the alignment provided by the allocator is not
>> determined by which allocator I happen to have enabled.
>>
>> The values and ifdef'ery should be identical in all of our
>> allocators.
> 
> Why? It doesn't make much sense for SLOB, which tries to be as space
> efficient as possible, as a default. If things break on sparc, it
> really needs to set ARCH_KMALLOC_MINALIGN as slab default alignment is
> not something you really want to depend on.

I think it does make sense to expect that, whatever my architecture
defines or does not define, I can expect the allocators to provide the
same minimum alignment guarentee.  Otherwise it is no guarantee at all.

It's already obvious from these reports that such dependencies do
exist.

I'll add the define for sparc, but saying "sparc's fault" is bogus
because I defined what was necessary to get SLAB/SLUB to provide the
necessary alignment.  SLOB pays for choosing not to use the same
calculations for minimum alignment as the other allocators, and
therefore pays for being different in this regard.

And in fact I do know that the ifdef'ery in SLAB/SLUB is derived from
a change long ago that was specifically added to handle platforms like
sparc.

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.
--
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/