|
Message-ID: <5642B8E8.684.312DEE18@pageexec.freemail.hu> Date: Wed, 11 Nov 2015 04:41:28 +0100 From: "PaX Team" <pageexec@...email.hu> To: kernel-hardening@...ts.openwall.com, Emese Revfy <re.emese@...il.com>, Kees Cook <keescook@...omium.org>, Laura Abbott <laura@...bott.name> CC: Brad Spengler <spender@...ecurity.net>, Greg KH <gregkh@...uxfoundation.org>, Theodore Tso <tytso@...gle.com>, Josh Triplett <josh@...htriplett.org> Subject: Re: Re: Proposal for kernel self protection features On 9 Nov 2015 at 10:07, Laura Abbott wrote: > I took a look at something closely related sometime ago[1] for > ARM DT based targets. The stack canary was always the same because > it was early enough no entropy was being added and there's no standard > RNG. This series proposed allowing entropy to be read out of the DT. > This still relied on reliable entropy being added to the DT somehow. > Ultimately, I never followed up and this still seems to be an issue. > > The out of tree solution which was never submitted was to make a call > to the hwrng very early to seed the pool. This was very SoC specific > though. At the time I wrote the patches, I didn't look to see what > Pax/GrSec might have had to address the issue. to extract entropy via the plugin by the time start_kernel is called you'd have to use the plugin for code that runs beforehand, i.e., the firmware, boot loader, etc and also find a way to pass this entropy to the kernel somehow. another feature of the plugin is to initialize global variables with compile-time generated random numbers, but if the kernel images are available to an attacker then it's of no use of course. last but not least PaX also feeds hashes of every page into the random pool as it gets taken over by the kernel allocator, this could be run earlier to extract whatever entropy is left in RAM. cheers, PaX Team
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.