Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 03:01:08PM +, Sasha Levin wrote: > On Thu, May 03, 2018 at 04:52:05PM +0200, Willy Tarreau wrote: > >I wouldn't be much surprised if you'd find that among those not introduced > >in the current merge window, many were introduced in the previous release. &

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 08:27:48AM -0700, James Bottomley wrote: > It's also a sad fact that a lot of things which look like obvious fixes > actually turn out not to be so with later testing. This is why the > user visibility test is paramount. If a bug fix has no real user > visible effects,

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 08:27:48AM -0700, James Bottomley wrote: > It's also a sad fact that a lot of things which look like obvious fixes > actually turn out not to be so with later testing. This is why the > user visibility test is paramount. If a bug fix has no real user > visible effects,

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 02:46:14PM +, Sasha Levin wrote: > I'll work on breaking up the 4.16 commits into categories, but one > interesting statistic I've noticed while starting the work is: > > Fixes in -rc cycles: > rc1 68 > rc2 147 > rc3 88 > rc4 121 > rc5 40 > rc6 193 > rc7 98 > >

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 02:46:14PM +, Sasha Levin wrote: > I'll work on breaking up the 4.16 commits into categories, but one > interesting statistic I've noticed while starting the work is: > > Fixes in -rc cycles: > rc1 68 > rc2 147 > rc3 88 > rc4 121 > rc5 40 > rc6 193 > rc7 98 > >

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 07:33:04AM -0700, James Bottomley wrote: > They're definitely for bug fixes, but there's a spectrum: obvious bug > fixes with no side effects are easy to justify. More complex bug fixes > run the risk of having side effects which introduce other bugs, so > could

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 07:33:04AM -0700, James Bottomley wrote: > They're definitely for bug fixes, but there's a spectrum: obvious bug > fixes with no side effects are easy to justify. More complex bug fixes > run the risk of having side effects which introduce other bugs, so > could

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote: > > Because if that last is the case, then the prescription is very simple > > and not controversial --- bug fixes found post -rc4 should be held to > > the next merge window. > > > > Holding up even fixes for severe bugs for 4-6

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote: > > Because if that last is the case, then the prescription is very simple > > and not controversial --- bug fixes found post -rc4 should be held to > > the next merge window. > > > > Holding up even fixes for severe bugs for 4-6

Re: bug-introducing patches

On Wed, May 02, 2018 at 07:42:33PM +, Sasha Levin wrote: > I'm not advocating to keep bugs in. If there is a fix, but the developer > can't indicate that proper testing was done on the fix we should revert > the new feature rather than merge the untested fix in. If you're exclusively talking

Re: bug-introducing patches

On Wed, May 02, 2018 at 07:42:33PM +, Sasha Levin wrote: > I'm not advocating to keep bugs in. If there is a fix, but the developer > can't indicate that proper testing was done on the fix we should revert > the new feature rather than merge the untested fix in. If you're exclusively talking

Re: bug-introducing patches

On Tue, May 01, 2018 at 10:02:30PM +, Sasha Levin wrote: > On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: > >Post -rc3 or -rc4, in my opinion bug fixes should wait until the next > >merge window before they get merged at all. (And certainly features > >bugs should be Right

Re: bug-introducing patches

On Tue, May 01, 2018 at 10:02:30PM +, Sasha Levin wrote: > On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: > >Post -rc3 or -rc4, in my opinion bug fixes should wait until the next > >merge window before they get merged at all. (And certainly features > >bugs should be Right

Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: > What's worse is that that commit is tagged for stable, which means > that (given Greg's schedule) it may find it's way to -stable users > even before some -next users/bots had a chance to test it out. But it's a difficult trade-off. I

Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: > What's worse is that that commit is tagged for stable, which means > that (given Greg's schedule) it may find it's way to -stable users > even before some -next users/bots had a chance to test it out. But it's a difficult trade-off. I

Re: bug-introducing patches (or: -rc cycles suck)

