Re: Pondering per-process vsyscall disablement
On Fri, May 30, 2014 at 1:20 PM, H. Peter Anvin wrote: > On 05/30/2014 01:11 PM, Andy Lutomirski wrote: >> On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin wrote: >>> On 05/30/2014 01:00 PM, Andy Lutomirski wrote: Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. >>> >>> They go into each object which becomes part of the running program, i.e. >>> executable, dynamic libraries, and dynamic linker. >> >> Well, sure, but the kernel is not about to start reading ELF headers >> in dynamic libraries. So we need to make a decision based on the >> interpreter and the executable. The conservative approach is to >> require both to have the flag set *and* to offer a prctl to twiddle >> the flags. Then userspace loaders can do whatever they want, and >> distros get to rebuild the world :) >> > > Yes, something like that. I'll hack something up once the merge window closes. Or maybe sooner if you commit my vsyscall patches from a few days ago. Otherwise I'm just going to confuse my git tree too much :) --Andy > > -hpa > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Pondering per-process vsyscall disablement
On 05/30/2014 01:11 PM, Andy Lutomirski wrote: > On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin wrote: >> On 05/30/2014 01:00 PM, Andy Lutomirski wrote: >>> >>> Do the flags go in the ELF loader or in the executable we're running? >>> Or both (and, if both, do we and them or or them)? >>> >>> I think the interpreter makes a little more sense in general: for the >>> most part, use of vsyscalls is a property of the runtime environment, >>> not of the program being run. But maybe this is naive. >>> >> >> They go into each object which becomes part of the running program, i.e. >> executable, dynamic libraries, and dynamic linker. > > Well, sure, but the kernel is not about to start reading ELF headers > in dynamic libraries. So we need to make a decision based on the > interpreter and the executable. The conservative approach is to > require both to have the flag set *and* to offer a prctl to twiddle > the flags. Then userspace loaders can do whatever they want, and > distros get to rebuild the world :) > Yes, something like that. -hpa -- 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: Pondering per-process vsyscall disablement
On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin wrote: > On 05/30/2014 01:00 PM, Andy Lutomirski wrote: >> >> Do the flags go in the ELF loader or in the executable we're running? >> Or both (and, if both, do we and them or or them)? >> >> I think the interpreter makes a little more sense in general: for the >> most part, use of vsyscalls is a property of the runtime environment, >> not of the program being run. But maybe this is naive. >> > > They go into each object which becomes part of the running program, i.e. > executable, dynamic libraries, and dynamic linker. Well, sure, but the kernel is not about to start reading ELF headers in dynamic libraries. So we need to make a decision based on the interpreter and the executable. The conservative approach is to require both to have the flag set *and* to offer a prctl to twiddle the flags. Then userspace loaders can do whatever they want, and distros get to rebuild the world :) --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: Pondering per-process vsyscall disablement
On 05/30/2014 01:00 PM, Andy Lutomirski wrote: > > Do the flags go in the ELF loader or in the executable we're running? > Or both (and, if both, do we and them or or them)? > > I think the interpreter makes a little more sense in general: for the > most part, use of vsyscalls is a property of the runtime environment, > not of the program being run. But maybe this is naive. > They go into each object which becomes part of the running program, i.e. executable, dynamic libraries, and dynamic linker. -hpa -- 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: Pondering per-process vsyscall disablement
On Wed, May 28, 2014 at 2:45 PM, H. Peter Anvin wrote: > On 05/23/2014 09:40 AM, Andy Lutomirski wrote: >> >> I don't think this should be something configured by the >> administrator, unless the administrator is the builder of a kiosky >> thing like Chromium OS. In that case, the administrator can use >> vsyscall=none. >> >> I think this should be handled by either libc or the toolchain, hence >> the suggestions of a syscall or an ELF header. >> > > We could mimic the NX stack stuff, but it would have a lot of false > negatives, simply because very few things would actually poke at the > vsyscall page. > > The NX stuff uses a dummy program header in the ELF image. > > On the other hand, you could make the argument that anything compiled > with a new toolchain simply should not use the vsyscall page, and just > unconditionally set the opt-out bit (header) in question. > > It might be better to have some kind of flags field (which a number of > architectures use) than keep using dummy program headers, though. Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. --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: Pondering per-process vsyscall disablement
On Wed, May 28, 2014 at 2:45 PM, H. Peter Anvin h...@zytor.com wrote: On 05/23/2014 09:40 AM, Andy Lutomirski wrote: I don't think this should be something configured by the administrator, unless the administrator is the builder of a kiosky thing like Chromium OS. In that case, the administrator can use vsyscall=none. I think this should be handled by either libc or the toolchain, hence the suggestions of a syscall or an ELF header. We could mimic the NX stack stuff, but it would have a lot of false negatives, simply because very few things would actually poke at the vsyscall page. The NX stuff uses a dummy program header in the ELF image. On the other hand, you could make the argument that anything compiled with a new toolchain simply should not use the vsyscall page, and just unconditionally set the opt-out bit (header) in question. It might be better to have some kind of flags field (which a number of architectures use) than keep using dummy program headers, though. Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. --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: Pondering per-process vsyscall disablement
On 05/30/2014 01:00 PM, Andy Lutomirski wrote: Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. They go into each object which becomes part of the running program, i.e. executable, dynamic libraries, and dynamic linker. -hpa -- 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: Pondering per-process vsyscall disablement
On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin h...@zytor.com wrote: On 05/30/2014 01:00 PM, Andy Lutomirski wrote: Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. They go into each object which becomes part of the running program, i.e. executable, dynamic libraries, and dynamic linker. Well, sure, but the kernel is not about to start reading ELF headers in dynamic libraries. So we need to make a decision based on the interpreter and the executable. The conservative approach is to require both to have the flag set *and* to offer a prctl to twiddle the flags. Then userspace loaders can do whatever they want, and distros get to rebuild the world :) --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: Pondering per-process vsyscall disablement
On 05/30/2014 01:11 PM, Andy Lutomirski wrote: On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin h...@zytor.com wrote: On 05/30/2014 01:00 PM, Andy Lutomirski wrote: Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. They go into each object which becomes part of the running program, i.e. executable, dynamic libraries, and dynamic linker. Well, sure, but the kernel is not about to start reading ELF headers in dynamic libraries. So we need to make a decision based on the interpreter and the executable. The conservative approach is to require both to have the flag set *and* to offer a prctl to twiddle the flags. Then userspace loaders can do whatever they want, and distros get to rebuild the world :) Yes, something like that. -hpa -- 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: Pondering per-process vsyscall disablement
On Fri, May 30, 2014 at 1:20 PM, H. Peter Anvin h...@zytor.com wrote: On 05/30/2014 01:11 PM, Andy Lutomirski wrote: On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin h...@zytor.com wrote: On 05/30/2014 01:00 PM, Andy Lutomirski wrote: Do the flags go in the ELF loader or in the executable we're running? Or both (and, if both, do we and them or or them)? I think the interpreter makes a little more sense in general: for the most part, use of vsyscalls is a property of the runtime environment, not of the program being run. But maybe this is naive. They go into each object which becomes part of the running program, i.e. executable, dynamic libraries, and dynamic linker. Well, sure, but the kernel is not about to start reading ELF headers in dynamic libraries. So we need to make a decision based on the interpreter and the executable. The conservative approach is to require both to have the flag set *and* to offer a prctl to twiddle the flags. Then userspace loaders can do whatever they want, and distros get to rebuild the world :) Yes, something like that. I'll hack something up once the merge window closes. Or maybe sooner if you commit my vsyscall patches from a few days ago. Otherwise I'm just going to confuse my git tree too much :) --Andy -hpa -- To unsubscribe from this list: send the line unsubscribe linux-api in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Pondering per-process vsyscall disablement
On 05/23/2014 09:40 AM, Andy Lutomirski wrote: > > I don't think this should be something configured by the > administrator, unless the administrator is the builder of a kiosky > thing like Chromium OS. In that case, the administrator can use > vsyscall=none. > > I think this should be handled by either libc or the toolchain, hence > the suggestions of a syscall or an ELF header. > We could mimic the NX stack stuff, but it would have a lot of false negatives, simply because very few things would actually poke at the vsyscall page. The NX stuff uses a dummy program header in the ELF image. On the other hand, you could make the argument that anything compiled with a new toolchain simply should not use the vsyscall page, and just unconditionally set the opt-out bit (header) in question. It might be better to have some kind of flags field (which a number of architectures use) than keep using dummy program headers, though. -hpa -- 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: Pondering per-process vsyscall disablement
On 05/23/2014 09:40 AM, Andy Lutomirski wrote: I don't think this should be something configured by the administrator, unless the administrator is the builder of a kiosky thing like Chromium OS. In that case, the administrator can use vsyscall=none. I think this should be handled by either libc or the toolchain, hence the suggestions of a syscall or an ELF header. We could mimic the NX stack stuff, but it would have a lot of false negatives, simply because very few things would actually poke at the vsyscall page. The NX stuff uses a dummy program header in the ELF image. On the other hand, you could make the argument that anything compiled with a new toolchain simply should not use the vsyscall page, and just unconditionally set the opt-out bit (header) in question. It might be better to have some kind of flags field (which a number of architectures use) than keep using dummy program headers, though. -hpa -- 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: Pondering per-process vsyscall disablement
On Thu, May 22, 2014 at 7:44 PM, Marian Marinov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/23/2014 02:04 AM, Andy Lutomirski wrote: >> It would be nice to have a way for new programs to declare that they don't >> need vsyscalls. What's the right way to >> do this? An ELF header entry in the loader? An ELF header entry in the >> program? A new arch_prctl? >> >> As background, there's an old part of the x86_64 ABI that allows programs to >> do gettimeofday, clock_gettime, and >> getcpu by calling to fixed addresses of the form 0xff600n00 where n >> indicates which of those three syscalls >> is being invoked. This is a security issue. >> >> Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a >> result, vsyscalls no longer offer any >> performance advantage over normal syscalls; in fact, they're much slower. >> As far as I know, nothing newer than >> 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of >> things will still fall back to the >> vsyscall page if there is no vdso, but that shouldn't matter, since there is >> always a vdso.) >> >> Despite the emulation, they could still be used as a weird form of ROP >> gadget that lives at a fixed address. I'd >> like to offer a way for new runtimes to indicate that they don't use >> vsyscalls so that the kernel can selectively >> disable emulation and remove the fixed-address executable code issue. >> >> > Wouldn't it be more useful if the check is against a bitmask added as > extended attribute for that executable? > This way the administrators and will have the flexibility to simply add the > new attribute to the executable. I don't think this should be something configured by the administrator, unless the administrator is the builder of a kiosky thing like Chromium OS. In that case, the administrator can use vsyscall=none. I think this should be handled by either libc or the toolchain, hence the suggestions of a syscall or an ELF header. --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: Pondering per-process vsyscall disablement
On Thu, May 22, 2014 at 7:44 PM, Marian Marinov m...@1h.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2014 02:04 AM, Andy Lutomirski wrote: It would be nice to have a way for new programs to declare that they don't need vsyscalls. What's the right way to do this? An ELF header entry in the loader? An ELF header entry in the program? A new arch_prctl? As background, there's an old part of the x86_64 ABI that allows programs to do gettimeofday, clock_gettime, and getcpu by calling to fixed addresses of the form 0xff600n00 where n indicates which of those three syscalls is being invoked. This is a security issue. Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a result, vsyscalls no longer offer any performance advantage over normal syscalls; in fact, they're much slower. As far as I know, nothing newer than 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of things will still fall back to the vsyscall page if there is no vdso, but that shouldn't matter, since there is always a vdso.) Despite the emulation, they could still be used as a weird form of ROP gadget that lives at a fixed address. I'd like to offer a way for new runtimes to indicate that they don't use vsyscalls so that the kernel can selectively disable emulation and remove the fixed-address executable code issue. Wouldn't it be more useful if the check is against a bitmask added as extended attribute for that executable? This way the administrators and will have the flexibility to simply add the new attribute to the executable. I don't think this should be something configured by the administrator, unless the administrator is the builder of a kiosky thing like Chromium OS. In that case, the administrator can use vsyscall=none. I think this should be handled by either libc or the toolchain, hence the suggestions of a syscall or an ELF header. --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: Pondering per-process vsyscall disablement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2014 02:04 AM, Andy Lutomirski wrote: > It would be nice to have a way for new programs to declare that they don't > need vsyscalls. What's the right way to > do this? An ELF header entry in the loader? An ELF header entry in the > program? A new arch_prctl? > > As background, there's an old part of the x86_64 ABI that allows programs to > do gettimeofday, clock_gettime, and > getcpu by calling to fixed addresses of the form 0xff600n00 where n > indicates which of those three syscalls > is being invoked. This is a security issue. > > Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a > result, vsyscalls no longer offer any > performance advantage over normal syscalls; in fact, they're much slower. As > far as I know, nothing newer than > 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of > things will still fall back to the > vsyscall page if there is no vdso, but that shouldn't matter, since there is > always a vdso.) > > Despite the emulation, they could still be used as a weird form of ROP gadget > that lives at a fixed address. I'd > like to offer a way for new runtimes to indicate that they don't use > vsyscalls so that the kernel can selectively > disable emulation and remove the fixed-address executable code issue. > > Wouldn't it be more useful if the check is against a bitmask added as extended attribute for that executable? This way the administrators and will have the flexibility to simply add the new attribute to the executable. Marian > --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/ > - -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hack...@jabber.org ICQ: 7556201 Mobile: +359 886 660 270 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlN+tg4ACgkQ4mt9JeIbjJRGkgCgjnD2s+J9kIr5oEDeL3VKHNvX X4cAn17zC0aPKyTCVekmqZRlVukqLWyC =vrfk -END PGP SIGNATURE- -- 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/
Pondering per-process vsyscall disablement
It would be nice to have a way for new programs to declare that they don't need vsyscalls. What's the right way to do this? An ELF header entry in the loader? An ELF header entry in the program? A new arch_prctl? As background, there's an old part of the x86_64 ABI that allows programs to do gettimeofday, clock_gettime, and getcpu by calling to fixed addresses of the form 0xff600n00 where n indicates which of those three syscalls is being invoked. This is a security issue. Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a result, vsyscalls no longer offer any performance advantage over normal syscalls; in fact, they're much slower. As far as I know, nothing newer than 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of things will still fall back to the vsyscall page if there is no vdso, but that shouldn't matter, since there is always a vdso.) Despite the emulation, they could still be used as a weird form of ROP gadget that lives at a fixed address. I'd like to offer a way for new runtimes to indicate that they don't use vsyscalls so that the kernel can selectively disable emulation and remove the fixed-address executable code issue. --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/
Pondering per-process vsyscall disablement
It would be nice to have a way for new programs to declare that they don't need vsyscalls. What's the right way to do this? An ELF header entry in the loader? An ELF header entry in the program? A new arch_prctl? As background, there's an old part of the x86_64 ABI that allows programs to do gettimeofday, clock_gettime, and getcpu by calling to fixed addresses of the form 0xff600n00 where n indicates which of those three syscalls is being invoked. This is a security issue. Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a result, vsyscalls no longer offer any performance advantage over normal syscalls; in fact, they're much slower. As far as I know, nothing newer than 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of things will still fall back to the vsyscall page if there is no vdso, but that shouldn't matter, since there is always a vdso.) Despite the emulation, they could still be used as a weird form of ROP gadget that lives at a fixed address. I'd like to offer a way for new runtimes to indicate that they don't use vsyscalls so that the kernel can selectively disable emulation and remove the fixed-address executable code issue. --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: Pondering per-process vsyscall disablement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2014 02:04 AM, Andy Lutomirski wrote: It would be nice to have a way for new programs to declare that they don't need vsyscalls. What's the right way to do this? An ELF header entry in the loader? An ELF header entry in the program? A new arch_prctl? As background, there's an old part of the x86_64 ABI that allows programs to do gettimeofday, clock_gettime, and getcpu by calling to fixed addresses of the form 0xff600n00 where n indicates which of those three syscalls is being invoked. This is a security issue. Since Linux 3.1, vsyscalls are emulated using NX and page faults. As a result, vsyscalls no longer offer any performance advantage over normal syscalls; in fact, they're much slower. As far as I know, nothing newer than 2012 will attempt to use vsyscalls if a vdso is present. (Sadly, a lot of things will still fall back to the vsyscall page if there is no vdso, but that shouldn't matter, since there is always a vdso.) Despite the emulation, they could still be used as a weird form of ROP gadget that lives at a fixed address. I'd like to offer a way for new runtimes to indicate that they don't use vsyscalls so that the kernel can selectively disable emulation and remove the fixed-address executable code issue. Wouldn't it be more useful if the check is against a bitmask added as extended attribute for that executable? This way the administrators and will have the flexibility to simply add the new attribute to the executable. Marian --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/ - -- Marian Marinov Founder CEO of 1H Ltd. Jabber/GTalk: hack...@jabber.org ICQ: 7556201 Mobile: +359 886 660 270 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlN+tg4ACgkQ4mt9JeIbjJRGkgCgjnD2s+J9kIr5oEDeL3VKHNvX X4cAn17zC0aPKyTCVekmqZRlVukqLWyC =vrfk -END PGP SIGNATURE- -- 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/
