|
Message-ID: <57AC9C43.5080106@intel.com> Date: Thu, 11 Aug 2016 08:39:47 -0700 From: Dave Hansen <dave.hansen@...el.com> To: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Emese Revfy <re.emese@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Jonathan Corbet <corbet@....net>, Vlastimil Babka <vbabka@...e.cz>, Mel Gorman <mgorman@...hsingularity.net>, Michal Hocko <mhocko@...e.com>, Johannes Weiner <hannes@...xchg.org>, Joonsoo Kim <iamjoonsoo.kim@....com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Taku Izumi <izumi.taku@...fujitsu.com>, linux-doc@...r.kernel.org, linux-mm@...ck.org, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH] mm: Add the ram_latent_entropy kernel parameter On 08/10/2016 03:28 PM, Kees Cook wrote: > + if (ram_latent_entropy && !PageHighMem(page) && > + page_to_pfn(page) < 0x100000) { > + u64 hash = 0; > + size_t index, end = PAGE_SIZE * nr_pages / sizeof(hash); > + const u64 *data = lowmem_page_address(page); > + > + for (index = 0; index < end; index++) > + hash ^= hash + data[index]; > + add_device_randomness((const void *)&hash, sizeof(hash)); > + } When I was first reading this, I thought it was using the _addresses_ of the freed memory for entropy. But it's actually using the _contents_. The description could probably use a wee bit of sprucing up. It might also be nice to say in the patch description (and the Documentation/) what you expect to be in this memory. It will obviously be zeros for the vast majority of the space, but I do wonder what else ends up in there in practice. Why is it limited to 4GB? Just so it doesn't go and try to XOR the contents of a multi-TB system if it got turned on there? :)
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.