On Tue, May 01, 2018 at 04:19:35PM +, Sasha Levin wrote: > On Mon, Apr 30, 2018 at 09:09:18PM +0200, Willy Tarreau wrote: > >Hi Sasha, > > > >On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: > >> - For some reason, the odds of a -rc commit to be targe

Re: bug-introducing patches (or: -rc cycles suck)

On Tue, May 01, 2018 at 04:19:35PM +, Sasha Levin wrote: > On Mon, Apr 30, 2018 at 09:09:18PM +0200, Willy Tarreau wrote: > >Hi Sasha, > > > >On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: > >> - For some reason, the odds of a -rc commit to be targe

Re: bug-introducing patches (or: -rc cycles suck)

Hi Sasha, On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: > - For some reason, the odds of a -rc commit to be targetted for -stable is > over 20%, while for merge window commits it's about 3%. I can't quite > explain why that happens, but this would suggest that -rc commits end up

Re: bug-introducing patches (or: -rc cycles suck)

Hi Sasha, On Mon, Apr 30, 2018 at 05:58:30PM +, Sasha Levin wrote: > - For some reason, the odds of a -rc commit to be targetted for -stable is > over 20%, while for merge window commits it's about 3%. I can't quite > explain why that happens, but this would suggest that -rc commits end up

Re: Moving unmaintained filesystems to staging

On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote: > > > On 25.04.2018 23:30, David Sterba wrote: > > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote: > >> Recently ncpfs got moved to staging. Also recently, we had some fuzzer > >> developers report bugs in hfs,

Re: Moving unmaintained filesystems to staging

On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote: > > > On 25.04.2018 23:30, David Sterba wrote: > > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote: > >> Recently ncpfs got moved to staging. Also recently, we had some fuzzer > >> developers report bugs in hfs,

Re: [PATCH] staging: speakup: separate 80+ chars lines.

On Thu, Apr 19, 2018 at 03:47:10AM -0300, Andrew Jye Shih Chuang wrote: > Increase readability of code following the Kernel coding style by breaking > long lines and thus eliminating the checkpatch.pl warning. > > Signed-off-by: Andrew Jye Shih Chuang > --- >

Re: [PATCH] staging: speakup: separate 80+ chars lines.

On Thu, Apr 19, 2018 at 03:47:10AM -0300, Andrew Jye Shih Chuang wrote: > Increase readability of code following the Kernel coding style by breaking > long lines and thus eliminating the checkpatch.pl warning. > > Signed-off-by: Andrew Jye Shih Chuang > --- > drivers/staging/speakup/main.c |

Re: [Question] patch posting process

Hi Vadim, On Fri, Apr 06, 2018 at 11:29:16AM -0700, Vadim Lomovtsev wrote: > Hi all, > > I bring my Apologise for wasting your time, but .. Questions about doing things right rarely are a waste of time if they save others from having to do useless work! > May I ask for some clarification..

Re: [Question] patch posting process

Hi Vadim, On Fri, Apr 06, 2018 at 11:29:16AM -0700, Vadim Lomovtsev wrote: > Hi all, > > I bring my Apologise for wasting your time, but .. Questions about doing things right rarely are a waste of time if they save others from having to do useless work! > May I ask for some clarification..

Re: Did kernel 3.11 never work?

On Fri, Mar 23, 2018 at 02:58:46PM +, Maurice R Volaski wrote: > I'm trying to build a computer with network diagnostic tool, > https://software.internet2.edu/ndt/ and it requires patches to the kernel, > https://www.web10g.org/. The latest kernel for which there are patches, 3.17, > doesn't

Re: Did kernel 3.11 never work?

On Fri, Mar 23, 2018 at 02:58:46PM +, Maurice R Volaski wrote: > I'm trying to build a computer with network diagnostic tool, > https://software.internet2.edu/ndt/ and it requires patches to the kernel, > https://www.web10g.org/. The latest kernel for which there are patches, 3.17, > doesn't

Re: Did kernel 3.11 never work?

On Fri, Mar 23, 2018 at 02:37:17PM +, Maurice R Volaski wrote: > I am trying to use kernel 3.11 on VirtualBox or VMWare, but it hangs at boot > right after the message "Booting the kernel". Under VMWare, VMWare gives a > message that it received an instruction to halt the CPU. > > I have

Re: Did kernel 3.11 never work?

On Fri, Mar 23, 2018 at 02:37:17PM +, Maurice R Volaski wrote: > I am trying to use kernel 3.11 on VirtualBox or VMWare, but it hangs at boot > right after the message "Booting the kernel". Under VMWare, VMWare gives a > message that it received an instruction to halt the CPU. > > I have

Re: [PATCH] ubi: Reject MLC NAND

Hi Boris, On Wed, Mar 07, 2018 at 11:30:57PM +0100, Boris Brezillon wrote: > I have one simple question: did you ever play with MLC NANDs or are you > just trolling? If you had, like Richard and I did when working on MLC > support, I'm pretty sure you wouldn't play this "don't backport to >

Re: [PATCH] ubi: Reject MLC NAND

Hi Boris, On Wed, Mar 07, 2018 at 11:30:57PM +0100, Boris Brezillon wrote: > I have one simple question: did you ever play with MLC NANDs or are you > just trolling? If you had, like Richard and I did when working on MLC > support, I'm pretty sure you wouldn't play this "don't backport to >

Re: C tricks for efficient stack zeroing

Hi Jason, On Fri, Mar 02, 2018 at 08:50:17PM +0100, Jason A. Donenfeld wrote: > Hi list, > > I'm writing this email to solicit tricks for efficiently zeroing out > the stack upon returning from a function. The reason this is often > desirable is if the stack contains intermediate values that

Re: C tricks for efficient stack zeroing

Hi Jason, On Fri, Mar 02, 2018 at 08:50:17PM +0100, Jason A. Donenfeld wrote: > Hi list, > > I'm writing this email to solicit tricks for efficiently zeroing out > the stack upon returning from a function. The reason this is often > desirable is if the stack contains intermediate values that

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

Hi Robert, On Wed, Feb 28, 2018 at 12:29:38AM +0100, Robert Abel wrote: > It is however an edge case that incurs a > lot of code for little to no functionality. > I'd much prefer if we broke backwards compatibility here and actually > only parse the format that is indicated in the comment: > > >

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

Hi Robert, On Wed, Feb 28, 2018 at 12:29:38AM +0100, Robert Abel wrote: > It is however an edge case that incurs a > lot of code for little to no functionality. > I'd much prefer if we broke backwards compatibility here and actually > only parse the format that is indicated in the comment: > > >

Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 11:09:52PM +0100, Miguel Ojeda wrote: > The current version is not parsing multiple x/y commands as the code > originally intended. On top of that, kstrtoul() expects > NULL-terminated strings. Finally, the code does two passes over > the string. > > Some explanations

Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 11:09:52PM +0100, Miguel Ojeda wrote: > The current version is not parsing multiple x/y commands as the code > originally intended. On top of that, kstrtoul() expects > NULL-terminated strings. Finally, the code does two passes over > the string. > > Some explanations

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 08:32:21PM +0100, Miguel Ojeda wrote: > The current version is not parsing multiple x/y commands as the code > originally intended. On top of that, kstrtoul() expects > NULL-terminated strings. Finally, the code had to do two passes over > the string, while now only one is

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 08:32:21PM +0100, Miguel Ojeda wrote: > The current version is not parsing multiple x/y commands as the code > originally intended. On top of that, kstrtoul() expects > NULL-terminated strings. Finally, the code had to do two passes over > the string, while now only one is

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

On Tue, Feb 27, 2018 at 12:05:10AM +0100, Robert Abel wrote: > Hi Miguel, > > On 26 Feb 2018 17:49, Miguel Ojeda wrote: > > On Mon, Feb 26, 2018 at 12:54 AM, Robert Abel wrote: > >> + /* clamp new x/y coordinates */ > >> + if (tmp_addr.x >=

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

On Tue, Feb 27, 2018 at 12:05:10AM +0100, Robert Abel wrote: > Hi Miguel, > > On 26 Feb 2018 17:49, Miguel Ojeda wrote: > > On Mon, Feb 26, 2018 at 12:54 AM, Robert Abel wrote: > >> + /* clamp new x/y coordinates */ > >> + if (tmp_addr.x >= lcd->width) > >> +

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

On Mon, Feb 26, 2018 at 11:43:36PM +0100, Robert Abel wrote: > On 26 Feb 2018 17:49, Miguel Ojeda wrote: > > On a general note, the code seems a bit convoluted for what it does, > > specially without the comment written in the commit message :-) Isn't > > it simpler to use a tiny array in the

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

