* Useless stack randomization patch @ 2007-09-26 14:10 Franck Bui-Huu 2007-09-26 14:22 ` Markus Gothe 2007-09-26 15:04 ` Ralf Baechle 0 siblings, 2 replies; 6+ messages in thread From: Franck Bui-Huu @ 2007-09-26 14:10 UTC (permalink / raw) To: Ralf Baechle; +Cc: nigel, linux-mips 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Useless stack randomization patch 2007-09-26 14:10 Useless stack randomization patch Franck Bui-Huu @ 2007-09-26 14:22 ` Markus Gothe 2007-09-26 14:27 ` Franck Bui-Huu 2007-09-26 15:04 ` Ralf Baechle 1 sibling, 1 reply; 6+ messages in thread From: Markus Gothe @ 2007-09-26 14:22 UTC (permalink / raw) To: Franck Bui-Huu; +Cc: Ralf Baechle, nigel, linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Franck Bui-Huu wrote: > 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 > 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----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Useless stack randomization patch 2007-09-26 14:22 ` Markus Gothe @ 2007-09-26 14:27 ` Franck Bui-Huu 0 siblings, 0 replies; 6+ messages in thread From: Franck Bui-Huu @ 2007-09-26 14:27 UTC (permalink / raw) To: Markus Gothe; +Cc: Ralf Baechle, nigel, linux-mips Markus Gothe wrote: > 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? > Correct... Franck ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Useless stack randomization patch 2007-09-26 14:10 Useless stack randomization patch Franck Bui-Huu 2007-09-26 14:22 ` Markus Gothe @ 2007-09-26 15:04 ` Ralf Baechle 2007-09-26 15:20 ` Franck Bui-Huu 1 sibling, 1 reply; 6+ messages in thread From: Ralf Baechle @ 2007-09-26 15:04 UTC (permalink / raw) To: Franck Bui-Huu; +Cc: nigel, linux-mips On Wed, Sep 26, 2007 at 04:10:14PM +0200, Franck Bui-Huu wrote: > 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. > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Useless stack randomization patch 2007-09-26 15:04 ` Ralf Baechle @ 2007-09-26 15:20 ` Franck Bui-Huu 2007-09-27 14:57 ` Ralf Baechle 0 siblings, 1 reply; 6+ messages in thread From: Franck Bui-Huu @ 2007-09-26 15:20 UTC (permalink / raw) To: Ralf Baechle; +Cc: nigel, linux-mips Ralf Baechle wrote: > 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< -- diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 43143c5..e8713fb 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -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; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Useless stack randomization patch 2007-09-26 15:20 ` Franck Bui-Huu @ 2007-09-27 14:57 ` Ralf Baechle 0 siblings, 0 replies; 6+ messages in thread From: Ralf Baechle @ 2007-09-27 14:57 UTC (permalink / raw) To: Franck Bui-Huu; +Cc: nigel, linux-mips On Wed, Sep 26, 2007 at 05:20:10PM +0200, Franck Bui-Huu wrote: > Ralf Baechle wrote: > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-09-27 14:57 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-09-26 14:10 Useless stack randomization patch Franck Bui-Huu 2007-09-26 14:22 ` Markus Gothe 2007-09-26 14:27 ` Franck Bui-Huu 2007-09-26 15:04 ` Ralf Baechle 2007-09-26 15:20 ` Franck Bui-Huu 2007-09-27 14:57 ` Ralf Baechle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox