No, it literally doesn't exist yet. As in it isn't in memory at the point this
is run.
Pavel Machek wrote:
>On Wed 2013-11-13 10:40:40, H. Peter Anvin wrote:
>> On 11/13/2013 10:16 AM, Pavel Machek wrote:
>> >
>> > If it is not performance critical, why not use "/dev/random"
>> > infrastructur
On Wed 2013-11-13 10:40:40, H. Peter Anvin wrote:
> On 11/13/2013 10:16 AM, Pavel Machek wrote:
> >
> > If it is not performance critical, why not use "/dev/random"
> > infrastructure?
> >
>
> Because it doesn't exist yet?
Would it be feasible to initialize /dev/random earlier instead of
reinve
On 11/13/2013 10:16 AM, Pavel Machek wrote:
>
> If it is not performance critical, why not use "/dev/random"
> infrastructure?
>
Because it doesn't exist yet?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
Hi!
> > x86, kaslr: Provide randomness functions
> >
> > Adds potential sources of randomness: RDRAND, RDTSC, or the i8254.
> >
> > This moves the pre-alternatives inline rdrand function into the header so
> > both pieces of code can use it. Availability of RDRAND is then controlled
> > by CONFI
XOR and rotate is probably a good start.
Kees Cook wrote:
>On Mon, Nov 11, 2013 at 12:07 PM, Ingo Molnar wrote:
>>
>> * H. Peter Anvin wrote:
>>
>>> Of course, perhaps we could just hash struct boot_params as a
>starting
>>> point?
>>
>> Yeah, that would be a good first step, before trying to p
On Mon, Nov 11, 2013 at 12:07 PM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> Of course, perhaps we could just hash struct boot_params as a starting
>> point?
>
> Yeah, that would be a good first step, before trying to parse DMI or ACPI.
> Anything that is reasonably system dependent and
* H. Peter Anvin wrote:
> On 11/11/2013 11:58 AM, Ingo Molnar wrote:
> >>
> >> Use the i8254 if and only if nothing else is available, it isn't safe to
> >> touch on some newer systems.
> >
> > I concur - the i8254 is probably also a low entry source, given that this
> > all runs early bootup.
* H. Peter Anvin wrote:
> Of course, perhaps we could just hash struct boot_params as a starting
> point?
Yeah, that would be a good first step, before trying to parse DMI or ACPI.
Anything that is reasonably system dependent and gives at least some
amount of unpredicability.
Thanks,
On 11/11/2013 11:58 AM, Ingo Molnar wrote:
>>
>> Use the i8254 if and only if nothing else is available, it isn't safe to
>> touch on some newer systems.
>
> I concur - the i8254 is probably also a low entry source, given that this
> all runs early bootup.
>
Well, it is a 16-bit 1.19318 MHz cou
* H. Peter Anvin wrote:
> On 11/11/2013 11:37 AM, Kees Cook wrote:
> > On Mon, Nov 11, 2013 at 11:27 AM, H. Peter Anvin wrote:
> >> On 11/11/2013 10:20 AM, Ingo Molnar wrote:
> >>>
> >>> Why aren't the 3 sources of entropy XOR-ed together?
> >>
> >> Note we don't want to poke i8254 if we have a
On 11/11/2013 11:37 AM, Kees Cook wrote:
> On Mon, Nov 11, 2013 at 11:27 AM, H. Peter Anvin wrote:
>> On 11/11/2013 10:20 AM, Ingo Molnar wrote:
>>>
>>> Why aren't the 3 sources of entropy XOR-ed together?
>>
>> Note we don't want to poke i8254 if we have any other sources, as the
>> i8254 may not
On 11/11/2013 11:32 AM, Kees Cook wrote:
>>>
>>> Why aren't the 3 sources of entropy XOR-ed together?
>
> Ah, excellent suggestion. There's no reason they couldn't be. I can
> rework that function to do that.
>
>>> Also, we talked about also adding system dependent entropy sources, such
>>> as me
On Mon, Nov 11, 2013 at 11:27 AM, H. Peter Anvin wrote:
> On 11/11/2013 10:20 AM, Ingo Molnar wrote:
>>
>> Why aren't the 3 sources of entropy XOR-ed together?
>>
>
> Note we don't want to poke i8254 if we have any other sources, as the
> i8254 may not be present on newer systems and in some other
On Mon, Nov 11, 2013 at 10:31 AM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>>
>> * tip-bot for Kees Cook wrote:
>>
>> > Commit-ID: 5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
>> > Gitweb:
>> > http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
>> > Author: Kees Cook
On 11/11/2013 10:20 AM, Ingo Molnar wrote:
>
> Why aren't the 3 sources of entropy XOR-ed together?
>
Note we don't want to poke i8254 if we have any other sources, as the
i8254 may not be present on newer systems and in some other cases not
safe to touch. We can XOR in the TSC with RDRAND alth
* Ingo Molnar wrote:
>
> * tip-bot for Kees Cook wrote:
>
> > Commit-ID: 5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> > Gitweb:
> > http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> > Author: Kees Cook
> > AuthorDate: Thu, 10 Oct 2013 17:18:15 -0700
> > Committer:
* tip-bot for Kees Cook wrote:
> Commit-ID: 5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> Gitweb: http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> Author: Kees Cook
> AuthorDate: Thu, 10 Oct 2013 17:18:15 -0700
> Committer: H. Peter Anvin
> CommitDate: Sun, 13 Oct 20
Commit-ID: 5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
Gitweb: http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
Author: Kees Cook
AuthorDate: Thu, 10 Oct 2013 17:18:15 -0700
Committer: H. Peter Anvin
CommitDate: Sun, 13 Oct 2013 03:12:12 -0700
x86, kaslr: Provide randomn
18 matches
Mail list logo