On Mon, Feb 26, 2018 at 11:43:36PM +0100, Robert Abel wrote: > On 26 Feb 2018 17:49, Miguel Ojeda wrote: > > On a general note, the code seems a bit convoluted for what it does, > > specially without the comment written in the commit message :-) Isn't > > it simpler to use a tiny array in the

Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers

On Sat, Feb 17, 2018 at 08:39:55PM +0100, Miguel Ojeda wrote: > Cc: Willy Tarreau <w...@1wt.eu> > Cc: Geert Uytterhoeven <ge...@linux-m68k.org> > Cc: Linus Walleij <tr...@df.lth.se> > Cc: Robin van der Gracht <ro...@protonic.nl> > Cc: Paul Burton <pau

Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers

On Sat, Feb 17, 2018 at 08:39:55PM +0100, Miguel Ojeda wrote: > Cc: Willy Tarreau > Cc: Geert Uytterhoeven > Cc: Linus Walleij > Cc: Robin van der Gracht > Cc: Paul Burton > Signed-off-by: Miguel Ojeda > --- > Please let me know if you agree for your files and I wi

Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

On Tue, Feb 13, 2018 at 03:36:45PM +0200, Andy Shevchenko wrote: > On Sat, Feb 10, 2018 at 11:41 AM, Miguel Ojeda > <miguel.ojeda.sando...@gmail.com> wrote: > > On Sat, Feb 10, 2018 at 10:20 AM, Willy Tarreau <w...@1wt.eu> wrote: > >> On Sat, Feb 10, 2018 at 09:

Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

On Tue, Feb 13, 2018 at 03:36:45PM +0200, Andy Shevchenko wrote: > On Sat, Feb 10, 2018 at 11:41 AM, Miguel Ojeda > wrote: > > On Sat, Feb 10, 2018 at 10:20 AM, Willy Tarreau wrote: > >> On Sat, Feb 10, 2018 at 09:58:44AM +0100, Miguel Ojeda wrote: > >>> On Sat,

Re: [PATCH V2] auxdisplay: use correct string length

On Tue, Feb 13, 2018 at 09:19:21AM +0800, Xiongfeng Wang wrote: > >> diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c > >> index ea7869c..d288900 100644 > >> --- a/drivers/auxdisplay/panel.c > >> +++ b/drivers/auxdisplay/panel.c > >> @@ -1506,10 +1506,10 @@ static struct

Re: [PATCH V2] auxdisplay: use correct string length

On Tue, Feb 13, 2018 at 09:19:21AM +0800, Xiongfeng Wang wrote: > >> diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c > >> index ea7869c..d288900 100644 > >> --- a/drivers/auxdisplay/panel.c > >> +++ b/drivers/auxdisplay/panel.c > >> @@ -1506,10 +1506,10 @@ static struct

Re: [PATCH V2] auxdisplay: use correct string length

On Mon, Feb 12, 2018 at 01:53:57PM +0100, Miguel Ojeda wrote: > > diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c > > index ea7869c..d288900 100644 > > --- a/drivers/auxdisplay/panel.c > > +++ b/drivers/auxdisplay/panel.c > > @@ -1506,10 +1506,10 @@ static struct logical_input

Re: [PATCH V2] auxdisplay: use correct string length

On Mon, Feb 12, 2018 at 01:53:57PM +0100, Miguel Ojeda wrote: > > diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c > > index ea7869c..d288900 100644 > > --- a/drivers/auxdisplay/panel.c > > +++ b/drivers/auxdisplay/panel.c > > @@ -1506,10 +1506,10 @@ static struct logical_input

Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

