Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Valentin QUEQUET <v.quequet-techniques@orange.fr>
Cc: linux-crypto@vger.kernel.org, bugme-daemon@bugzilla.kernel.org,
	dm-devel@redhat.com
Subject: Re: [Bugme-new] [Bug 12680] New: Not having a VIA PadLock hardware incurs a long delay in probing on modules insertion attempt.
Date: Wed, 11 Feb 2009 09:16:47 -0800	[thread overview]
Message-ID: <20090211091647.6607aea4.akpm@linux-foundation.org> (raw)
In-Reply-To: <4992FC7E.3010207@orange.fr>


(cc dm-devel)

On Wed, 11 Feb 2009 17:27:42 +0100 Valentin QUEQUET <v.quequet-techniques@orange.fr> wrote:

> 
> I've finally found why my computer seems to hang (pause) quite lengthy 
> when I boot Pristine Linux 2.6.29-rcX... instead of Pristine Linux 
> 2.6.28.4 (for example).
> 
> The reason is that the cryptographic keys generation for the Device 
> Mapper takes longer with 2.6.29 than with 2.6.28 under certain 
> circumstances.

So it's device-mapper userspace?

Is this new behaviour in recent kernel versions?  Some kernel change
caused /dev/random accesses to wait for longer before sufficient
entropy has been gathered?


> To notice a non-negligible delay in the key generation phase, the system 
> must fit the following both 2 conditions:
> 
>    1) The system PRNG entropy pool must lack of entropy normally brought 
> in the form of environmental noise.
> 
>    2) The system must initiate its Device-Mapper-Encrypted (dm-crypt) 
> partitions with boot-time dynamically generated
>         cryptographic keys using "/dev/random" as key file. (the 3rd 
> field of "/etc/crypttab" ; see "man crypttab")
> 
> 
> Such a long delay in the key generation phase can be avoided if the 
> system fits either of the following 2 conditions:
> 
>    1) The excitated user stresses its keyboard and mouse (generates much 
> environmental noise) to provide the PRNG entropy pool with much entropy. 
> (Or some other peripheral generates noise : network interface, ...)
> 
>    2) The system initiates dm-crypt partitions using "/dev/urandom" as 
> key file.
> 
> 
> But in the scenario where both
>    1) environmental noise is reduced to the minimum (no user 
> 'excitation' and mouse and NIC unplugged)
> and
>    2) where dm-crypt partitions are initialized with "/dev/random" as 
> key file,
> there is a huge difference whether I boot Linux 2.6.28.y or Linux 
> 2.6.29-rcX... .
> 
> 
> In order to provide you with meaningful information but not too much, I 
> join a few "bootchart"-generated logs (bootchart*.tgz) plus their 
> ".svgz" corresponding diagrams (Pruned and Not-Pruned) for the following 
> test cases:
> 
> Having always environmental noise reduced at its minimum possible level.
> Using alternately 2.6.28 and 2.6.29 Linux versions.
> Using alternately "/dev/random" and "/dev/urandom" as dm-crypt key file.
> 
> There are then 4 test cases for which I join files, and for each test 
> case, I provide:
>    - The "bootchart*.tgz" bootchart report.
>    - The Not-Pruned ".svgz" corresponding SVG diagram.
>    - The Pruned ".svgz" corresponding SVG diagram.
> 
> Thus leading to the following 12 files:
> 
> -r--r--r-- 1 testr testr 174682 Feb 11 17:10 
> DevRandom_bootchart-2.6.28.4.BootChart_Report.tgz
> -r--r--r-- 1 testr testr 102648 Feb 11 17:10 
> DevRandom_bootchart-2.6.28.4.Not-Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr  26010 Feb 11 17:10 
> DevRandom_bootchart-2.6.28.4.Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr 327701 Feb 11 17:10 
> DevRandom_bootchart-2.6.29-rc4-git1.BootChart_Report.tgz
> -r--r--r-- 1 testr testr 175522 Feb 11 17:10 
> DevRandom_bootchart-2.6.29-rc4-git1.Not-Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr  39844 Feb 11 17:10 
> DevRandom_bootchart-2.6.29-rc4-git1.Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr 138401 Feb 11 17:10 
> DevUrandom_bootchart-2.6.28.4.BootChart_Report.tgz
> -r--r--r-- 1 testr testr  80691 Feb 11 17:10 
> DevUrandom_bootchart-2.6.28.4.Not-Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr  21136 Feb 11 17:10 
> DevUrandom_bootchart-2.6.28.4.Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr 152979 Feb 11 17:10 
> DevUrandom_bootchart-2.6.29-rc4-git1.BootChart_Report.tgz
> -r--r--r-- 1 testr testr  78323 Feb 11 17:10 
> DevUrandom_bootchart-2.6.29-rc4-git1.Not-Pruned_SVG_Diagram.svgz
> -r--r--r-- 1 testr testr  20745 Feb 11 17:10 
> DevUrandom_bootchart-2.6.29-rc4-git1.Pruned_SVG_Diagram.svgz
> 
> But for the sake of convenience, I tar them all as 
> "Dev-Random_regression_on_post-2.6.28_kernels.tar"
> 
> In hope my report will prove useful.
> 
> Sincerely,
> Valentin QUEQUET
> 
> n.b. : Don't hesitate to ask me for more files or explanations.
> 

  parent reply	other threads:[~2009-02-11 17:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-12680-10286@http.bugzilla.kernel.org/>
2009-02-09 21:05 ` [Bugme-new] [Bug 12680] New: Not having a VIA PadLock hardware incurs a long delay in probing on modules insertion attempt Andrew Morton
2009-02-09 21:59   ` Valentin QUEQUET
     [not found]   ` <4992FC7E.3010207@orange.fr>
2009-02-11 17:16     ` Andrew Morton [this message]
2009-02-11 19:28       ` Milan Broz
2009-02-11 20:55         ` [dm-devel] " Valentin QUEQUET

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090211091647.6607aea4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=v.quequet-techniques@orange.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox