Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Mon, Jun 25, 2007 at 05:02:01PM +0200, Alexander Gabert wrote: > >Am I right in thinking you have three unrelated patches here? > > > I don't think so but you may be right nonetheless if my opinion. The point is: the way we do development here is to break things down into a series of simple, obvious pieces and send them individually. Each patch should build and run when applied on top of the earlier patches. Then each part can be reviewed, tested, and applied on its own. It also makes figuring out what happened in the future and tracking down bugs much easier. So send three patches in this order: - fix get_random_int - rename it - add auxv bits Also, you might want to drop Linus from the cc: list unless he's chimed in on this topic already. The likely path here is for the first two patches to go through me and the last to go through Arjan, then on to Andrew Morton for his -mm tree, and then to Linus after a bit. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
Hi Matt, sorry for not answering your questions in the first place, i hope this did not mean to make a bad impression Matt Mackall schrieb: On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote: Hi Linus, hi LKML, i would like to thank LKML and especially Eric (thanks for the per_cpu macro tips and design guidelines!) and the other contributors to this idea. This time the patch is rather big because it also removes get_random_int() and introduces get_random_long() throughout the kernel. Stop right there. You still haven't answered my original question. What is the point of this exercise in the first place, please? Am I right in thinking you have three unrelated patches here? I don't think so but you may be right nonetheless if my opinion. - something to do with aux vector headers Adding the new field - something to do with get_random_int repeating itself Found while adding the new field and testing it. - sweeping change of get_random_int to get_random_long for no obvious reason It is needed for properly initializing a SSP guard which is (afaik) a long value. These should be three completely separate patches. Probably ... but bear in mind that the goal is still the same: allowing glibc to use SSP with /proc/self/auxv instead of fopen(/dev/urandom) as it is now. Effectively saving three syscalls (open,read,close) and making life easier for glibc because randomization "generated" in the kernel does not deplete /dev/urandom too much for high coverage SSP userlands (i.e. Gentoo Hardened). I can imagine that Redhat would do the same with the SSP implementation in glibc, i think if this patch moves into kernel, they will bring out a glibc patch that is checking for AT_ENTROPY and using the opening of /dev/urandom for retrieving randomized data as a fallback for machines where such a kernel is not available. This is a win-win situation for both sides- the kernel wins because the pressure on /dev/urandom is released a bit (applicable to SSP environments) and the glibc wins because it has a reliable, fast, cheap and easy to use source for randomization. Thank you, Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote: > > - something to do with aux vector headers > > the primary goal is to pass a random value to userspace at process > start; this to save glibc from having to open /dev/urandom on ever > program start (which it does now for all apps compiled with > -fstack-protector, which in various distros is "everything"). There are 2 ways to compile -fstack-protector supporting glibc actually, only one opens /dev/urandom on every program initialization, the other computes the stack guard from some bits of the stack address (so indirectly depends on get_random_int() in stack randomization). Nevertheless, having one random long (32-bit for 32-bit arches, 64-bit otherwise) in aux vector would be useful. Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote: - something to do with aux vector headers the primary goal is to pass a random value to userspace at process start; this to save glibc from having to open /dev/urandom on ever program start (which it does now for all apps compiled with -fstack-protector, which in various distros is everything). There are 2 ways to compile -fstack-protector supporting glibc actually, only one opens /dev/urandom on every program initialization, the other computes the stack guard from some bits of the stack address (so indirectly depends on get_random_int() in stack randomization). Nevertheless, having one random long (32-bit for 32-bit arches, 64-bit otherwise) in aux vector would be useful. Jakub - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
Hi Matt, sorry for not answering your questions in the first place, i hope this did not mean to make a bad impression Matt Mackall schrieb: On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote: Hi Linus, hi LKML, i would like to thank LKML and especially Eric (thanks for the per_cpu macro tips and design guidelines!) and the other contributors to this idea. This time the patch is rather big because it also removes get_random_int() and introduces get_random_long() throughout the kernel. Stop right there. You still haven't answered my original question. What is the point of this exercise in the first place, please? Am I right in thinking you have three unrelated patches here? I don't think so but you may be right nonetheless if my opinion. - something to do with aux vector headers Adding the new field - something to do with get_random_int repeating itself Found while adding the new field and testing it. - sweeping change of get_random_int to get_random_long for no obvious reason It is needed for properly initializing a SSP guard which is (afaik) a long value. These should be three completely separate patches. Probably ... but bear in mind that the goal is still the same: allowing glibc to use SSP with /proc/self/auxv instead of fopen(/dev/urandom) as it is now. Effectively saving three syscalls (open,read,close) and making life easier for glibc because randomization generated in the kernel does not deplete /dev/urandom too much for high coverage SSP userlands (i.e. Gentoo Hardened). I can imagine that Redhat would do the same with the SSP implementation in glibc, i think if this patch moves into kernel, they will bring out a glibc patch that is checking for AT_ENTROPY and using the opening of /dev/urandom for retrieving randomized data as a fallback for machines where such a kernel is not available. This is a win-win situation for both sides- the kernel wins because the pressure on /dev/urandom is released a bit (applicable to SSP environments) and the glibc wins because it has a reliable, fast, cheap and easy to use source for randomization. Thank you, Alex - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Mon, Jun 25, 2007 at 05:02:01PM +0200, Alexander Gabert wrote: Am I right in thinking you have three unrelated patches here? I don't think so but you may be right nonetheless if my opinion. The point is: the way we do development here is to break things down into a series of simple, obvious pieces and send them individually. Each patch should build and run when applied on top of the earlier patches. Then each part can be reviewed, tested, and applied on its own. It also makes figuring out what happened in the future and tracking down bugs much easier. So send three patches in this order: - fix get_random_int - rename it - add auxv bits Also, you might want to drop Linus from the cc: list unless he's chimed in on this topic already. The likely path here is for the first two patches to go through me and the last to go through Arjan, then on to Andrew Morton for his -mm tree, and then to Linus after a bit. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote: > On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote: > > On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote: > > > Hi Linus, > > > hi LKML, > > > > > > i would like to thank LKML and especially Eric (thanks for the per_cpu > > > macro tips and design guidelines!) and the other contributors to this > > > idea. > > > > > > This time the patch is rather big because it also removes > > > get_random_int() and introduces get_random_long() throughout the kernel. > > > > Stop right there. You still haven't answered my original question. > > What is the point of this exercise in the first place, please? > > > > Am I right in thinking you have three unrelated patches here? > > > > - something to do with aux vector headers > > the primary goal is to pass a random value to userspace at process > start; this to save glibc from having to open /dev/urandom on ever > program start (which it does now for all apps compiled with > -fstack-protector, which in various distros is "everything"). Interesting. What are our requirements here? Defending against local attackers who can build exploits on the fly probably means something stronger than get_random_int. > > - sweeping change of get_random_int to get_random_long for no obvious reason > > and this is because Alexander wants 2 and not 1 random int to be passed > for his own glibc proposed change (combined with get_random_int() being > designed for only 4 bytes per process ;-) Sure. Still, separate patches. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote: > On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote: > > Hi Linus, > > hi LKML, > > > > i would like to thank LKML and especially Eric (thanks for the per_cpu > > macro tips and design guidelines!) and the other contributors to this idea. > > > > This time the patch is rather big because it also removes > > get_random_int() and introduces get_random_long() throughout the kernel. > > Stop right there. You still haven't answered my original question. > What is the point of this exercise in the first place, please? > > Am I right in thinking you have three unrelated patches here? > > - something to do with aux vector headers the primary goal is to pass a random value to userspace at process start; this to save glibc from having to open /dev/urandom on ever program start (which it does now for all apps compiled with -fstack-protector, which in various distros is "everything"). > - sweeping change of get_random_int to get_random_long for no obvious reason and this is because Alexander wants 2 and not 1 random int to be passed for his own glibc proposed change (combined with get_random_int() being designed for only 4 bytes per process ;-) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> Hi Linus,
> hi LKML,
>
> i would like to thank LKML and especially Eric (thanks for the per_cpu
> macro tips and design guidelines!) and the other contributors to this idea.
>
> This time the patch is rather big because it also removes
> get_random_int() and introduces get_random_long() throughout the kernel.
Stop right there. You still haven't answered my original question.
What is the point of this exercise in the first place, please?
Am I right in thinking you have three unrelated patches here?
- something to do with aux vector headers
- something to do with get_random_int repeating itself
- sweeping change of get_random_int to get_random_long for no obvious reason
These should be three completely separate patches.
> My findings with get_random_int was that when i called it two times very
> fast after another because of setting up two SSP randomized guard values
> for the same process, it returned the same, yet randomized, integer number.
Send me a patch that fixes the above and nothing else, please.
Then we can talk about another patch to change things to get_random_long.
> --- linux-2.6.21.5.ORIG/arch/sparc64/kernel/sys_sparc.c 2007-06-11
> 20:37:06.0 +0200
> +++ linux-2.6.21.5/arch/sparc64/kernel/sys_sparc.c2007-06-24
> 19:01:44.0 +0200
> @@ -362,7 +362,7 @@
> unsigned long random_factor = 0UL;
>
> if (current->flags & PF_RANDOMIZE) {
> - random_factor = get_random_int();
> + random_factor = get_random_long();
This probably breaks Sparc64.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
Hi Linus,
hi LKML,
i would like to thank LKML and especially Eric (thanks for the per_cpu
macro tips and design guidelines!) and the other contributors to this idea.
This time the patch is rather big because it also removes
get_random_int() and introduces get_random_long() throughout the kernel.
The function get_random_int was primarily used for setting up the
randomization of memory used for process stacks and initializing a stack
canary in a tsk.
However, using get_random_long works exactly the same way to generate
randomization deltas for this purpose and i have applied it to all
locations where get_random_int was previously used.
Now to explain the reasoning for replacing get_random_int...
My findings with get_random_int was that when i called it two times very
fast after another because of setting up two SSP randomized guard values
for the same process, it returned the same, yet randomized, integer number.
I learned that get_random_int uses the current process pid and the
current jiffies for feeding the half_md4_transform function that's
following deeper in the code. However, when called in a relatively
short timeframe (lesser than a jiffie can increase it's count), this
information given to the underlying "randomization" generation is not
changing, which means when you call get_random_int two or more times in
short time, it will use the same data for generating the randomized
data, which is the pid of the process and current jiffies. The returned
randomized integer numbers are the same because the pid and the jiffies
used as the input for the randomization function did not change in such
a short time. Sorry that i cannot explain it more detailed or in better
english, you should be able to see it from the code looking at
get_random_int and how it's working by calling the other function and
looking at the input to the function.
Also remember that the comment in the function is probably a bit
outdated because rekeying is happening not every 1 second any more.
This is the url for the patch:
http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_random_long-AT_ENTROPY.patch
Thanks for the attention and thanks again to all posters for your help!
-Alex
This is the inlined patch, i changed my vimrc and really hope i'm not
making a whitespace error again:
diff -Nru linux-2.6.21.5.ORIG/arch/i386/kernel/process.c
linux-2.6.21.5/arch/i386/kernel/process.c
--- linux-2.6.21.5.ORIG/arch/i386/kernel/process.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/i386/kernel/process.c 2007-06-24 19:00:15.0
+0200
@@ -924,6 +924,6 @@
unsigned long arch_align_stack(unsigned long sp)
{
if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
- sp -= get_random_int() % 8192;
+ sp -= get_random_long() % 8192;
return sp & ~0xf;
}
diff -Nru linux-2.6.21.5.ORIG/arch/i386/mm/mmap.c
linux-2.6.21.5/arch/i386/mm/mmap.c
--- linux-2.6.21.5.ORIG/arch/i386/mm/mmap.c 2007-06-11 20:37:06.0
+0200
+++ linux-2.6.21.5/arch/i386/mm/mmap.c 2007-06-24 19:00:53.0 +0200
@@ -42,7 +42,7 @@
unsigned long random_factor = 0;
if (current->flags & PF_RANDOMIZE)
- random_factor = get_random_int() % (1024*1024);
+ random_factor = get_random_long() % (1024*1024);
if (gap < MIN_GAP)
gap = MIN_GAP;
diff -Nru linux-2.6.21.5.ORIG/arch/sparc64/kernel/sys_sparc.c
linux-2.6.21.5/arch/sparc64/kernel/sys_sparc.c
--- linux-2.6.21.5.ORIG/arch/sparc64/kernel/sys_sparc.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/sparc64/kernel/sys_sparc.c 2007-06-24
19:01:44.0 +0200
@@ -362,7 +362,7 @@
unsigned long random_factor = 0UL;
if (current->flags & PF_RANDOMIZE) {
- random_factor = get_random_int();
+ random_factor = get_random_long();
if (test_thread_flag(TIF_32BIT))
random_factor &= ((1 * 1024 * 1024) - 1);
else
diff -Nru linux-2.6.21.5.ORIG/arch/um/kernel/process.c
linux-2.6.21.5/arch/um/kernel/process.c
--- linux-2.6.21.5.ORIG/arch/um/kernel/process.c2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/um/kernel/process.c 2007-06-24 19:02:08.0
+0200
@@ -478,7 +478,7 @@
unsigned long arch_align_stack(unsigned long sp)
{
if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
- sp -= get_random_int() % 8192;
+ sp -= get_random_long() % 8192;
return sp & ~0xf;
}
#endif
diff -Nru linux-2.6.21.5.ORIG/arch/x86_64/ia32/mmap32.c
linux-2.6.21.5/arch/x86_64/ia32/mmap32.c
--- linux-2.6.21.5.ORIG/arch/x86_64/ia32/mmap32.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/x86_64/ia32/mmap32.c2007-06-24 19:02:34.0
+0200
@@ -44,7 +44,7 @@
unsigned long random_factor = 0;
if (current->flags & PF_RANDOMIZE)
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
Hi Linus,
hi LKML,
i would like to thank LKML and especially Eric (thanks for the per_cpu
macro tips and design guidelines!) and the other contributors to this idea.
This time the patch is rather big because it also removes
get_random_int() and introduces get_random_long() throughout the kernel.
The function get_random_int was primarily used for setting up the
randomization of memory used for process stacks and initializing a stack
canary in a tsk.
However, using get_random_long works exactly the same way to generate
randomization deltas for this purpose and i have applied it to all
locations where get_random_int was previously used.
Now to explain the reasoning for replacing get_random_int...
My findings with get_random_int was that when i called it two times very
fast after another because of setting up two SSP randomized guard values
for the same process, it returned the same, yet randomized, integer number.
I learned that get_random_int uses the current process pid and the
current jiffies for feeding the half_md4_transform function that's
following deeper in the code. However, when called in a relatively
short timeframe (lesser than a jiffie can increase it's count), this
information given to the underlying randomization generation is not
changing, which means when you call get_random_int two or more times in
short time, it will use the same data for generating the randomized
data, which is the pid of the process and current jiffies. The returned
randomized integer numbers are the same because the pid and the jiffies
used as the input for the randomization function did not change in such
a short time. Sorry that i cannot explain it more detailed or in better
english, you should be able to see it from the code looking at
get_random_int and how it's working by calling the other function and
looking at the input to the function.
Also remember that the comment in the function is probably a bit
outdated because rekeying is happening not every 1 second any more.
This is the url for the patch:
http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_random_long-AT_ENTROPY.patch
Thanks for the attention and thanks again to all posters for your help!
-Alex
This is the inlined patch, i changed my vimrc and really hope i'm not
making a whitespace error again:
diff -Nru linux-2.6.21.5.ORIG/arch/i386/kernel/process.c
linux-2.6.21.5/arch/i386/kernel/process.c
--- linux-2.6.21.5.ORIG/arch/i386/kernel/process.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/i386/kernel/process.c 2007-06-24 19:00:15.0
+0200
@@ -924,6 +924,6 @@
unsigned long arch_align_stack(unsigned long sp)
{
if (!(current-personality ADDR_NO_RANDOMIZE) randomize_va_space)
- sp -= get_random_int() % 8192;
+ sp -= get_random_long() % 8192;
return sp ~0xf;
}
diff -Nru linux-2.6.21.5.ORIG/arch/i386/mm/mmap.c
linux-2.6.21.5/arch/i386/mm/mmap.c
--- linux-2.6.21.5.ORIG/arch/i386/mm/mmap.c 2007-06-11 20:37:06.0
+0200
+++ linux-2.6.21.5/arch/i386/mm/mmap.c 2007-06-24 19:00:53.0 +0200
@@ -42,7 +42,7 @@
unsigned long random_factor = 0;
if (current-flags PF_RANDOMIZE)
- random_factor = get_random_int() % (1024*1024);
+ random_factor = get_random_long() % (1024*1024);
if (gap MIN_GAP)
gap = MIN_GAP;
diff -Nru linux-2.6.21.5.ORIG/arch/sparc64/kernel/sys_sparc.c
linux-2.6.21.5/arch/sparc64/kernel/sys_sparc.c
--- linux-2.6.21.5.ORIG/arch/sparc64/kernel/sys_sparc.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/sparc64/kernel/sys_sparc.c 2007-06-24
19:01:44.0 +0200
@@ -362,7 +362,7 @@
unsigned long random_factor = 0UL;
if (current-flags PF_RANDOMIZE) {
- random_factor = get_random_int();
+ random_factor = get_random_long();
if (test_thread_flag(TIF_32BIT))
random_factor = ((1 * 1024 * 1024) - 1);
else
diff -Nru linux-2.6.21.5.ORIG/arch/um/kernel/process.c
linux-2.6.21.5/arch/um/kernel/process.c
--- linux-2.6.21.5.ORIG/arch/um/kernel/process.c2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/um/kernel/process.c 2007-06-24 19:02:08.0
+0200
@@ -478,7 +478,7 @@
unsigned long arch_align_stack(unsigned long sp)
{
if (!(current-personality ADDR_NO_RANDOMIZE) randomize_va_space)
- sp -= get_random_int() % 8192;
+ sp -= get_random_long() % 8192;
return sp ~0xf;
}
#endif
diff -Nru linux-2.6.21.5.ORIG/arch/x86_64/ia32/mmap32.c
linux-2.6.21.5/arch/x86_64/ia32/mmap32.c
--- linux-2.6.21.5.ORIG/arch/x86_64/ia32/mmap32.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/x86_64/ia32/mmap32.c2007-06-24 19:02:34.0
+0200
@@ -44,7 +44,7 @@
unsigned long random_factor = 0;
if (current-flags PF_RANDOMIZE)
-
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
Hi Linus,
hi LKML,
i would like to thank LKML and especially Eric (thanks for the per_cpu
macro tips and design guidelines!) and the other contributors to this idea.
This time the patch is rather big because it also removes
get_random_int() and introduces get_random_long() throughout the kernel.
Stop right there. You still haven't answered my original question.
What is the point of this exercise in the first place, please?
Am I right in thinking you have three unrelated patches here?
- something to do with aux vector headers
- something to do with get_random_int repeating itself
- sweeping change of get_random_int to get_random_long for no obvious reason
These should be three completely separate patches.
My findings with get_random_int was that when i called it two times very
fast after another because of setting up two SSP randomized guard values
for the same process, it returned the same, yet randomized, integer number.
Send me a patch that fixes the above and nothing else, please.
Then we can talk about another patch to change things to get_random_long.
--- linux-2.6.21.5.ORIG/arch/sparc64/kernel/sys_sparc.c 2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/arch/sparc64/kernel/sys_sparc.c2007-06-24
19:01:44.0 +0200
@@ -362,7 +362,7 @@
unsigned long random_factor = 0UL;
if (current-flags PF_RANDOMIZE) {
- random_factor = get_random_int();
+ random_factor = get_random_long();
This probably breaks Sparc64.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote: On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote: Hi Linus, hi LKML, i would like to thank LKML and especially Eric (thanks for the per_cpu macro tips and design guidelines!) and the other contributors to this idea. This time the patch is rather big because it also removes get_random_int() and introduces get_random_long() throughout the kernel. Stop right there. You still haven't answered my original question. What is the point of this exercise in the first place, please? Am I right in thinking you have three unrelated patches here? - something to do with aux vector headers the primary goal is to pass a random value to userspace at process start; this to save glibc from having to open /dev/urandom on ever program start (which it does now for all apps compiled with -fstack-protector, which in various distros is everything). - sweeping change of get_random_int to get_random_long for no obvious reason and this is because Alexander wants 2 and not 1 random int to be passed for his own glibc proposed change (combined with get_random_int() being designed for only 4 bytes per process ;-) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote: On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote: On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote: Hi Linus, hi LKML, i would like to thank LKML and especially Eric (thanks for the per_cpu macro tips and design guidelines!) and the other contributors to this idea. This time the patch is rather big because it also removes get_random_int() and introduces get_random_long() throughout the kernel. Stop right there. You still haven't answered my original question. What is the point of this exercise in the first place, please? Am I right in thinking you have three unrelated patches here? - something to do with aux vector headers the primary goal is to pass a random value to userspace at process start; this to save glibc from having to open /dev/urandom on ever program start (which it does now for all apps compiled with -fstack-protector, which in various distros is everything). Interesting. What are our requirements here? Defending against local attackers who can build exploits on the fly probably means something stronger than get_random_int. - sweeping change of get_random_int to get_random_long for no obvious reason and this is because Alexander wants 2 and not 1 random int to be passed for his own glibc proposed change (combined with get_random_int() being designed for only 4 bytes per process ;-) Sure. Still, separate patches. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, Jun 20, 2007 at 05:34:13PM +0200, Alexander Gabert wrote: > Hi, > > http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_urandom_long-AT_ENTROPY.patch > > this patch adds the function drivers/char/random.c:get_random_long() > and adds an AT_ENTROPY field in the auxv without config option > (the config option was removed as suggested by Arjan on LKML). One ought to cc: the /dev/random maintainer. > /* > + * get_random_long() returns a randomized unsigned long word. > + * It recycles it's entropy cache for a given time period and > + * uses half_md4_transform to generate a unique return value. > + * Every REKEY_INTERVAL the cache is reloaded with fresh > + * randomization data using get_random_bytes(). > + * This function is not intended for strong cryptographic routines. > + */ What's the point of this? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, 20 Jun 2007 17:34:13 +0200
Alexander Gabert <[EMAIL PROTECTED]> wrote:
> Hi,
Hello Alexander
>
> http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_urandom_long-AT_ENTROPY.patch
>
> this patch adds the function drivers/char/random.c:get_random_long()
> and adds an AT_ENTROPY field in the auxv without config option
> (the config option was removed as suggested by Arjan on LKML).
>
> README: get_random_long() and AT_ENTROPY support for auxv
> NAME: Alexander Gabert
> EMAIL: [EMAIL PROTECTED]
>
>
>
> diff -Nru linux-2.6.21.5.ORIG/drivers/char/random.c
> linux-2.6.21.5/drivers/char/random.c
> --- linux-2.6.21.5.ORIG/drivers/char/random.c2007-06-11
> 20:37:06.0 +0200
> +++ linux-2.6.21.5/drivers/char/random.c2007-06-20
> 17:00:35.0 +0200
> @@ -1654,6 +1654,53 @@
> }
>
> /*
> + * get_random_long() returns a randomized unsigned long word.
> + * It recycles it's entropy cache for a given time period and
> + * uses half_md4_transform to generate a unique return value.
> + * Every REKEY_INTERVAL the cache is reloaded with fresh
> + * randomization data using get_random_bytes().
> + * This function is not intended for strong cryptographic routines.
> + */
> +unsigned long get_random_long(void)
> +{
> + /* remember the last time we refreshed the cache with random entropy */
> + static time_t rekey_time;
> +
> + time_t t;
> +
> + /*
> + * the following data in the buffer is unchanged during REKEY_INTERVAL:
> + * |||||||||||||
> + * ___0123456789___10___11__
> + *
> + * the following data is updated during the first half_md4_transform call
> + * |||||||||||||
> + * ___0123456789___10___11__
> + *
> + * the following data is updated during the second half_md4_transform
> + * |||||||||||||
> + * ___0123456789___10___11__
> + */
> + static __u32entropycache[12];
> +
> + /* get the current time in seconds */
> + t = get_seconds();
> +
> + /* check for REKEY_INTERVAL */
> + if (t && (!rekey_time || ((t - rekey_time) > REKEY_INTERVAL))) {
> +rekey_time = t;
> +/* refresh with random entropy */
> +get_random_bytes(entropycache, sizeof(entropycache));
> + }
Maybe this rekeying can be added in rekey_seq_generator(), so that you dont
have to test rekey_time each time get_random_long() is called. You probably
could refresh only 8 values, not the full 12 values.
> +
> + /* transform the buffer to a new state, thus generating new return
> value */
> + entropycache[1] = half_md4_transform(entropycache+8, entropycache);
> + entropycache[0] = half_md4_transform(entropycache+8, entropycache);
> +
> + return *(unsigned long *)entropycache;
This is not valid on some arches, as entropycache[] alignment (u32 -> 4) might
be smaller then alignment for a long (4 or 8).
This also adds about 400 instructions (half_md4_transform() is about 200
instructions, about 700 bytes of code on x86_64) in exec() path, but this is
probably minor given the cost of exec()
I am not sure why you unconditionally call half_md4_transform() twice, since
the entropycache[1] wont be used on 32bits platforms.
I suggest spliting your entropycache into two parts :
One part, with 8 u32, that is read_mostly (and shared by all cpus), updated
once every 300 seconds in rekey_seq_generator()
static u32 entropycache_shared[8] __read_mostly;
One part, with (16/sizeof(long)) long, percpu to avoid false sharing between
cpus.
static DEFINE_PER_CPU(unsigned long , entropycache_pcpu)[16 / sizeof(unsigned
long)];
then call half_md4_transform() once :
half_md4_transform((u32 *)entropycache_pcpu, entropycache_shared);
return entropycache_pcpu[0];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, 20 Jun 2007, Alexander Gabert wrote: > > this patch adds the function drivers/char/random.c:get_random_long() It's totally whitespace-damaged, and I wonder why the "int" vs "long" is so important. Also, what are the performance implications for execve? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, 2007-06-20 at 17:34 +0200, Alexander Gabert wrote: > Hi, > > http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_urandom_long-AT_ENTROPY.patch > > this patch adds the function drivers/char/random.c:get_random_long() > and adds an AT_ENTROPY field in the auxv without config option > (the config option was removed as suggested by Arjan on LKML). your patch has some whitespace damage it seems... other than that I can agree with the approach. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, 2007-06-20 at 17:34 +0200, Alexander Gabert wrote: Hi, http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_urandom_long-AT_ENTROPY.patch this patch adds the function drivers/char/random.c:get_random_long() and adds an AT_ENTROPY field in the auxv without config option (the config option was removed as suggested by Arjan on LKML). your patch has some whitespace damage it seems... other than that I can agree with the approach. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, 20 Jun 2007, Alexander Gabert wrote: this patch adds the function drivers/char/random.c:get_random_long() It's totally whitespace-damaged, and I wonder why the int vs long is so important. Also, what are the performance implications for execve? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, 20 Jun 2007 17:34:13 +0200
Alexander Gabert [EMAIL PROTECTED] wrote:
Hi,
Hello Alexander
http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_urandom_long-AT_ENTROPY.patch
this patch adds the function drivers/char/random.c:get_random_long()
and adds an AT_ENTROPY field in the auxv without config option
(the config option was removed as suggested by Arjan on LKML).
README: get_random_long() and AT_ENTROPY support for auxv
NAME: Alexander Gabert
EMAIL: [EMAIL PROTECTED]
diff -Nru linux-2.6.21.5.ORIG/drivers/char/random.c
linux-2.6.21.5/drivers/char/random.c
--- linux-2.6.21.5.ORIG/drivers/char/random.c2007-06-11
20:37:06.0 +0200
+++ linux-2.6.21.5/drivers/char/random.c2007-06-20
17:00:35.0 +0200
@@ -1654,6 +1654,53 @@
}
/*
+ * get_random_long() returns a randomized unsigned long word.
+ * It recycles it's entropy cache for a given time period and
+ * uses half_md4_transform to generate a unique return value.
+ * Every REKEY_INTERVAL the cache is reloaded with fresh
+ * randomization data using get_random_bytes().
+ * This function is not intended for strong cryptographic routines.
+ */
+unsigned long get_random_long(void)
+{
+ /* remember the last time we refreshed the cache with random entropy */
+ static time_t rekey_time;
+
+ time_t t;
+
+ /*
+ * the following data in the buffer is unchanged during REKEY_INTERVAL:
+ * |||||||||||||
+ * ___0123456789___10___11__
+ *
+ * the following data is updated during the first half_md4_transform call
+ * |||||||||||||
+ * ___0123456789___10___11__
+ *
+ * the following data is updated during the second half_md4_transform
+ * |||||||||||||
+ * ___0123456789___10___11__
+ */
+ static __u32entropycache[12];
+
+ /* get the current time in seconds */
+ t = get_seconds();
+
+ /* check for REKEY_INTERVAL */
+ if (t (!rekey_time || ((t - rekey_time) REKEY_INTERVAL))) {
+rekey_time = t;
+/* refresh with random entropy */
+get_random_bytes(entropycache, sizeof(entropycache));
+ }
Maybe this rekeying can be added in rekey_seq_generator(), so that you dont
have to test rekey_time each time get_random_long() is called. You probably
could refresh only 8 values, not the full 12 values.
+
+ /* transform the buffer to a new state, thus generating new return
value */
+ entropycache[1] = half_md4_transform(entropycache+8, entropycache);
+ entropycache[0] = half_md4_transform(entropycache+8, entropycache);
+
+ return *(unsigned long *)entropycache;
This is not valid on some arches, as entropycache[] alignment (u32 - 4) might
be smaller then alignment for a long (4 or 8).
This also adds about 400 instructions (half_md4_transform() is about 200
instructions, about 700 bytes of code on x86_64) in exec() path, but this is
probably minor given the cost of exec()
I am not sure why you unconditionally call half_md4_transform() twice, since
the entropycache[1] wont be used on 32bits platforms.
I suggest spliting your entropycache into two parts :
One part, with 8 u32, that is read_mostly (and shared by all cpus), updated
once every 300 seconds in rekey_seq_generator()
static u32 entropycache_shared[8] __read_mostly;
One part, with (16/sizeof(long)) long, percpu to avoid false sharing between
cpus.
static DEFINE_PER_CPU(unsigned long , entropycache_pcpu)[16 / sizeof(unsigned
long)];
then call half_md4_transform() once :
half_md4_transform((u32 *)entropycache_pcpu, entropycache_shared);
return entropycache_pcpu[0];
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5
On Wed, Jun 20, 2007 at 05:34:13PM +0200, Alexander Gabert wrote: Hi, http://dev.gentoo.org/~pappy/kernel/linux-2.6.21.5-get_urandom_long-AT_ENTROPY.patch this patch adds the function drivers/char/random.c:get_random_long() and adds an AT_ENTROPY field in the auxv without config option (the config option was removed as suggested by Arjan on LKML). One ought to cc: the /dev/random maintainer. /* + * get_random_long() returns a randomized unsigned long word. + * It recycles it's entropy cache for a given time period and + * uses half_md4_transform to generate a unique return value. + * Every REKEY_INTERVAL the cache is reloaded with fresh + * randomization data using get_random_bytes(). + * This function is not intended for strong cryptographic routines. + */ What's the point of this? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