On Sat, Feb 10, 2018 at 07:31:54PM +0100, Geert Uytterhoeven wrote: > The redefinition feature definitely works with hex characters. > I've used it in the past, cfr. the picture on my Google+ profile ;-) > https://plus.google.com/u/0/+GeertUytterhoeven I've used it as well which is why I never

Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

On Sat, Feb 10, 2018 at 07:31:54PM +0100, Geert Uytterhoeven wrote: > The redefinition feature definitely works with hex characters. > I've used it in the past, cfr. the picture on my Google+ profile ;-) > https://plus.google.com/u/0/+GeertUytterhoeven I've used it as well which is why I never

Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

Hi Miguel, On Sat, Feb 10, 2018 at 09:58:44AM +0100, Miguel Ojeda wrote: > On Sat, Feb 10, 2018 at 12:50 AM, Robert Abel wrote: > > The graphics command expects 16 hexadecimal literals, but would allow > > characters in range [0-9a-zA-Z] instead of [0-9a-fA-F]. > > > >

Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

Hi Miguel, On Sat, Feb 10, 2018 at 09:58:44AM +0100, Miguel Ojeda wrote: > On Sat, Feb 10, 2018 at 12:50 AM, Robert Abel wrote: > > The graphics command expects 16 hexadecimal literals, but would allow > > characters in range [0-9a-zA-Z] instead of [0-9a-fA-F]. > > > > Signed-off-by: Robert

Re: [PATCH] auxdisplay: charlcd: delete mdelay in long_sleep

an interrupt handler. > Thus mdelay() and in_interrupt() are not necessary. > > This is found by a static analysis tool named DCNS written by myself. Looks good. This code is extremely old (started in 2.2) so I'm not surprised at all that after many changes such parts are not used anym

Re: [PATCH] auxdisplay: charlcd: delete mdelay in long_sleep

an interrupt handler. > Thus mdelay() and in_interrupt() are not necessary. > > This is found by a static analysis tool named DCNS written by myself. Looks good. This code is extremely old (started in 2.2) so I'm not surprised at all that after many changes such parts are not used anym

MAINTAINERS: clarify that only verified bugs should be submitted to security@

We're seeing a raise of automated reports from testing tools and reports about address leaks that are not really exploitable as-is, many of which do not represent an immediate risk justifying to work in closed places. Signed-off-by: Willy Tarreau <w...@1wt.eu> Acked-by: Greg Kroah-Hartma

MAINTAINERS: clarify that only verified bugs should be submitted to security@

We're seeing a raise of automated reports from testing tools and reports about address leaks that are not really exploitable as-is, many of which do not represent an immediate risk justifying to work in closed places. Signed-off-by: Willy Tarreau Acked-by: Greg Kroah-Hartman --- MAINTAINERS

Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

On Sat, Jan 20, 2018 at 03:26:27PM +0100, Ingo Molnar wrote: > > * Nadav Amit wrote: > > > > So we are trading a 5-15% slowdown (PTI) for another 5-15% slowdown, plus > > > we > > > are losing the soft-SMEP feature on older CPUs that PTI enables, which is > > > a > > >

Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

On Sat, Jan 20, 2018 at 03:26:27PM +0100, Ingo Molnar wrote: > > * Nadav Amit wrote: > > > > So we are trading a 5-15% slowdown (PTI) for another 5-15% slowdown, plus > > > we > > > are losing the soft-SMEP feature on older CPUs that PTI enables, which is > > > a > > > pretty powerful

Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

On Mon, Jan 15, 2018 at 11:49:19AM -0800, Dave Hansen wrote: > If we start disabling PTI willy nilly at points _away_ from the > capability checks (like for 32-bit binaries, say), then it gets really > hard to decide if we are doing the right things. > > Also, what's the end goal here? Run old

Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

