Date: Sun, 10 Jul 2016 21:29:08 +0200 From: Stephan Mueller <smueller@...onox.de> To: Shubham Bansal <illusionist.neo@...il.com> Cc: kernel-hardening@...ts.openwall.com, sandyinchina@...il.com, tytso@....edu, keescook@...omium.org, jsd@...n.com Subject: Re: Looking for something to WORK ON Am Sonntag, 10. Juli 2016, 22:12:53 CEST schrieb Shubham Bansal: Hi Shubham, > Hi Sandy, > > On Wed, Jul 6, 2016 at 8:44 PM, Sandy Harris <sandyinchina@...il.com> wrote: > > Shubham Bansal <illusionist.neo@...il.com> wrote: > > > I want to start with linux kernel development and looking for some > > > > project > > > > > where I can contribute. > > > > Nearly all crypto and the address randomisation that is part of kernel > > hardening depend on good random numbers, for Linux on the random(4) > > driver. Getting it initialised early enough & well enough is an > > extremely tricky problem. Several people have proposed solutions but > > AFAIK none are complete and it might benefit from having fresh eyes > > take a look, especially if you have a good background in crypto or > > math. > > I have a basic understanding of crypto as I just graduated. But it sound > really interesting to work on. I am happy to work on it if you think it > would be good, But I must tell you that I have to read a lot for this. > > > Not all discussion is here; other relevant lists include > > linux-crypto@...r.kernel.org and cryptography@...zdowd.com. > > Subscribed. > > > People to > > look for include the maintainer, tytso@....edu, the main person > > working on the problem here, keescook@...omium.org, > > Should I mail them to get the update and how can I start contributing ? > > > two guys who have > > proposed drive rewrites that partly solve the problem, me and > > smueller@...onox.de, and one with a lot of excellent comments, > > jsd@...n.com. > > Would it be possible to work with you on this ? I would try my best. I > would need some help from your side though. > > Looking forward to hearing back from you. I would like to get started with > it soon. My code is in the kernel at crypto/jitterentropy.c. It is completely standalone and does not require anything, provided the intended architecture has either random_get_entropy() or get_cycles implemented. I have tested it on bare metal without a kernel. Thus, it can be operational as early as you need it. To make it fully standalone, you have to: - compile jitterentropy.c and the helper functions listed at the top in jitterentropy.c and implemented in jitterentropy_kcapi.c (note, jent_fips_enabled is not needed for your purpose) - statically allocate the memory obtained in jent_entropy_collector_alloc - ensure serialization as necessary I strongly suggest that you call jent_entropy_init to ensure that the timer has a sufficient high resolution before you collect entropy with jent_read_entropy. Note, I am currently getting help from a big chip vendor tracking down the root cause that beyond the analysis of chapter 6.1 in my report. Ciao Stephan
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.