On Thu 2014-07-31 10:06:37, Bernd Petrovitsch wrote:
> On Don, 2014-07-31 at 00:18 +0200, Pavel Machek wrote:
> > On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote:
> > > On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> > > > Pavel. I have bit 'ol enterprise daemon running with established fi
On Don, 2014-07-31 at 00:18 +0200, Pavel Machek wrote:
> On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote:
> > On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> > > Pavel. I have bit 'ol enterprise daemon running with established file
> > > descriptors serving thousands of connections
> > > w
On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote:
> On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> > Pavel. I have bit 'ol enterprise daemon running with established file
> > descriptors serving thousands of connections
> > which periodically require entropy. Now I run out of descriptors.
On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> Pavel. I have bit 'ol enterprise daemon running with established file
> descriptors serving thousands of connections
> which periodically require entropy. Now I run out of descriptors. I
> can't establish new connections. but I should
> now halt
Pavel. I have bit 'ol enterprise daemon running with established file
descriptors serving thousands of connections
which periodically require entropy. Now I run out of descriptors. I
can't establish new connections. but I should
now halt all the other ones that require entropy? I should raise
SIG
Hi!
> The rationale of this system call is to provide resiliance against
> file descriptor exhaustion attacks, where the attacker consumes all
> available file descriptors, forcing the use of the fallback code where
> /dev/[u]random is not available. Since the fallback code is often not
> well-te
> EAGAIN The requested entropy was not available, and the
> getentropy(2) would have blocked if GRND_BLOCK flag
> was set.
I think either "and the call to getentropy(2)" or "and getentropy(2)" here.
Greetings,
Eike
--
To unsubscribe from
On Mon, Jul 21, 2014 at 10:21:26PM +0200, Till Smejkal wrote:
> Hi,
>
> On Fri, 18 Jul 2014, Theodore Ts'o wrote:
> [...]
> > If the GRND_RANDOM bit is not set, then the /dev/urandom pool
> > will be used. Unlike using read(2) to fetch data from
> > /dev/urandom, if the urandom pool h
Hi,
On Fri, 18 Jul 2014, Theodore Ts'o wrote:
[...]
> If the GRND_RANDOM bit is not set, then the /dev/urandom pool
> will be used. Unlike using read(2) to fetch data from
> /dev/urandom, if the urandom pool has not been sufficiently
> initialized, getrandom(2) will block
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descr
10 matches
Mail list logo
