Re: [v4, resend] fcntl-linux.h: add new definitions and manual updates for open file description locks
On Sat, May 03, 2014 at 09:33:24AM -0400, Jeff Layton wrote: > Open file description locks have been merged into the Linux kernel for > v3.15. Add the appropriate command-value definitions and an update to > the manual that describes their usage. > > ChangeLog: > > 2014-04-24 Jeff Layton > > [BZ#16839] > * manual/llio.texi: add section about open file description locks > > * sysdeps/unix/sysv/linux/bits/fcntl-linux.h: > (F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW): New macros. > manual/examples/ofdlocks.c entry is missing. Otherwise ok for me, Carlos, Michael do you have additional comments? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4, resend] fcntl-linux.h: add new definitions and manual updates for open file description locks
On Sat, May 03, 2014 at 09:33:24AM -0400, Jeff Layton wrote: Open file description locks have been merged into the Linux kernel for v3.15. Add the appropriate command-value definitions and an update to the manual that describes their usage. ChangeLog: 2014-04-24 Jeff Layton jlay...@poochiereds.net [BZ#16839] * manual/llio.texi: add section about open file description locks * sysdeps/unix/sysv/linux/bits/fcntl-linux.h: (F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW): New macros. manual/examples/ofdlocks.c entry is missing. Otherwise ok for me, Carlos, Michael do you have additional comments? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, Aug 06, 2013 at 08:56:00PM -0400, Steven Rostedt wrote: > On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote: > > > [3.387362] short jumps: 106 > > [3.390277] long jumps: 330 > > > > Thus, approximately 25%. Not bad. > > Also, where these happen to be is probably even more important than how > many. If all the short jumps happen in slow paths, it's rather > pointless. But they seem to be in some rather hot paths. I had it print > out where it placed the short jumps too: > > The kmem_cache_* and the try_to_wake_up* are the hot paths that caught > my eye. > > But still, is this worth it? > Add short_counter,long_counter and before increment counter before each jump. That way we will know how many short/long jumps were taken. > -- Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] gcc feature request: Moving blocks into sections
On Tue, Aug 06, 2013 at 08:56:00PM -0400, Steven Rostedt wrote: On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote: [3.387362] short jumps: 106 [3.390277] long jumps: 330 Thus, approximately 25%. Not bad. Also, where these happen to be is probably even more important than how many. If all the short jumps happen in slow paths, it's rather pointless. But they seem to be in some rather hot paths. I had it print out where it placed the short jumps too: The kmem_cache_* and the try_to_wake_up* are the hot paths that caught my eye. But still, is this worth it? Add short_counter,long_counter and before increment counter before each jump. That way we will know how many short/long jumps were taken. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
On Sat, Dec 15, 2012 at 07:30:20PM -0500, Theodore Ts'o wrote: > > What I would do instead is use an AES-based cryptographic random > number generator. That is, at boot time, grab enough randomness to > for an AES key, and then use that key to create a cryptographic random > number generator by encrypting a counter with said AES key. This is a > cryptographic primitive which has been very carefully studied, and for > architectures where you have a hardware support for AES (including > ARMv8, Power 7, Sparc T4, as well as x86 processors with the AES-NI > instructions), this will be much faster and require much less memory > and CPU resources than replicating the /dev/urandom infrastructure. > I was suggesting in another thread different approach. Use AES-based cryptographic random number generator as replacement of /dev/urandom. Reseeding would get done by changing both aes key and data. This would with hardware support make /dev/urandom much faster than its now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
On Sat, Dec 15, 2012 at 11:59:46PM +0100, Stephan Müller wrote: > Am 15.12.2012 20:15, schrieb Ondřej Bílka: > >Why not use nonblocking pool and seed nonblocking pool only with half of > >collected entropy to get /dev/random in almost all practical scenarios > >nonblocking? > > I would not recommend changing /dev/urandom. First, we would change > the characteristic of a kernel interface a lot of user space > cryptographic components rely on. How it would change characteristic more than swapping a hard disk for a ssd? Should we display a message "Please type more slowly to maintain kernel interface."? > According to Linus that is > typically a no-go. Moreover, the question can be raised, where do we > pick the number of 50%, why not 30% or 70%, why (re)seeding it at > all? And does this argument make any difference? > > Also, let us assume we pick 50% and we leave the create_elf_tables > function as is (i.e. it pulls from get_random_bytes), I fear that we > do not win at all. Our discussed problem is the depletion of the > entropy via nonblocking_pool due to every execve() syscall requires > 128 bits of data from nonblocking_pool. Even if we seed > nonblocking_pool more rarely, we still deplete the entropy of the > input_pool and thus deplete the entropy we want for cryptographic > purposes a particular user has. This is only correct upto thus part. As blocking pool would get full after 8096 bytes would be generated, stayed full until needed and won't be affected by input pool. As long as we would generate at least twice entropy than blocking pool consumes we would be fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
On Sat, Dec 15, 2012 at 11:59:46PM +0100, Stephan Müller wrote: Am 15.12.2012 20:15, schrieb Ondřej Bílka: Why not use nonblocking pool and seed nonblocking pool only with half of collected entropy to get /dev/random in almost all practical scenarios nonblocking? I would not recommend changing /dev/urandom. First, we would change the characteristic of a kernel interface a lot of user space cryptographic components rely on. How it would change characteristic more than swapping a hard disk for a ssd? Should we display a message Please type more slowly to maintain kernel interface.? According to Linus that is typically a no-go. Moreover, the question can be raised, where do we pick the number of 50%, why not 30% or 70%, why (re)seeding it at all? And does this argument make any difference? Also, let us assume we pick 50% and we leave the create_elf_tables function as is (i.e. it pulls from get_random_bytes), I fear that we do not win at all. Our discussed problem is the depletion of the entropy via nonblocking_pool due to every execve() syscall requires 128 bits of data from nonblocking_pool. Even if we seed nonblocking_pool more rarely, we still deplete the entropy of the input_pool and thus deplete the entropy we want for cryptographic purposes a particular user has. This is only correct upto thus part. As blocking pool would get full after 8096 bytes would be generated, stayed full until needed and won't be affected by input pool. As long as we would generate at least twice entropy than blocking pool consumes we would be fine. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
On Sat, Dec 15, 2012 at 07:30:20PM -0500, Theodore Ts'o wrote: What I would do instead is use an AES-based cryptographic random number generator. That is, at boot time, grab enough randomness to for an AES key, and then use that key to create a cryptographic random number generator by encrypting a counter with said AES key. This is a cryptographic primitive which has been very carefully studied, and for architectures where you have a hardware support for AES (including ARMv8, Power 7, Sparc T4, as well as x86 processors with the AES-NI instructions), this will be much faster and require much less memory and CPU resources than replicating the /dev/urandom infrastructure. I was suggesting in another thread different approach. Use AES-based cryptographic random number generator as replacement of /dev/urandom. Reseeding would get done by changing both aes key and data. This would with hardware support make /dev/urandom much faster than its now. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
Why not use nonblocking pool and seed nonblocking pool only with half of
collected entropy to get /dev/random in almost all practical scenarios
nonblocking?
On Thu, Dec 13, 2012 at 08:44:36AM +0100, Stephan Mueller wrote:
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> wrote:
>
> Hi Andrew,
> > On Tue, 11 Dec 2012 13:33:04 +0100
> > Stephan Mueller 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.
>
> Ciao
> Stephan
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
It's those computer people in X {city of world}. They keep stuffing things up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
Why not use nonblocking pool and seed nonblocking pool only with half of
collected entropy to get /dev/random in almost all practical scenarios
nonblocking?
On Thu, Dec 13, 2012 at 08:44:36AM +0100, Stephan Mueller wrote:
On 13.12.2012 01:43:21, +0100, Andrew Morton
a...@linux-foundation.org wrote:
Hi Andrew,
On Tue, 11 Dec 2012 13:33:04 +0100
Stephan Mueller smuel...@chronox.de 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.
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
It's those computer people in X {city of world}. They keep stuffing things up.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] AES instead of SHA1 for /dev/urandom
On Wed, Dec 12, 2012 at 01:08:26PM +1100, NeilBrown wrote: > On Wed, 12 Dec 2012 03:03:54 +0100 Ondřej Bílka wrote: > > > I consider to speed-up /dev/urandom on recent intel processors by > > using hardware aes. Same for accelerated aes crypto. > > > > Would you accept a patch if I wrote it? > > Have you read https://lwn.net/Articles/525459 ? > Yes > In particular the paragraph containing: > >A member of the audience asked why the kernel couldn't just do away with >the existing system and use the HWRNG directly. > > Does that answer your question in any way? > No as AES is a HWRNG about as much as horse is type of automobile. Ondra -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] AES instead of SHA1 for /dev/urandom
On Wed, Dec 12, 2012 at 01:08:26PM +1100, NeilBrown wrote: On Wed, 12 Dec 2012 03:03:54 +0100 Ondřej Bílka nel...@seznam.cz wrote: I consider to speed-up /dev/urandom on recent intel processors by using hardware aes. Same for accelerated aes crypto. Would you accept a patch if I wrote it? Have you read https://lwn.net/Articles/525459 ? Yes In particular the paragraph containing: A member of the audience asked why the kernel couldn't just do away with the existing system and use the HWRNG directly. Does that answer your question in any way? No as AES is a HWRNG about as much as horse is type of automobile. Ondra -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] AES instead of SHA1 for /dev/urandom
I consider to speed-up /dev/urandom on recent intel processors by using hardware aes. Same for accelerated aes crypto. Would you accept a patch if I wrote it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] AES instead of SHA1 for /dev/urandom
I consider to speed-up /dev/urandom on recent intel processors by using hardware aes. Same for accelerated aes crypto. Would you accept a patch if I wrote it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
