Re: [PATCH] avoid entropy starvation due to stack protection

[Stephan Mueller]

On 13.12.2012 08:44:36, +0100, Stephan Mueller <smueller@xxxxxxxxxx> wrote:

Hi Andrew,
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Andrew,
>> On Tue, 11 Dec 2012 13:33:04 +0100
>> Stephan Mueller <smueller@xxxxxxxxxx> wrote:
>>
>>> Some time ago, I noticed the fact that for every newly
>>> executed process, the function create_elf_tables requests 16 bytes of
>>> randomness from get_random_bytes. This is easily visible when calling
>>>
>>> while [ 1 ]
>>> do
>>> 	cat /proc/sys/kernel/random/entropy_avail
>>> 	sleep 1
>>> done
>> Please see
>> http://ozlabs.org/~akpm/mmotm/broken-out/binfmt_elfc-use-get_random_int-to-fix-entropy-depleting.patch
>>
>> That patch is about one week from a mainline merge, btw.
> Initially I was also thinking about get_random_int. But stack protection
> depends on non-predictable numbers to ensure it cannot be defeated. As
> get_random_int depends on MD5 which is assumed to be broken now, I
> discarded the idea of using get_random_int.
>
> Moreover, please consider that get_cycles is an architecture-specific
> function that on some architectures only returns 0 (For all
> architectures where this is implemented, you have no guarantee that it
> increments as a high-resolution timer). So, the quality of
> get_random_int is questionable IMHO for the use as a stack protector.
>
> Also note, that other in-kernel users of get_random_bytes may be
> converted to using the proposed kernel pool to avoid more entropy drainage.
>
> Please note that the suggested approach of fully seeding a deterministic
> RNG never followed by a re-seeding is used elsewhere (e.g. the OpenSSL
> RNG). Therefore, I think the suggested approach is viable.

I would like to add one more thing to consider. As the get_random_int
state depends on a relatively predictable timer reading, especially on
architectures without get_cycles(), hashed by MD5, it gains strength
(read unpredictability, entropy) over time. I.e. the more random numbers
are *randomly* extracted, the more random the value is.

Since many applications that are intended to benefit from stack
protection are started during boot time (e.g. the SSH daemon, Web
servers, Mail servers, other networking servers), I would conclude that
at the time these applications need random values, the strength behind
get_random_int is very low.

With my proposed patch, we have a similar strength than /dev/urandom but
without the drag on entropy during normal operation time -- i.e. the
time when cryptography comes into play triggered by normal users. Only
at that time the system needs to conserve entropy.
>
> Ciao
> Stephan
>

-- 
| Cui bono? |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/