On 05/11/2014 08:36 PM, Stephan Mueller wrote:
>
> But in our current predicament, not everybody trusts a few potentially easily
> manipulated gates that have no other purpose than produce white noise which
> are developed by the biggest chip vendor in the US. Gates which have other
> purposes
On 05/11/2014 08:36 PM, Stephan Mueller wrote:
>
> Ohh, ok, thanks for fixing that. :-)
>
> Though what makes me wonder is the following: why are some RNGs forced to use
> the hw_random framework whereas some others are not? What is the driver for
> that?
>
> The current state of random.c vs.
Am Sonntag, 11. Mai 2014, 20:22:28 schrieb H. Peter Anvin:
Hi Peter,
>
> > Note, I do not see an issue with the patch that adds RDSEED as part of
> > add_interrupt_randomness outlined in [2]. The reason is that this patch
> > does not monopolizes the noise sources.
> >
> > I do not want to imply
On 05/11/2014 04:01 PM, Stephan Mueller wrote:
> Hi Peter,
>
> some time back when the RDRAND instruction was debated, a patch was offered
> for driver/char/random.c that in essence turned /dev/random into a frontend
> for RDRAND in case that instruction was available. The patch kind of
> monop
From: Fabio Estevam
Remove mutex_lock from probe in order to avoid the following warning:
[8.526613] Freeing unused kernel memory: 232K (c0683000 - c06bd000)
starting pid 56, tty '': '/etc/rc.d/rcS'
[9.110314]
[9.111864] =
[9.116603] [ BUG: ini
On Friday, May 09, 2014 8:36 PM, Arnd Bergmann wrote:
>
> As we are preparing to enable multiplatform support on EXYNOS,
> we can no longer include mach/*.h or plat/*.h headers from device
> drivers.
>
> The s5p-sss driver was just enabled for EXYNOS when it used to
> be used only on s5pv210, and
Hi Peter,
some time back when the RDRAND instruction was debated, a patch was offered
for driver/char/random.c that in essence turned /dev/random into a frontend
for RDRAND in case that instruction was available. The patch kind of
monopolized the noise sources such that if a user space "random
The kernel pool is intended to serve kernel-internal callers only.
Its purpose and usage is identical to the blocking_pool.
As the kernel_pool is not available to user space, user space cannot
directly interfere with the blocking behavior when obtaining
data from the kernel_pool. Thus, if entropy
Hi,
as discussed in thread [1], an in-kernel equivalent to the blocking
/dev/random device behavior is suggested. This in-kernel blocking access to
the RNG can be used to seed deterministic random number generators with random
numbers that are directly backed by the underlying noise sources.
T
The kernel_pool is intended to be the in-kernel equivalent to the
blocking_pool, i.e. requests for random data may be blocked if
insufficient entropy is present.
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked.
In addition, an asynchro
Sun, 11 May 2014 17:09:27 -0300 от Fabio Estevam :
> On Sun, May 11, 2014 at 5:08 PM, Alexander Shiyan wrote:
> > Sun, 11 May 2014 16:57:57 -0300 от Fabio Estevam :
> >> Hi,
> >>
> >> Running linux-next 20140509 on a mx28evk I observe the following warning:
> >>
> >> [8.526613] Freeing unused
On Sun, May 11, 2014 at 5:08 PM, Alexander Shiyan wrote:
> Sun, 11 May 2014 16:57:57 -0300 от Fabio Estevam :
>> Hi,
>>
>> Running linux-next 20140509 on a mx28evk I observe the following warning:
>>
>> [8.526613] Freeing unused kernel memory: 232K (c0683000 - c06bd000)
>> starting pid 56, tty
Sun, 11 May 2014 16:57:57 -0300 от Fabio Estevam :
> Hi,
>
> Running linux-next 20140509 on a mx28evk I observe the following warning:
>
> [8.526613] Freeing unused kernel memory: 232K (c0683000 - c06bd000)
> starting pid 56, tty '': '/etc/rc.d/rcS'
> [9.110314]
> [9.111864] =
Hi,
Running linux-next 20140509 on a mx28evk I observe the following warning:
[8.526613] Freeing unused kernel memory: 232K (c0683000 - c06bd000)
starting pid 56, tty '': '/etc/rc.d/rcS'
[9.110314]
[9.111864] =
[9.116603] [ BUG: init/1 still has
14 matches
Mail list logo