On Mon, Jan 15, 2018 at 11:49:19AM -0800, Dave Hansen wrote: > If we start disabling PTI willy nilly at points _away_ from the > capability checks (like for 32-bit binaries, say), then it gets really > hard to decide if we are doing the right things. > > Also, what's the end goal here? Run old

Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote: > In fact, it looks like this code is totally bogus and has never been > correct at all. Even in: > > commit 4b1d5ae3b103eda43f9d0f85c355bb6995b03a30 > Author: Peter Zijlstra > Date: Mon Dec 4 15:07:59 2017

Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote: > In fact, it looks like this code is totally bogus and has never been > correct at all. Even in: > > commit 4b1d5ae3b103eda43f9d0f85c355bb6995b03a30 > Author: Peter Zijlstra > Date: Mon Dec 4 15:07:59 2017 +0100 > >

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Fri, Jan 12, 2018 at 01:18:06PM -0800, Andy Lutomirski wrote: > FWIW, if we take this approach, then either dropping the capability should > turn PTI back on or we need to deal with the corner case of PTI off and > capability not present. The latter is a bit awkward but not necessarily a >

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Fri, Jan 12, 2018 at 01:18:06PM -0800, Andy Lutomirski wrote: > FWIW, if we take this approach, then either dropping the capability should > turn PTI back on or we need to deal with the corner case of PTI off and > capability not present. The latter is a bit awkward but not necessarily a >

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Fri, Jan 12, 2018 at 09:55:45AM -0800, Linus Torvalds wrote: > On Fri, Jan 12, 2018 at 8:27 AM, David Laight wrote: > > > > You need to allow for libraries that create threads before main() > > is called. > > I really don't think we do. I think the normal case is the

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Fri, Jan 12, 2018 at 09:55:45AM -0800, Linus Torvalds wrote: > On Fri, Jan 12, 2018 at 8:27 AM, David Laight wrote: > > > > You need to allow for libraries that create threads before main() > > is called. > > I really don't think we do. I think the normal case is the wrapper. > > Processes

Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI

On Fri, Jan 12, 2018 at 03:03:23PM +, David Laight wrote: > From: Willy Tarreau > > Sent: 09 January 2018 12:56 > > > > This allows to report the current state of the PTI protection and to > > enable or disable it for the current process. The state change is

Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI

On Fri, Jan 12, 2018 at 03:03:23PM +, David Laight wrote: > From: Willy Tarreau > > Sent: 09 January 2018 12:56 > > > > This allows to report the current state of the PTI protection and to > > enable or disable it for the current process. The state change is

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 01:28:18PM -0800, Linus Torvalds wrote: > The traditional fast system call to test is getppid(). > > write() goes through a lot more code. Just tried getppid() now, it's relatively similar (slightly slower than write(-1) though, maybe that one aborts very early) :

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 01:28:18PM -0800, Linus Torvalds wrote: > The traditional fast system call to test is getppid(). > > write() goes through a lot more code. Just tried getppid() now, it's relatively similar (slightly slower than write(-1) though, maybe that one aborts very early) :

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:25:29AM -0800, Linus Torvalds wrote: > Just to clarify: I definitely want the part where it is only > switchable in single-threaded mode, and I actually do want it > "inherited" by threads when they do get created. OK this is what is currently done in series v3 because

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:25:29AM -0800, Linus Torvalds wrote: > Just to clarify: I definitely want the part where it is only > switchable in single-threaded mode, and I actually do want it > "inherited" by threads when they do get created. OK this is what is currently done in series v3 because

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:35:57AM -0800, Dave Hansen wrote: > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > >> 4. Cleared on setuid() and friends > > This one causes me a problem : some daemons already take care of dropping > > privileges after the initial fork()

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:35:57AM -0800, Dave Hansen wrote: > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > >> 4. Cleared on setuid() and friends > > This one causes me a problem : some daemons already take care of dropping > > privileges after the initial fork()

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 07:34:31PM +, Alan Cox wrote: > On Thu, 11 Jan 2018 13:26:01 -0600 > Josh Poimboeuf wrote: > > > On Thu, Jan 11, 2018 at 08:19:35PM +0100, Olivier Galibert wrote: > > > Wouldn't the time taken by an easy syscall like getuid be a clear > > >

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 07:34:31PM +, Alan Cox wrote: > On Thu, 11 Jan 2018 13:26:01 -0600 > Josh Poimboeuf wrote: > > > On Thu, Jan 11, 2018 at 08:19:35PM +0100, Olivier Galibert wrote: > > > Wouldn't the time taken by an easy syscall like getuid be a clear > > > indicator? > > > > I

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:38:07AM -0800, Dave Hansen wrote: > On 01/11/2018 10:32 AM, Josh Poimboeuf wrote: > >> hmm. Exposing cr3 to user space will make it trivial for user process > >> to know whether kpti is active. Not sure how exploitable such > >> information leak. > > It's already trivial

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:38:07AM -0800, Dave Hansen wrote: > On 01/11/2018 10:32 AM, Josh Poimboeuf wrote: > >> hmm. Exposing cr3 to user space will make it trivial for user process > >> to know whether kpti is active. Not sure how exploitable such > >> information leak. > > It's already trivial

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 09:53:26AM -0800, Andy Lutomirski wrote: > >> So I think that no-pti mode is a privilege as opposed to a mode per > >> se. If you can turn off PTI, then you have the ability to read all of > >> kernel memory So maybe we should treat it as such. Add a capability > >>

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 09:53:26AM -0800, Andy Lutomirski wrote: > >> So I think that no-pti mode is a privilege as opposed to a mode per > >> se. If you can turn off PTI, then you have the ability to read all of > >> kernel memory So maybe we should treat it as such. Add a capability > >>

