Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
On Fri, Dec 5, 2014 at 3:13 AM, Chuck Ebbert wrote: > Should the completely pointless supervisor_stack[] be removed as well? > I had a patch to do that but I never sent it. Might as well. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Fri, Dec 5, 2014 at 3:13 AM, Chuck Ebbert cebbert.l...@gmail.com wrote: Should the completely pointless supervisor_stack[] be removed as well? I had a patch to do that but I never sent it. Might as well. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
Should the completely pointless supervisor_stack[] be removed as well? I had a patch to do that but I never sent 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/
Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
Should the completely pointless supervisor_stack[] be removed as well? I had a patch to do that but I never sent 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/
Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
On Wed, Dec 3, 2014 at 3:53 PM, Andrew Morton wrote: > On Wed, 3 Dec 2014 15:38:29 -0800 Andy Lutomirski wrote: > >> Yes, exactly. >> >> > >> > Spelling this out in the changelog would be useful for the ignorant and >> > the forgetful ;) >> >> Want a new version, or will you fix it up yourself? >> > > I think I can work that out. > > A couple of linux-next things to check: > > - arch/arm/include/asm/thread_info.h:arm_restart_block has > disappeared from the thread_info. > > - the reference to ti->restart_block in arch/arm/kernel/traps.c has > vanished. I couldn't find anywhere where it was moved to. This looks like it's: commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 Author: Vladimir Murzin Date: Thu Nov 27 11:39:04 2014 +0100 ARM: 8226/1: cacheflush: get rid of restarting block We cannot restart cacheflush safely if a process provides user-defined signal handler and signal is pending. In this case -EINTR is returned and it is expected that process re-invokes syscall. However, there are a few problems with that: * looks like nobody bothers checking return value from cacheflush * but if it did, we don't provide the restart address for that, so the process has to use the same range again * ...and again, what might lead to looping forever So, remove cacheflush restarting code and terminate cache flushing as early as fatal signal is pending. If you haven't already done the obvious fixup (just drop the offending hunk), I can send a new version. -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Wed, 3 Dec 2014 15:38:29 -0800 Andy Lutomirski wrote: > Yes, exactly. > > > > > Spelling this out in the changelog would be useful for the ignorant and > > the forgetful ;) > > Want a new version, or will you fix it up yourself? > I think I can work that out. A couple of linux-next things to check: - arch/arm/include/asm/thread_info.h:arm_restart_block has disappeared from the thread_info. - the reference to ti->restart_block in arch/arm/kernel/traps.c has vanished. I couldn't find anywhere where it was moved to. -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Wed, Dec 3, 2014 at 3:37 PM, Andrew Morton wrote: > On Mon, 1 Dec 2014 06:55:01 -0800 Andy Lutomirski wrote: > >> On Tue, Nov 11, 2014 at 2:52 AM, Richard Weinberger wrote: >> > Am 11.11.2014 um 03:13 schrieb David Miller: >> >> From: Andy Lutomirski >> >> Date: Mon, 10 Nov 2014 14:03:23 -0800 >> >> >> >>> On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner >> >>> wrote: >> On Wed, 29 Oct 2014, Andy Lutomirski wrote: >> >> > If an attacker can cause a controlled kernel stack overflow, >> > overwriting the restart block is a very juicy exploit target. >> > Moving the restart block to struct task_struct prevents this >> > exploit. >> > >> > Note that there are other fields in thread_info that are also easy >> > targets, at least on some architectures. >> > >> > It's also a decent simplification, since the restart code is more or >> > less identical on all architectures. >> >> I think that's the most important change. Moving common stuff into >> common code. The side effect of slightly reducing the attack surface >> is nice, but as Al pointed out not really the big win here. >> >>> >> >>> Having gotten exactly zero feedback from any arch maintainer outside >> >>> of x86, am I supposed to pester people further? >> >> >> >> No objections wrt. sparc and if things break I'll help fix it. >> > >> > Same for UML. >> > Acked-by: Richard Weinberger >> >> akpm, do you consider this appropriate for either 3.19 or 3.20? If >> so, can you add it to the appropriate part of -mm? > > Yes, I can grab it. Probably for .20, as the lag times for exposing > issues in obscures architectures are lengthy. > > One clarification: > > : If an attacker can cause a controlled kernel stack overflow, > : overwriting the restart block is a very juicy exploit target. > > This is because the thread_info actually resides in the memory which > was allocated for the kernel stack, yes? Whereas the task_struct is > separately allocated and is harder to find? Yes, exactly. > > Spelling this out in the changelog would be useful for the ignorant and > the forgetful ;) Want a new version, or will you fix it up yourself? Thanks, Andy > > : Moving the restart block to struct task_struct prevents this > : exploit. > > -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Mon, 1 Dec 2014 06:55:01 -0800 Andy Lutomirski wrote: > On Tue, Nov 11, 2014 at 2:52 AM, Richard Weinberger wrote: > > Am 11.11.2014 um 03:13 schrieb David Miller: > >> From: Andy Lutomirski > >> Date: Mon, 10 Nov 2014 14:03:23 -0800 > >> > >>> On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner > >>> wrote: > On Wed, 29 Oct 2014, Andy Lutomirski wrote: > > > If an attacker can cause a controlled kernel stack overflow, > > overwriting the restart block is a very juicy exploit target. > > Moving the restart block to struct task_struct prevents this > > exploit. > > > > Note that there are other fields in thread_info that are also easy > > targets, at least on some architectures. > > > > It's also a decent simplification, since the restart code is more or > > less identical on all architectures. > > I think that's the most important change. Moving common stuff into > common code. The side effect of slightly reducing the attack surface > is nice, but as Al pointed out not really the big win here. > >>> > >>> Having gotten exactly zero feedback from any arch maintainer outside > >>> of x86, am I supposed to pester people further? > >> > >> No objections wrt. sparc and if things break I'll help fix it. > > > > Same for UML. > > Acked-by: Richard Weinberger > > akpm, do you consider this appropriate for either 3.19 or 3.20? If > so, can you add it to the appropriate part of -mm? Yes, I can grab it. Probably for .20, as the lag times for exposing issues in obscures architectures are lengthy. One clarification: : If an attacker can cause a controlled kernel stack overflow, : overwriting the restart block is a very juicy exploit target. This is because the thread_info actually resides in the memory which was allocated for the kernel stack, yes? Whereas the task_struct is separately allocated and is harder to find? Spelling this out in the changelog would be useful for the ignorant and the forgetful ;) : Moving the restart block to struct task_struct prevents this : exploit. -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Mon, 1 Dec 2014 06:55:01 -0800 Andy Lutomirski l...@amacapital.net wrote: On Tue, Nov 11, 2014 at 2:52 AM, Richard Weinberger rich...@nod.at wrote: Am 11.11.2014 um 03:13 schrieb David Miller: From: Andy Lutomirski l...@amacapital.net Date: Mon, 10 Nov 2014 14:03:23 -0800 On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? No objections wrt. sparc and if things break I'll help fix it. Same for UML. Acked-by: Richard Weinberger rich...@nod.at akpm, do you consider this appropriate for either 3.19 or 3.20? If so, can you add it to the appropriate part of -mm? Yes, I can grab it. Probably for .20, as the lag times for exposing issues in obscures architectures are lengthy. One clarification: : If an attacker can cause a controlled kernel stack overflow, : overwriting the restart block is a very juicy exploit target. This is because the thread_info actually resides in the memory which was allocated for the kernel stack, yes? Whereas the task_struct is separately allocated and is harder to find? Spelling this out in the changelog would be useful for the ignorant and the forgetful ;) : Moving the restart block to struct task_struct prevents this : exploit. -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Wed, Dec 3, 2014 at 3:37 PM, Andrew Morton a...@linux-foundation.org wrote: On Mon, 1 Dec 2014 06:55:01 -0800 Andy Lutomirski l...@amacapital.net wrote: On Tue, Nov 11, 2014 at 2:52 AM, Richard Weinberger rich...@nod.at wrote: Am 11.11.2014 um 03:13 schrieb David Miller: From: Andy Lutomirski l...@amacapital.net Date: Mon, 10 Nov 2014 14:03:23 -0800 On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? No objections wrt. sparc and if things break I'll help fix it. Same for UML. Acked-by: Richard Weinberger rich...@nod.at akpm, do you consider this appropriate for either 3.19 or 3.20? If so, can you add it to the appropriate part of -mm? Yes, I can grab it. Probably for .20, as the lag times for exposing issues in obscures architectures are lengthy. One clarification: : If an attacker can cause a controlled kernel stack overflow, : overwriting the restart block is a very juicy exploit target. This is because the thread_info actually resides in the memory which was allocated for the kernel stack, yes? Whereas the task_struct is separately allocated and is harder to find? Yes, exactly. Spelling this out in the changelog would be useful for the ignorant and the forgetful ;) Want a new version, or will you fix it up yourself? Thanks, Andy : Moving the restart block to struct task_struct prevents this : exploit. -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Wed, 3 Dec 2014 15:38:29 -0800 Andy Lutomirski l...@amacapital.net wrote: Yes, exactly. Spelling this out in the changelog would be useful for the ignorant and the forgetful ;) Want a new version, or will you fix it up yourself? I think I can work that out. A couple of linux-next things to check: - arch/arm/include/asm/thread_info.h:arm_restart_block has disappeared from the thread_info. - the reference to ti-restart_block in arch/arm/kernel/traps.c has vanished. I couldn't find anywhere where it was moved to. -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Wed, Dec 3, 2014 at 3:53 PM, Andrew Morton a...@linux-foundation.org wrote: On Wed, 3 Dec 2014 15:38:29 -0800 Andy Lutomirski l...@amacapital.net wrote: Yes, exactly. Spelling this out in the changelog would be useful for the ignorant and the forgetful ;) Want a new version, or will you fix it up yourself? I think I can work that out. A couple of linux-next things to check: - arch/arm/include/asm/thread_info.h:arm_restart_block has disappeared from the thread_info. - the reference to ti-restart_block in arch/arm/kernel/traps.c has vanished. I couldn't find anywhere where it was moved to. This looks like it's: commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 Author: Vladimir Murzin vladimir.mur...@arm.com Date: Thu Nov 27 11:39:04 2014 +0100 ARM: 8226/1: cacheflush: get rid of restarting block We cannot restart cacheflush safely if a process provides user-defined signal handler and signal is pending. In this case -EINTR is returned and it is expected that process re-invokes syscall. However, there are a few problems with that: * looks like nobody bothers checking return value from cacheflush * but if it did, we don't provide the restart address for that, so the process has to use the same range again * ...and again, what might lead to looping forever So, remove cacheflush restarting code and terminate cache flushing as early as fatal signal is pending. If you haven't already done the obvious fixup (just drop the offending hunk), I can send a new version. -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Tue, Nov 11, 2014 at 2:52 AM, Richard Weinberger wrote: > Am 11.11.2014 um 03:13 schrieb David Miller: >> From: Andy Lutomirski >> Date: Mon, 10 Nov 2014 14:03:23 -0800 >> >>> On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner >>> wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: > If an attacker can cause a controlled kernel stack overflow, > overwriting the restart block is a very juicy exploit target. > Moving the restart block to struct task_struct prevents this > exploit. > > Note that there are other fields in thread_info that are also easy > targets, at least on some architectures. > > It's also a decent simplification, since the restart code is more or > less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. >>> >>> Having gotten exactly zero feedback from any arch maintainer outside >>> of x86, am I supposed to pester people further? >> >> No objections wrt. sparc and if things break I'll help fix it. > > Same for UML. > Acked-by: Richard Weinberger akpm, do you consider this appropriate for either 3.19 or 3.20? If so, can you add it to the appropriate part of -mm? Thanks, Andy -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Tue, Nov 11, 2014 at 2:52 AM, Richard Weinberger rich...@nod.at wrote: Am 11.11.2014 um 03:13 schrieb David Miller: From: Andy Lutomirski l...@amacapital.net Date: Mon, 10 Nov 2014 14:03:23 -0800 On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? No objections wrt. sparc and if things break I'll help fix it. Same for UML. Acked-by: Richard Weinberger rich...@nod.at akpm, do you consider this appropriate for either 3.19 or 3.20? If so, can you add it to the appropriate part of -mm? Thanks, Andy -- 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 v2] all arches, signal: Move restart_block to struct task_struct
Am 11.11.2014 um 03:13 schrieb David Miller: > From: Andy Lutomirski > Date: Mon, 10 Nov 2014 14:03:23 -0800 > >> On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner wrote: >>> On Wed, 29 Oct 2014, Andy Lutomirski wrote: >>> If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. >>> >>> I think that's the most important change. Moving common stuff into >>> common code. The side effect of slightly reducing the attack surface >>> is nice, but as Al pointed out not really the big win here. >> >> Having gotten exactly zero feedback from any arch maintainer outside >> of x86, am I supposed to pester people further? > > No objections wrt. sparc and if things break I'll help fix it. Same for UML. Acked-by: Richard Weinberger Thanks, //richard -- 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 v2] all arches, signal: Move restart_block to struct task_struct
Am 11.11.2014 um 03:13 schrieb David Miller: From: Andy Lutomirski l...@amacapital.net Date: Mon, 10 Nov 2014 14:03:23 -0800 On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? No objections wrt. sparc and if things break I'll help fix it. Same for UML. Acked-by: Richard Weinberger rich...@nod.at Thanks, //richard -- 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 v2] all arches, signal: Move restart_block to struct task_struct
From: Andy Lutomirski Date: Mon, 10 Nov 2014 14:03:23 -0800 > On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner wrote: >> On Wed, 29 Oct 2014, Andy Lutomirski wrote: >> >>> If an attacker can cause a controlled kernel stack overflow, >>> overwriting the restart block is a very juicy exploit target. >>> Moving the restart block to struct task_struct prevents this >>> exploit. >>> >>> Note that there are other fields in thread_info that are also easy >>> targets, at least on some architectures. >>> >>> It's also a decent simplification, since the restart code is more or >>> less identical on all architectures. >> >> I think that's the most important change. Moving common stuff into >> common code. The side effect of slightly reducing the attack surface >> is nice, but as Al pointed out not really the big win here. > > Having gotten exactly zero feedback from any arch maintainer outside > of x86, am I supposed to pester people further? No objections wrt. sparc and if things break I'll help fix 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/
Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner wrote: > On Wed, 29 Oct 2014, Andy Lutomirski wrote: > >> If an attacker can cause a controlled kernel stack overflow, >> overwriting the restart block is a very juicy exploit target. >> Moving the restart block to struct task_struct prevents this >> exploit. >> >> Note that there are other fields in thread_info that are also easy >> targets, at least on some architectures. >> >> It's also a decent simplification, since the restart code is more or >> less identical on all architectures. > > I think that's the most important change. Moving common stuff into > common code. The side effect of slightly reducing the attack surface > is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? --Andy > > Thanks, > > tglx -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? --Andy Thanks, tglx -- Andy Lutomirski AMA Capital Management, LLC -- 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 v2] all arches, signal: Move restart_block to struct task_struct
From: Andy Lutomirski l...@amacapital.net Date: Mon, 10 Nov 2014 14:03:23 -0800 On Wed, Oct 29, 2014 at 11:12 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Having gotten exactly zero feedback from any arch maintainer outside of x86, am I supposed to pester people further? No objections wrt. sparc and if things break I'll help fix 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/
Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
On Wed, 29 Oct 2014, Andy Lutomirski wrote: > If an attacker can cause a controlled kernel stack overflow, > overwriting the restart block is a very juicy exploit target. > Moving the restart block to struct task_struct prevents this > exploit. > > Note that there are other fields in thread_info that are also easy > targets, at least on some architectures. > > It's also a decent simplification, since the restart code is more or > less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Thanks, tglx -- 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/
[PATCH v2] all arches, signal: Move restart_block to struct task_struct
If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. Signed-off-by: Andy Lutomirski --- Changes from v1: - Fixed sparc issues and similar issues on other architectures, I think. (Sam Ravnborg) - Improved changelog message (hopefully addressing Al Viro's concerns) arch/alpha/include/asm/thread_info.h | 5 - arch/alpha/kernel/signal.c| 2 +- arch/arc/include/asm/thread_info.h| 4 arch/arc/kernel/signal.c | 2 +- arch/arm/include/asm/thread_info.h| 4 arch/arm/kernel/signal.c | 4 ++-- arch/arm/kernel/traps.c | 2 +- arch/arm64/include/asm/thread_info.h | 4 arch/arm64/kernel/signal.c| 2 +- arch/arm64/kernel/signal32.c | 4 ++-- arch/avr32/include/asm/thread_info.h | 4 arch/avr32/kernel/asm-offsets.c | 1 - arch/avr32/kernel/signal.c| 2 +- arch/blackfin/include/asm/thread_info.h | 4 arch/blackfin/kernel/signal.c | 2 +- arch/c6x/include/asm/thread_info.h| 4 arch/c6x/kernel/signal.c | 2 +- arch/cris/arch-v10/kernel/signal.c| 2 +- arch/cris/arch-v32/kernel/signal.c| 2 +- arch/cris/include/asm/thread_info.h | 4 arch/frv/include/asm/thread_info.h| 4 arch/frv/kernel/asm-offsets.c | 1 - arch/frv/kernel/signal.c | 2 +- arch/hexagon/include/asm/thread_info.h| 4 arch/hexagon/kernel/signal.c | 2 +- arch/ia64/include/asm/thread_info.h | 4 arch/ia64/kernel/signal.c | 2 +- arch/m32r/include/asm/thread_info.h | 5 - arch/m32r/kernel/signal.c | 2 +- arch/m68k/include/asm/thread_info.h | 4 arch/m68k/kernel/signal.c | 4 ++-- arch/metag/include/asm/thread_info.h | 4 arch/metag/kernel/signal.c| 2 +- arch/microblaze/include/asm/thread_info.h | 4 arch/microblaze/kernel/signal.c | 2 +- arch/mips/include/asm/thread_info.h | 4 arch/mips/kernel/asm-offsets.c| 1 - arch/mips/kernel/signal.c | 2 +- arch/mips/kernel/signal32.c | 2 +- arch/mn10300/include/asm/thread_info.h| 4 arch/mn10300/kernel/asm-offsets.c | 1 - arch/mn10300/kernel/signal.c | 2 +- arch/openrisc/include/asm/thread_info.h | 4 arch/openrisc/kernel/signal.c | 2 +- arch/parisc/include/asm/thread_info.h | 4 arch/parisc/kernel/signal.c | 2 +- arch/powerpc/include/asm/thread_info.h| 4 arch/powerpc/kernel/signal_32.c | 4 ++-- arch/powerpc/kernel/signal_64.c | 2 +- arch/s390/include/asm/thread_info.h | 4 arch/s390/kernel/compat_signal.c | 2 +- arch/s390/kernel/signal.c | 2 +- arch/score/include/asm/thread_info.h | 4 arch/score/kernel/asm-offsets.c | 1 - arch/score/kernel/signal.c| 2 +- arch/sh/include/asm/thread_info.h | 4 arch/sh/kernel/asm-offsets.c | 1 - arch/sh/kernel/signal_32.c| 4 ++-- arch/sh/kernel/signal_64.c| 4 ++-- arch/sparc/include/asm/thread_info_32.h | 6 -- arch/sparc/include/asm/thread_info_64.h | 12 +++- arch/sparc/kernel/signal32.c | 4 ++-- arch/sparc/kernel/signal_32.c | 2 +- arch/sparc/kernel/signal_64.c | 2 +- arch/sparc/kernel/traps_64.c | 2 -- arch/tile/include/asm/thread_info.h | 4 arch/tile/kernel/signal.c | 2 +- arch/um/include/asm/thread_info.h | 4 arch/unicore32/include/asm/thread_info.h | 4 arch/unicore32/kernel/signal.c| 2 +- arch/x86/ia32/ia32_signal.c | 2 +- arch/x86/include/asm/thread_info.h| 4 arch/x86/kernel/signal.c | 2 +- arch/x86/um/signal.c | 2 +- arch/xtensa/include/asm/thread_info.h | 5 - arch/xtensa/kernel/signal.c | 2 +- fs/select.c | 2 +- include/linux/init_task.h | 3 +++ include/linux/sched.h | 2 ++ kernel/compat.c | 5 ++--- kernel/futex.c| 2 +- kernel/signal.c | 2 +- kernel/time/alarmtimer.c | 2 +- kernel/time/hrtimer.c | 2 +-
[PATCH v2] all arches, signal: Move restart_block to struct task_struct
If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. Signed-off-by: Andy Lutomirski l...@amacapital.net --- Changes from v1: - Fixed sparc issues and similar issues on other architectures, I think. (Sam Ravnborg) - Improved changelog message (hopefully addressing Al Viro's concerns) arch/alpha/include/asm/thread_info.h | 5 - arch/alpha/kernel/signal.c| 2 +- arch/arc/include/asm/thread_info.h| 4 arch/arc/kernel/signal.c | 2 +- arch/arm/include/asm/thread_info.h| 4 arch/arm/kernel/signal.c | 4 ++-- arch/arm/kernel/traps.c | 2 +- arch/arm64/include/asm/thread_info.h | 4 arch/arm64/kernel/signal.c| 2 +- arch/arm64/kernel/signal32.c | 4 ++-- arch/avr32/include/asm/thread_info.h | 4 arch/avr32/kernel/asm-offsets.c | 1 - arch/avr32/kernel/signal.c| 2 +- arch/blackfin/include/asm/thread_info.h | 4 arch/blackfin/kernel/signal.c | 2 +- arch/c6x/include/asm/thread_info.h| 4 arch/c6x/kernel/signal.c | 2 +- arch/cris/arch-v10/kernel/signal.c| 2 +- arch/cris/arch-v32/kernel/signal.c| 2 +- arch/cris/include/asm/thread_info.h | 4 arch/frv/include/asm/thread_info.h| 4 arch/frv/kernel/asm-offsets.c | 1 - arch/frv/kernel/signal.c | 2 +- arch/hexagon/include/asm/thread_info.h| 4 arch/hexagon/kernel/signal.c | 2 +- arch/ia64/include/asm/thread_info.h | 4 arch/ia64/kernel/signal.c | 2 +- arch/m32r/include/asm/thread_info.h | 5 - arch/m32r/kernel/signal.c | 2 +- arch/m68k/include/asm/thread_info.h | 4 arch/m68k/kernel/signal.c | 4 ++-- arch/metag/include/asm/thread_info.h | 4 arch/metag/kernel/signal.c| 2 +- arch/microblaze/include/asm/thread_info.h | 4 arch/microblaze/kernel/signal.c | 2 +- arch/mips/include/asm/thread_info.h | 4 arch/mips/kernel/asm-offsets.c| 1 - arch/mips/kernel/signal.c | 2 +- arch/mips/kernel/signal32.c | 2 +- arch/mn10300/include/asm/thread_info.h| 4 arch/mn10300/kernel/asm-offsets.c | 1 - arch/mn10300/kernel/signal.c | 2 +- arch/openrisc/include/asm/thread_info.h | 4 arch/openrisc/kernel/signal.c | 2 +- arch/parisc/include/asm/thread_info.h | 4 arch/parisc/kernel/signal.c | 2 +- arch/powerpc/include/asm/thread_info.h| 4 arch/powerpc/kernel/signal_32.c | 4 ++-- arch/powerpc/kernel/signal_64.c | 2 +- arch/s390/include/asm/thread_info.h | 4 arch/s390/kernel/compat_signal.c | 2 +- arch/s390/kernel/signal.c | 2 +- arch/score/include/asm/thread_info.h | 4 arch/score/kernel/asm-offsets.c | 1 - arch/score/kernel/signal.c| 2 +- arch/sh/include/asm/thread_info.h | 4 arch/sh/kernel/asm-offsets.c | 1 - arch/sh/kernel/signal_32.c| 4 ++-- arch/sh/kernel/signal_64.c| 4 ++-- arch/sparc/include/asm/thread_info_32.h | 6 -- arch/sparc/include/asm/thread_info_64.h | 12 +++- arch/sparc/kernel/signal32.c | 4 ++-- arch/sparc/kernel/signal_32.c | 2 +- arch/sparc/kernel/signal_64.c | 2 +- arch/sparc/kernel/traps_64.c | 2 -- arch/tile/include/asm/thread_info.h | 4 arch/tile/kernel/signal.c | 2 +- arch/um/include/asm/thread_info.h | 4 arch/unicore32/include/asm/thread_info.h | 4 arch/unicore32/kernel/signal.c| 2 +- arch/x86/ia32/ia32_signal.c | 2 +- arch/x86/include/asm/thread_info.h| 4 arch/x86/kernel/signal.c | 2 +- arch/x86/um/signal.c | 2 +- arch/xtensa/include/asm/thread_info.h | 5 - arch/xtensa/kernel/signal.c | 2 +- fs/select.c | 2 +- include/linux/init_task.h | 3 +++ include/linux/sched.h | 2 ++ kernel/compat.c | 5 ++--- kernel/futex.c| 2 +- kernel/signal.c | 2 +- kernel/time/alarmtimer.c | 2 +- kernel/time/hrtimer.c
Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
On Wed, 29 Oct 2014, Andy Lutomirski wrote: If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. Moving the restart block to struct task_struct prevents this exploit. Note that there are other fields in thread_info that are also easy targets, at least on some architectures. It's also a decent simplification, since the restart code is more or less identical on all architectures. I think that's the most important change. Moving common stuff into common code. The side effect of slightly reducing the attack surface is nice, but as Al pointed out not really the big win here. Thanks, tglx -- 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/
