Useless stack randomization patch

DISCUSSION Franck Bui-Huu 3 participants 6 messages Sep 26, 2007 – Sep 27, 2007

Subsystems (3)

VFS MIPS exec and binfmt

lore

Share & tools

lore

Franck Bui-Huu

author

2007-09-26 14:12 UTC #0 lore raw

Ralf,

We started stack inside page randomization through commit 941091024ef0f2f7e09eb81201d293ac18833cc8 but it currently does nothing usefull because ELF_PLATFORM is not defined on MIPS (see fs/binfm_elf.c, create_elf_tables() for details).

I tried several times to get information on lkml about that dependency but unfortunately I got no answer.

I'm not sure how ELF_PLATFORM is used by ld.so and I don't think it's a good idea to define it just for enabling stack randomization.

What do you think ?

thanks
Franck

Markus Gothe

2007-09-26 14:23 UTC #1 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Quoted 10 lines · Franck Bui-Huu

Ralf,
We started stack inside page randomization through commit 941091024ef0f2f7e09eb81201d293ac18833cc8 but it currently does nothing usefull because ELF_PLATFORM is not defined on MIPS (see fs/binfm_elf.c, create_elf_tables() for details).
I tried several times to get information on lkml about that dependency but unfortunately I got no answer.

Quoted 8 lines

I'm not sure how ELF_PLATFORM is used by ld.so and I don't think it's a good idea to define it just for enabling stack randomization.
What do you think ?
thanks
Franck

I think you mean this in specific:

"/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in intent than poking at uname or /proc/cpuinfo.

For the moment, we have only optimizations for the Intel generations, but that could change... */

#define ELF_PLATFORM (NULL)"

Right?

- --
_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80 Diskettgatan 11, SE-583 35 Linköping, Sweden www.27m.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG+msl6I0XmJx2NrwRCBm0AJ99yMRx1Kkre9bPa3y9lkV+xHSvVwCcC6qP 5AoYOLF7HLEOPrnr8fIhBuk=
=+uD/
-----END PGP SIGNATURE-----

Franck Bui-Huu

author

2007-09-26 14:29 UTC #2 lore raw

Quoted 6 lines · Markus Gothe

I think you mean this in specific:
"/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in intent than poking at uname or /proc/cpuinfo.

Quoted 7 lines

For the moment, we have only optimizations for the Intel generations, but that could change... */
#define ELF_PLATFORM (NULL)"
Right?

Correct...

Franck

Ralf Baechle

2007-09-26 15:04 UTC #3 lore raw

In reply to Franck Bui-Huu

Quoted 7 lines · Franck Bui-Huu

We started stack inside page randomization through commit 941091024ef0f2f7e09eb81201d293ac18833cc8 but it currently does nothing usefull because ELF_PLATFORM is not defined on MIPS (see fs/binfm_elf.c, create_elf_tables() for details).
I tried several times to get information on lkml about that dependency but unfortunately I got no answer.

lkml has turned into a posting-only mailing list. I've stopped reading it years ago; the volume is so insane that I only use it to occasionally to follow references from other sources. So don't be surprised if you don't get an answer. Linus does not read lkml either.

Quoted 4 lines

I'm not sure how ELF_PLATFORM is used by ld.so and I don't think it's a good idea to define it just for enabling stack randomization.
What do you think ?

I suppose we should give it a sane definition. Not sure what would be useful, if it should be like an ASCII string with the processor type or more corse grained like just "mips32r2", should ASEs be mentioned ...

Ralf

Franck Bui-Huu

author

2007-09-26 15:22 UTC #4 lore raw

Quoted 5 lines · Ralf Baechle

On Wed, Sep 26, 2007 at 04:10:14PM +0200, Franck Bui-Huu wrote:
I suppose we should give it a sane definition. Not sure what would be useful, if it should be like an ASCII string with the processor type or more corse grained like just "mips32r2", should ASEs be mentioned ...

Well before giving any sane definition, shouldn't we know why this dependency (ELF_PLATFORM/sp-randomization) exists at all...

Is something like the patch below better ?

Franck

-- 8< --

fs/binfmt_elf.c +7 -8

index 43143c5..e8713fb 100644
@@ -150,6 +150,13 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
 	struct vm_area_struct *vma;
 
 	/*
+	 * In some cases (e.g. Hyper-Threading), we want to avoid L1
+	 * evictions by the processes running on the same package. One
+	 * thing we can do is to shuffle the initial stack for them.
+	 */
+	p = arch_align_stack(p);
+
+	/*
 	 * If this architecture has a platform capability string, copy it
 	 * to userspace.  In some cases (Sparc), this info is impossible
 	 * for userspace to get any other way, in others (i386) it is

@@ -159,14 +166,6 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
 	if (k_platform) {
 		size_t len = strlen(k_platform) + 1;
 
-		/*
-		 * In some cases (e.g. Hyper-Threading), we want to avoid L1
-		 * evictions by the processes running on the same package. One
-		 * thing we can do is to shuffle the initial stack for them.
-		 */
-
-		p = arch_align_stack(p);
-
 		u_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
 		if (__copy_to_user(u_platform, k_platform, len))
 			return -EFAULT;

Ralf Baechle

2007-09-27 14:57 UTC #5 lore raw

Quoted 11 lines · Franck Bui-Huu

Quoted 5 lines · Ralf Baechle
On Wed, Sep 26, 2007 at 04:10:14PM +0200, Franck Bui-Huu wrote:
I suppose we should give it a sane definition. Not sure what would be useful, if it should be like an ASCII string with the processor type or more corse grained like just "mips32r2", should ASEs be mentioned ...
Well before giving any sane definition, shouldn't we know why this dependency (ELF_PLATFORM/sp-randomization) exists at all...
Is something like the patch below better ?

Yes, I think that makes more sense.

Ralf