Re: Backport of KPTI to 2.6.32 available

Hi Corey, On Thu, Jan 11, 2018 at 11:42:38AM -0600, Corey Minyard wrote: > I've completed a backport of KPTI from linux-stable-3.2.y to 2.6.32.71, in > case anyone is interested and wants to avoid all the work I went through. > It's available at: > >

Re: Backport of KPTI to 2.6.32 available

Hi Corey, On Thu, Jan 11, 2018 at 11:42:38AM -0600, Corey Minyard wrote: > I've completed a backport of KPTI from linux-stable-3.2.y to 2.6.32.71, in > case anyone is interested and wants to avoid all the work I went through. > It's available at: > >

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Hi Andy! On Thu, Jan 11, 2018 at 09:09:14AM -0800, Andy Lutomirski wrote: > On Thu, Jan 11, 2018 at 7:44 AM, Willy Tarreau <w...@1wt.eu> wrote: > >> So, I'd do this: > >> 1. Do the arch_prctl() (but ask the ARM guys what they want too) > >> 2. Enabled for a

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Hi Andy! On Thu, Jan 11, 2018 at 09:09:14AM -0800, Andy Lutomirski wrote: > On Thu, Jan 11, 2018 at 7:44 AM, Willy Tarreau wrote: > >> So, I'd do this: > >> 1. Do the arch_prctl() (but ask the ARM guys what they want too) > >> 2. Enabled for an entire process

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Hi Dave, On Thu, Jan 11, 2018 at 07:29:30AM -0800, Dave Hansen wrote: > I don't think we need a "NOW" and "NEXT" mode, at least initially. The > "NEXT" semantics are going to be tricky and I think "NOW" is good enough In fact I thought the NEXT one would bring us a nice benefit which is that we

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Hi Dave, On Thu, Jan 11, 2018 at 07:29:30AM -0800, Dave Hansen wrote: > I don't think we need a "NOW" and "NEXT" mode, at least initially. The > "NEXT" semantics are going to be tricky and I think "NOW" is good enough In fact I thought the NEXT one would bring us a nice benefit which is that we

Re: [RFC PATCH v2 5/6] x86/entry/pti: avoid setting CR3 when it's already correct

On Wed, Jan 10, 2018 at 12:29:17PM -0800, Dave Hansen wrote: > On 01/09/2018 04:56 AM, Willy Tarreau wrote: > > --- a/arch/x86/entry/calling.h > > +++ b/arch/x86/entry/calling.h > > @@ -214,6 +214,11 @@ > > .macro SWITCH_TO_KERNEL_CR3 scratch_reg:req >

