SSD drives

SSD drives

Oleg Goldshmidt pub at goldshmidt.org
Thu Jan 3 11:57:01 IST 2013


On Thu, Jan 3, 2013 at 10:53 AM, Baruch Siach <baruch at tkos.co.il> wrote:
> Hi Oleg,
>
> On Sun, Dec 30, 2012 at 10:40:31AM +0200, Oleg Goldshmidt wrote:
>> On Sun, Dec 30, 2012 at 8:46 AM, shimi <linux-il at shimi.net> wrote:
>> > I really don't think so. SSDs (IMHO) makes computer much faster due to the
>> > VERY low seek time - the time it takes you to get a block. Compare 10-20ms
>> > with ~0.1ms. A regular hard drive simply wastes a lost of time seeking the
>> > data, instead of... reading it :)
>>
>> Absolutely correct. However, there is a tiny fraction of the seek time
>> that is not always a waste, and I think it is worth mentioning. There
>> is, I believe, a consideration that is usually overlooked when SSDs
>> are considered for server use, including a "desktop" that is used as a
>> server, which is why I am mentioning it here. In a server, magnetic
>> disk rotation - or, rather the air turbulence generated between the
>> rotating disk and its enclosure - is the only source of entropy that
>> makes random numbers random (seek times have a tiny random component
>> due to the turbulence, and it is captured). This does not apply to
>> SSDs, and as a result your security may be compromised (attacks
>> exploiting not very random RNGs are well known).
>
> Recent Intel CPUs introduced the RDRAND instruction that is essentially a
> Random Number Generator. Recent kernels (v3.2 and later) added support for
> this instruction. See http://git.kernel.org/linus/628c6246d4. See also the
> related commit (from v3.6) at http://git.kernel.org/linus/c2557a303 (and note
> the funny commit log).
>
> These patches were backported to all supported stable kernel trees (back to
> v2.6.32).

Note that the commit log (and Ted Ts'o really knows what he is talking
about) makes an important point, and I'll add one of my own.

1) Always use /dev/random even if a HW RNG is available. /dev/random
is where the disk-generated entropy ends up. If /dev/random is not
there you are in trouble.

2) I would not only be worried about an NSA backdoor in Intel CPUs,
but also about the degree of randomness of their generator. If it is
flawed (and it is notoriously difficult to do a really good PRNG - I
assume it is a PRNG, otherwise Ted would not be worried about NSA
backdoor) you will have no fix path. A PRNG needs a truly random seed
at least, which is where /dev/random comes in.

-- 
Oleg Goldshmidt | pub at goldshmidt.org



More information about the Linux-il mailing list