Re: [PATCH v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:46 PM, Leonid Yegoshin wrote: On 08/05/2015 05:37 PM, David Daney wrote: This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. Let's skip this until you explain how to create a fully non-executable-stack process. Build almost any program with a gcc/glibc from a recent Cavium SDK toolchain. Something like this: mips64-octeon-linux-gnu-gcc -o myprogram myprogram.c You cannot change the default setting for executable stack just because you have created a broken userspace. Please give me at least one example, one existing application which would suffer. Anything compiled with gcj that uses java.lang.reflect.Method.invoke() Anything that uses gcc nested functions. Anything that uses libffi Where an older toolchain that doesn't set PT_GNU_STACK was used. I remember that people already wrote here that this kind of apps (which is based on eXecutable stack and doesn't announce it in PT_GNU_STACK) need to be eliminated. The ability of legacy userspace to continue functioning cannot be sacrificed. Not at any price. However, this switch is a separate patch from others. It can be not applied or it can be applied, depending from prevailing mind - what is more significant, some (unknown) app or non-executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:37 PM, David Daney wrote: This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. Let's skip this until you explain how to create a fully non-executable-stack process. GLIBC people is ready to do something but after we remove emulation from stack. You cannot change the default setting for executable stack just because you have created a broken userspace. Please give me at least one example, one existing application which would suffer. I remember that people already wrote here that this kind of apps (which is based on eXecutable stack and doesn't announce it in PT_GNU_STACK) need to be eliminated. The ability of legacy userspace to continue functioning cannot be sacrificed. Not at any price. However, this switch is a separate patch from others. It can be not applied or it can be applied, depending from prevailing mind - what is more significant, some (unknown) app or non-executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On Wed, Aug 05, 2015 at 05:23:55PM -0700, Leonid Yegoshin wrote: > It is actually any application which requests non-executable stack > protection and needs some emulation BEFORE GLIBC cancels that non-executable > stack protection due to libraries. > > If you build all libraries with PT_GNU_STACK 'non-executable' and use > application with the same protection then you can't emulate even a single > instruction - it crashes immediately. So, it is not a bad application, it is > a bad choice for emulation space in past. ...snip... > Create a buildroot FS with PT_GNU_STACK 'non-executable' libraries. Then run > ssh_keygen on CPU without FPU and look. > > You also may try to run MIPS R2 Debian on MIPS R6 CPU, and see a spectacular > failure of ssh_keygen (it tries to emulate MIPS R2 instruction before first > library is loaded and that fails due to non-executable stack protection. All of that sounds like perfectly valid reasons to move the FP branch delay emulation away from using the stack, which we absolutely do need to do. They do not however justify changing the default flags & breaking backwards compatibility. Thanks, Paul -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:23 PM, Leonid Yegoshin wrote: On 08/05/2015 05:14 PM, David Daney wrote: On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. The very first thing that is executed is ld.so, you need to make your ld.so do the right thing before transferring control to your program's entry point. You cannot change the default setting for executable stack just because you have created a broken userspace. The ability of legacy userspace to continue functioning cannot be sacrificed. David Daney -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:14 PM, David Daney wrote: On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. I have never had a problem running ssh_keygen (on platforms requiring emulation). Create a buildroot FS with PT_GNU_STACK 'non-executable' libraries. Then run ssh_keygen on CPU without FPU and look. You also may try to run MIPS R2 Debian on MIPS R6 CPU, and see a spectacular failure of ssh_keygen (it tries to emulate MIPS R2 instruction before first library is loaded and that fails due to non-executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. I have never had a problem running ssh_keygen (on platforms requiring emulation). - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 04:49 PM, Leonid Yegoshin wrote: This is a last step of 3 patches which shift FPU emulation out of stack into protected area. So, it disables a default executable stack. NAK. You cannot change the default. If you want a non-executable stack, the program has to request it with the proper annotations in its ELF file. David Daney. Additionally, it sets a default data area non-executable protection. Signed-off-by: Leonid Yegoshin --- arch/mips/include/asm/page.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h index 89dd7fed1a57..0b6cec4a1b80 100644 --- a/arch/mips/include/asm/page.h +++ b/arch/mips/include/asm/page.h @@ -228,7 +228,7 @@ extern int __virt_addr_valid(const volatile void *kaddr); #define virt_addr_valid(kaddr) \ __virt_addr_valid((const volatile void *) (kaddr)) -#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ +#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) #define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On Wed, Aug 05, 2015 at 04:49:36PM -0700, Leonid Yegoshin wrote: > This is a last step of 3 patches which shift FPU emulation out of > stack into protected area. So, it disables a default executable stack. > > Additionally, it sets a default data area non-executable protection. > > Signed-off-by: Leonid Yegoshin > --- > arch/mips/include/asm/page.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h > index 89dd7fed1a57..0b6cec4a1b80 100644 > --- a/arch/mips/include/asm/page.h > +++ b/arch/mips/include/asm/page.h > @@ -228,7 +228,7 @@ extern int __virt_addr_valid(const volatile void *kaddr); > #define virt_addr_valid(kaddr) > \ > __virt_addr_valid((const volatile void *) (kaddr)) > > -#define VM_DATA_DEFAULT_FLAGS(VM_READ | VM_WRITE | VM_EXEC | \ > +#define VM_DATA_DEFAULT_FLAGS(VM_READ | VM_WRITE | \ >VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) > > #define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) > Hi Leonid, As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. We should only be changing executability of memory in the presence of a PT_GNU_STACK header indicating that it's safe to do so, with cooperation from the toolchain team to begin emitting it for MIPS. See the way ARM did it, or the patches I've posted for this in the past. Thanks, Paul -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:46 PM, Leonid Yegoshin wrote: On 08/05/2015 05:37 PM, David Daney wrote: This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. Let's skip this until you explain how to create a fully non-executable-stack process. Build almost any program with a gcc/glibc from a recent Cavium SDK toolchain. Something like this: mips64-octeon-linux-gnu-gcc -o myprogram myprogram.c You cannot change the default setting for executable stack just because you have created a broken userspace. Please give me at least one example, one existing application which would suffer. Anything compiled with gcj that uses java.lang.reflect.Method.invoke() Anything that uses gcc nested functions. Anything that uses libffi Where an older toolchain that doesn't set PT_GNU_STACK was used. I remember that people already wrote here that this kind of apps (which is based on eXecutable stack and doesn't announce it in PT_GNU_STACK) need to be eliminated. The ability of legacy userspace to continue functioning cannot be sacrificed. Not at any price. However, this switch is a separate patch from others. It can be not applied or it can be applied, depending from prevailing mind - what is more significant, some (unknown) app or non-executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 04:49 PM, Leonid Yegoshin wrote: This is a last step of 3 patches which shift FPU emulation out of stack into protected area. So, it disables a default executable stack. NAK. You cannot change the default. If you want a non-executable stack, the program has to request it with the proper annotations in its ELF file. David Daney. Additionally, it sets a default data area non-executable protection. Signed-off-by: Leonid Yegoshin leonid.yegos...@imgtec.com --- arch/mips/include/asm/page.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h index 89dd7fed1a57..0b6cec4a1b80 100644 --- a/arch/mips/include/asm/page.h +++ b/arch/mips/include/asm/page.h @@ -228,7 +228,7 @@ extern int __virt_addr_valid(const volatile void *kaddr); #define virt_addr_valid(kaddr) \ __virt_addr_valid((const volatile void *) (kaddr)) -#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ +#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) #define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On Wed, Aug 05, 2015 at 04:49:36PM -0700, Leonid Yegoshin wrote: This is a last step of 3 patches which shift FPU emulation out of stack into protected area. So, it disables a default executable stack. Additionally, it sets a default data area non-executable protection. Signed-off-by: Leonid Yegoshin leonid.yegos...@imgtec.com --- arch/mips/include/asm/page.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h index 89dd7fed1a57..0b6cec4a1b80 100644 --- a/arch/mips/include/asm/page.h +++ b/arch/mips/include/asm/page.h @@ -228,7 +228,7 @@ extern int __virt_addr_valid(const volatile void *kaddr); #define virt_addr_valid(kaddr) \ __virt_addr_valid((const volatile void *) (kaddr)) -#define VM_DATA_DEFAULT_FLAGS(VM_READ | VM_WRITE | VM_EXEC | \ +#define VM_DATA_DEFAULT_FLAGS(VM_READ | VM_WRITE | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) #define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) Hi Leonid, As was pointed out last time you posted this, it breaks backwards compatibility with userland thus cannot be applied. We should only be changing executability of memory in the presence of a PT_GNU_STACK header indicating that it's safe to do so, with cooperation from the toolchain team to begin emitting it for MIPS. See the way ARM did it, or the patches I've posted for this in the past. Thanks, Paul -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. I have never had a problem running ssh_keygen (on platforms requiring emulation). - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:14 PM, David Daney wrote: On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. I have never had a problem running ssh_keygen (on platforms requiring emulation). Create a buildroot FS with PT_GNU_STACK 'non-executable' libraries. Then run ssh_keygen on CPU without FPU and look. You also may try to run MIPS R2 Debian on MIPS R6 CPU, and see a spectacular failure of ssh_keygen (it tries to emulate MIPS R2 instruction before first library is loaded and that fails due to non-executable stack protection. - Leonid. -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:23 PM, Leonid Yegoshin wrote: On 08/05/2015 05:14 PM, David Daney wrote: On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. The very first thing that is executed is ld.so, you need to make your ld.so do the right thing before transferring control to your program's entry point. You cannot change the default setting for executable stack just because you have created a broken userspace. The ability of legacy userspace to continue functioning cannot be sacrificed. David Daney -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On Wed, Aug 05, 2015 at 05:23:55PM -0700, Leonid Yegoshin wrote: It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. ...snip... Create a buildroot FS with PT_GNU_STACK 'non-executable' libraries. Then run ssh_keygen on CPU without FPU and look. You also may try to run MIPS R2 Debian on MIPS R6 CPU, and see a spectacular failure of ssh_keygen (it tries to emulate MIPS R2 instruction before first library is loaded and that fails due to non-executable stack protection. All of that sounds like perfectly valid reasons to move the FP branch delay emulation away from using the stack, which we absolutely do need to do. They do not however justify changing the default flags breaking backwards compatibility. Thanks, Paul -- 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 v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:37 PM, David Daney wrote: This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. Let's skip this until you explain how to create a fully non-executable-stack process. GLIBC people is ready to do something but after we remove emulation from stack. You cannot change the default setting for executable stack just because you have created a broken userspace. Please give me at least one example, one existing application which would suffer. I remember that people already wrote here that this kind of apps (which is based on eXecutable stack and doesn't announce it in PT_GNU_STACK) need to be eliminated. The ability of legacy userspace to continue functioning cannot be sacrificed. Not at any price. However, this switch is a separate patch from others. It can be not applied or it can be applied, depending from prevailing mind - what is more significant, some (unknown) app or non-executable stack protection. - Leonid. -- 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/