Re: [RFC PATCH v2 5/6] x86/entry/pti: avoid setting CR3 when it's already correct

On Wed, Jan 10, 2018 at 12:29:17PM -0800, Dave Hansen wrote: > On 01/09/2018 04:56 AM, Willy Tarreau wrote: > > --- a/arch/x86/entry/calling.h > > +++ b/arch/x86/entry/calling.h > > @@ -214,6 +214,11 @@ > > .macro SWITCH_TO_KERNEL_CR3 scratch_reg:req >

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Wed, Jan 10, 2018 at 11:50:46AM -0800, Linus Torvalds wrote: > And the whole "NOW" vs "NEXT" is complete garbage. The obvious sane > no-PTI interface is that it > > (a) inherits on fork/exec, so that you don't have to worry about how > something is implemented (think "I want to run this

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Wed, Jan 10, 2018 at 11:50:46AM -0800, Linus Torvalds wrote: > And the whole "NOW" vs "NEXT" is complete garbage. The obvious sane > no-PTI interface is that it > > (a) inherits on fork/exec, so that you don't have to worry about how > something is implemented (think "I want to run this

Re: [RFC PATCH v3 6/8] x86/pti: don't mark the user PGD with _PAGE_NX.

On Wed, Jan 10, 2018 at 12:20:05PM -0800, Dave Hansen wrote: > Granted, you have an RFC on this, but please, for the love of everything > that is good the world, please stop sending this patch set until you > have a halfway reasonable method of dealing with NX that doesn't involve > #ifdefs.

Re: [RFC PATCH v3 6/8] x86/pti: don't mark the user PGD with _PAGE_NX.

On Wed, Jan 10, 2018 at 12:20:05PM -0800, Dave Hansen wrote: > Granted, you have an RFC on this, but please, for the love of everything > that is good the world, please stop sending this patch set until you > have a halfway reasonable method of dealing with NX that doesn't involve > #ifdefs.

Re: [RFC PATCH v3 6/8] x86/pti: don't mark the user PGD with _PAGE_NX.

Hi David, On Wed, Jan 10, 2018 at 08:28:27PM +, Woodhouse, David wrote: > So... we'd really like to *not* lose the property that KPTI implies > SMEP-like NX of user space for the kernel. Don't worry, I find it nice as well and am not trying to kill it. As mentionned in the "Note" section in

Re: [RFC PATCH v3 6/8] x86/pti: don't mark the user PGD with _PAGE_NX.

Hi David, On Wed, Jan 10, 2018 at 08:28:27PM +, Woodhouse, David wrote: > So... we'd really like to *not* lose the property that KPTI implies > SMEP-like NX of user space for the kernel. Don't worry, I find it nice as well and am not trying to kill it. As mentionned in the "Note" section in

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Hi Andy, On Wed, Jan 10, 2018 at 11:21:15AM -0800, Andy Lutomirski wrote: > > If we agree on this, I'd like to propose to have two flags : > > > > - TIF_DISABLE_PTI_NOW : disable PTI for the current task, reset by > > execve() > > - TIF_DISABLE_PTI_NEXT : disable PTI after execve(), reset by

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Hi Andy, On Wed, Jan 10, 2018 at 11:21:15AM -0800, Andy Lutomirski wrote: > > If we agree on this, I'd like to propose to have two flags : > > > > - TIF_DISABLE_PTI_NOW : disable PTI for the current task, reset by > > execve() > > - TIF_DISABLE_PTI_NEXT : disable PTI after execve(), reset by

[RFC PATCH v3 5/8] exec: take care of disabling PTI upon execve()

to disable PTI for a single exec call. Thanks to this, PTI-aware programs can adjust TIF_DISABLE_PTI_NOW for themselves, and a simple wrapper can be implemented by setting TIF_DISABLE_PTI_NEXT to manage those unable to set TIF_DISABLE_PTI_NOW themselves. Signed-off-by: Willy Tarreau <w...@1wt.eu&

<    1   2   3   4   5   6   7   8   9   10   >