Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, Steven. On Tue, Jan 09, 2018 at 05:08:47PM -0500, Steven Rostedt wrote: > The scenario you listed would affect multiple CPUs and multiple CPUs > would be flooding printk. In that case my patch WILL help. Because the > current method, the first CPU to do the printk will get stuck doing the

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, Steven. On Tue, Jan 09, 2018 at 05:08:47PM -0500, Steven Rostedt wrote: > The scenario you listed would affect multiple CPUs and multiple CPUs > would be flooding printk. In that case my patch WILL help. Because the > current method, the first CPU to do the printk will get stuck doing the

Re: [PATCH 31/31] aio: implement io_pgetevents

On Thu, Jan 4, 2018 at 9:00 AM, Christoph Hellwig wrote: > +} > + > +SYSCALL_DEFINE6(io_pgetevents, > + aio_context_t, ctx_id, > + long, min_nr, > + long, nr, > + struct io_event __user *, events, > + struct

Re: [PATCH 31/31] aio: implement io_pgetevents

On Thu, Jan 4, 2018 at 9:00 AM, Christoph Hellwig wrote: > +} > + > +SYSCALL_DEFINE6(io_pgetevents, > + aio_context_t, ctx_id, > + long, min_nr, > + long, nr, > + struct io_event __user *, events, > + struct timespec __user *,

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On Tue, 9 Jan 2018 12:06:20 -0800 Tejun Heo wrote: > What's happening is that the OOM killer is trapped flushing printk > failing to clear the memory condition and that leads irq / softirq > contexts to produce messages faster than can be flushed. I don't see > how we'd be

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On Tue, 9 Jan 2018 12:06:20 -0800 Tejun Heo wrote: > What's happening is that the OOM killer is trapped flushing printk > failing to clear the memory condition and that leads irq / softirq > contexts to produce messages faster than can be flushed. I don't see > how we'd be able to clear the

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Tejun Heo wrote: > The code might suck but I think this does replicate what we've been > seeing regularly in the fleet. The console side is pretty slow - IPMI > faithfully emulating serial console. I don't know it's doing 115200 > or even slower. Please consider something like the following.

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Tejun Heo wrote: > The code might suck but I think this does replicate what we've been > seeing regularly in the fleet. The console side is pretty slow - IPMI > faithfully emulating serial console. I don't know it's doing 115200 > or even slower. Please consider something like the following.

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

On Tue, Jan 09, 2018 at 10:46:02PM +0100, Borislav Petkov wrote: > On Tue, Jan 09, 2018 at 10:32:27PM +0100, Willy Tarreau wrote: > > Requiring a reboot just to fix a performance problem you've discovered > > the hard way is not the most friendly way to help users I'm afraid. > > That's a very

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

On Tue, Jan 09, 2018 at 10:46:02PM +0100, Borislav Petkov wrote: > On Tue, Jan 09, 2018 at 10:32:27PM +0100, Willy Tarreau wrote: > > Requiring a reboot just to fix a performance problem you've discovered > > the hard way is not the most friendly way to help users I'm afraid. > > That's a very

[PATCH] hwmon (pmbus): cffps: Add led class device for power supply fault led

This power supply device doesn't correctly manage it's own fault led. Add an led class device and register it so that userspace can manage power supply fault led as necessary. Signed-off-by: Eddie James --- drivers/hwmon/pmbus/ibm-cffps.c | 90

[PATCH] hwmon (pmbus): cffps: Add led class device for power supply fault led

This power supply device doesn't correctly manage it's own fault led. Add an led class device and register it so that userspace can manage power supply fault led as necessary. Signed-off-by: Eddie James --- drivers/hwmon/pmbus/ibm-cffps.c | 90 + 1 file

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

On Tue, Jan 09, 2018 at 01:50:10PM -0800, Kees Cook wrote: > On Tue, Jan 9, 2018 at 1:41 PM, Willy Tarreau wrote: > > On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > >> So I > >> think we should require CAP_SYS_RAWIO *and* that the system is booted > >> with

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

On Tue, Jan 09, 2018 at 01:50:10PM -0800, Kees Cook wrote: > On Tue, Jan 9, 2018 at 1:41 PM, Willy Tarreau wrote: > > On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > >> So I > >> think we should require CAP_SYS_RAWIO *and* that the system is booted > >> with pti=allow_optout or

Re: KASAN: use-after-free Read in handle_userfault

On Sun, Nov 26, 2017 at 10:15:17PM -0800, Eric Biggers wrote: > +Cc aarca...@redhat.com, xe...@parallels.com, linux...@kvack.org > > On Fri, Oct 27, 2017 at 11:46:13AM +0200, Dmitry Vyukov wrote: > > On Fri, Oct 27, 2017 at 11:44 AM, syzbot > >

Re: KASAN: use-after-free Read in handle_userfault

On Sun, Nov 26, 2017 at 10:15:17PM -0800, Eric Biggers wrote: > +Cc aarca...@redhat.com, xe...@parallels.com, linux...@kvack.org > > On Fri, Oct 27, 2017 at 11:46:13AM +0200, Dmitry Vyukov wrote: > > On Fri, Oct 27, 2017 at 11:44 AM, syzbot > > > > wrote: > > > Hello, > > > > > > syzkaller hit

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

It's unclear from Intel's documentation whether writing bit 0 of IA32_SPEC_CTRL or bit 0 of IA32_PRED_CMD will flush the BHB. (At least, it's unclear from the documentation I have.) The retpoline patches include code for *filling* the RSB, but if you invoke the RSB refill code from kernel text

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

It's unclear from Intel's documentation whether writing bit 0 of IA32_SPEC_CTRL or bit 0 of IA32_PRED_CMD will flush the BHB. (At least, it's unclear from the documentation I have.) The retpoline patches include code for *filling* the RSB, but if you invoke the RSB refill code from kernel text

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 9, 2018 at 1:49 PM, Josh Poimboeuf wrote: > On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote: >> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote: >> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: >> >> On

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 9, 2018 at 1:49 PM, Josh Poimboeuf wrote: > On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote: >> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote: >> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: >> >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams

Re: [PATCH RFC 0/4] Per-task PTI activation

On Tue, Jan 09, 2018 at 03:07:07PM -0600, Eric W. Biederman wrote: > > In fact that's what I liked with the wrapper approach, except that it > > had the downside of being harder to manage in terms of administration > > and we'd risk to see it used everywhere by default. The arch_prctl() > >

Re: [PATCH RFC 0/4] Per-task PTI activation

On Tue, Jan 09, 2018 at 03:07:07PM -0600, Eric W. Biederman wrote: > > In fact that's what I liked with the wrapper approach, except that it > > had the downside of being harder to manage in terms of administration > > and we'd risk to see it used everywhere by default. The arch_prctl() > >

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 09/01/2018 21:39, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 09, 2018 at 05:49:08PM +0100, Paolo Bonzini wrote: >> On 09/01/2018 17:23, Arjan van de Ven wrote: >>> On 1/9/2018 8:17 AM, Paolo Bonzini wrote: On 09/01/2018 16:19, Arjan van de Ven wrote: > On 1/9/2018 7:00 AM, Liran Alon

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 09/01/2018 21:39, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 09, 2018 at 05:49:08PM +0100, Paolo Bonzini wrote: >> On 09/01/2018 17:23, Arjan van de Ven wrote: >>> On 1/9/2018 8:17 AM, Paolo Bonzini wrote: On 09/01/2018 16:19, Arjan van de Ven wrote: > On 1/9/2018 7:00 AM, Liran Alon

Re: [PATCH v6 00/11] Intel SGX Driver

On Jan 9, 4:25pm, Jarkko Sakkinen wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Good afternoon I hope the week is going well for everyone. In order to minimize spamming mailboxes with two mails I'm incorporating a reply to Jarkko's second e-mail on the Memory Encryption Engine below

Re: [PATCH v6 00/11] Intel SGX Driver

On Jan 9, 4:25pm, Jarkko Sakkinen wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Good afternoon I hope the week is going well for everyone. In order to minimize spamming mailboxes with two mails I'm incorporating a reply to Jarkko's second e-mail on the Memory Encryption Engine below

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

On Tue, Jan 9, 2018 at 1:41 PM, Willy Tarreau wrote: > On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: >> So I >> think we should require CAP_SYS_RAWIO *and* that the system is booted >> with pti=allow_optout or something like that. > > I'm really not fan of this. 1)

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

On Tue, Jan 9, 2018 at 1:41 PM, Willy Tarreau wrote: > On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: >> So I >> think we should require CAP_SYS_RAWIO *and* that the system is booted >> with pti=allow_optout or something like that. > > I'm really not fan of this. 1) it would

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote: > On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote: > > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: > >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams > >> wrote:

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote: > On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote: > > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: > >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams > >> wrote: > >> > From: Andi Kleen > >> > > >> > When

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP Small queues heavily use TASKLET, >>

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP Small queues heavily use TASKLET, >> so as far as I am concerned a revert would have the

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote: > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams >> wrote: >> > From: Andi Kleen >> > >> > When access_ok

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote: > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams >> wrote: >> > From: Andi Kleen >> > >> > When access_ok fails we should always stop speculating. >> > Add the required

Re: Bricked x86 CPU with software?

> On Mon, 2018-01-08 at 11:08 -0800, Tim Mouraveiko wrote: > > > > > > I think you missed one of my posts from last week. The code has > > nothing to do with linux. > > Like the 'f00f' bug in the Pentium days, there may well be a way that a > kernel can *prevent* the code sequence from killing

Re: Bricked x86 CPU with software?

> On Mon, 2018-01-08 at 11:08 -0800, Tim Mouraveiko wrote: > > > > > > I think you missed one of my posts from last week. The code has > > nothing to do with linux. > > Like the 'f00f' bug in the Pentium days, there may well be a way that a > kernel can *prevent* the code sequence from killing

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

On Tue, Jan 09, 2018 at 10:32:27PM +0100, Willy Tarreau wrote: > Requiring a reboot just to fix a performance problem you've discovered > the hard way is not the most friendly way to help users I'm afraid. That's a very strange argument: if you know you'd need max perf, you boot with

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

On Tue, Jan 09, 2018 at 10:32:27PM +0100, Willy Tarreau wrote: > Requiring a reboot just to fix a performance problem you've discovered > the hard way is not the most friendly way to help users I'm afraid. That's a very strange argument: if you know you'd need max perf, you boot with

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 09/01/2018 21:57, Jim Mattson wrote: > Before VM-entry, don't we need to flush the BHB and the RSB to avoid > revealing KASLR information to the guest? (Thanks to Liran for > pointing this out.) I don't know how you flush the BHB? As to the RSB, that would also be part of generic Linux code

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 09/01/2018 21:57, Jim Mattson wrote: > Before VM-entry, don't we need to flush the BHB and the RSB to avoid > revealing KASLR information to the guest? (Thanks to Liran for > pointing this out.) I don't know how you flush the BHB? As to the RSB, that would also be part of generic Linux code

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

On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote: > > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote: > >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote: > >> > I see and am not

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

On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote: > > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote: > >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote: > >> > I see and am not particularly

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote: > > From: Andi Kleen > > > > When access_ok fails we should always stop speculating. > > Add the required barriers to the x86

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote: > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote: > > From: Andi Kleen > > > > When access_ok fails we should always stop speculating. > > Add the required barriers to the x86 access_ok macro. > > Honestly, this seems

[patch -mm] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks fix fix

Fix mmu_notifier.h comments in "mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks". mmu_notifier_invalidate_range_end() can also call the invalidate_range() callback, so it must not block for MMU_INVALIDATE_DOES_NOT_BLOCK to be set. Also remove a bogus comment about

[patch -mm] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks fix fix

Fix mmu_notifier.h comments in "mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks". mmu_notifier_invalidate_range_end() can also call the invalidate_range() callback, so it must not block for MMU_INVALIDATE_DOES_NOT_BLOCK to be set. Also remove a bogus comment about

Re: [PATCH V4 09/11] KVM: x86: Disable Intel Processor Trace when VMXON in L1 guest

On 09/01/2018 21:16, Jim Mattson wrote: > This doesn't look right to me. pt_disable_intercept_for_msr calls > either vmx_disable_intercept_for_msr or vmx_enable_intercept_for_msr, > both of which only change vmx_msr_bitmap_legacy > and vmx_msr_bitmap_longmode. Neither of these MSR permission

Re: [PATCH V4 09/11] KVM: x86: Disable Intel Processor Trace when VMXON in L1 guest

On 09/01/2018 21:16, Jim Mattson wrote: > This doesn't look right to me. pt_disable_intercept_for_msr calls > either vmx_disable_intercept_for_msr or vmx_enable_intercept_for_msr, > both of which only change vmx_msr_bitmap_legacy > and vmx_msr_bitmap_longmode. Neither of these MSR permission

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

On Tue, Jan 09, 2018 at 10:29:40PM +0100, Borislav Petkov wrote: > On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > > 2.Turning off PTI is, in general, a terrible idea. It totally breaks > > any semblance of a security model on a Meltdown-affected CPU. So I > > think we should

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

On Tue, Jan 09, 2018 at 10:29:40PM +0100, Borislav Petkov wrote: > On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > > 2.Turning off PTI is, in general, a terrible idea. It totally breaks > > any semblance of a security model on a Meltdown-affected CPU. So I > > think we should

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

On 01/09/2018 07:04 PM, Alexei Starovoitov wrote: > The BPF interpreter has been used as part of the spectre 2 attack > CVE-2017-5715. > > A quote from goolge project zero blog: > "At this point, it would normally be necessary to locate gadgets in > the host kernel code that can be used to

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

On 01/09/2018 07:04 PM, Alexei Starovoitov wrote: > The BPF interpreter has been used as part of the spectre 2 attack > CVE-2017-5715. > > A quote from goolge project zero blog: > "At this point, it would normally be necessary to locate gadgets in > the host kernel code that can be used to

Re: cgroups(7): documenting the nsdelegate mount option

On 01/09/2018 09:59 PM, Tejun Heo wrote: > Hello, Michael. > > On Tue, Jan 09, 2018 at 12:26:28AM +0100, Michael Kerrisk (man-pages) wrote: >> Hello Tejun, >> >> Here is my attempt to document dgroup v2 delegation using 'nsdelegate'. >> Could you please take a look at the text and let me know if

Re: cgroups(7): documenting the nsdelegate mount option

On 01/09/2018 09:59 PM, Tejun Heo wrote: > Hello, Michael. > > On Tue, Jan 09, 2018 at 12:26:28AM +0100, Michael Kerrisk (man-pages) wrote: >> Hello Tejun, >> >> Here is my attempt to document dgroup v2 delegation using 'nsdelegate'. >> Could you please take a look at the text and let me know if

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

On Tue, Jan 9, 2018 at 1:26 PM, Andy Lutomirski wrote: > 2.Turning off PTI is, in general, a terrible idea. It totally breaks > any semblance of a security model on a Meltdown-affected CPU. So I > think we should require CAP_SYS_RAWIO *and* that the system is booted > with

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

On Tue, Jan 9, 2018 at 1:26 PM, Andy Lutomirski wrote: > 2.Turning off PTI is, in general, a terrible idea. It totally breaks > any semblance of a security model on a Meltdown-affected CPU. So I > think we should require CAP_SYS_RAWIO *and* that the system is booted > with pti=allow_optout or

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

On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > 2.Turning off PTI is, in general, a terrible idea. It totally breaks > any semblance of a security model on a Meltdown-affected CPU. So I > think we should require CAP_SYS_RAWIO *and* that the system is booted > with

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

On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote: > 2.Turning off PTI is, in general, a terrible idea. It totally breaks > any semblance of a security model on a Meltdown-affected CPU. So I > think we should require CAP_SYS_RAWIO *and* that the system is booted > with

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

On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote: > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote: >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote: >> > I see and am not particularly against this, but what use case do you >> > have in mind

Re: [RFC] selftests/x86: Add test_vsyscall

On Tue, Jan 9, 2018 at 1:25 PM, Shuah Khan wrote: > On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote: >> This tests that the vsyscall entries do what they're expected to do. >> It also confirms that attempts to read the vsyscall page behave as >>

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

On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote: > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote: >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote: >> > I see and am not particularly against this, but what use case do you >> > have in mind precisely ? I doubt

Re: [RFC] selftests/x86: Add test_vsyscall

On Tue, Jan 9, 2018 at 1:25 PM, Shuah Khan wrote: > On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote: >> This tests that the vsyscall entries do what they're expected to do. >> It also confirms that attempts to read the vsyscall page behave as >> expected. >> >> If changes are made to the

Re: dvb usb issues since kernel 4.9

On Tue, 9 Jan 2018 15:42:35 -0200 Mauro Carvalho Chehab wrote: > Em Mon, 8 Jan 2018 11:51:04 -0800 Linus Torvalds > escreveu: > [...] > Patch makes sense to me, although I was not able to test it myself. The patch also make sense to

Re: dvb usb issues since kernel 4.9

On Tue, 9 Jan 2018 15:42:35 -0200 Mauro Carvalho Chehab wrote: > Em Mon, 8 Jan 2018 11:51:04 -0800 Linus Torvalds > escreveu: > [...] > Patch makes sense to me, although I was not able to test it myself. The patch also make sense to me. I've done some basic testing with it on my high-end

Re: [RFC] selftests/x86: Add test_vsyscall

On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map handling,

Re: [RFC] selftests/x86: Add test_vsyscall

On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map handling, > running this

Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

On 12/10/2017 12:21 PM, Jonathan Cameron wrote: > On Wed, 6 Dec 2017 17:52:34 + > Jeremy Cline wrote: > >> Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI >> device. Check for a companion device and handle a second i2c_client >> if it is present.

Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

On 12/10/2017 12:21 PM, Jonathan Cameron wrote: > On Wed, 6 Dec 2017 17:52:34 + > Jeremy Cline wrote: > >> Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI >> device. Check for a companion device and handle a second i2c_client >> if it is present. >> >> Signed-off-by:

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Tue, Jan 09, 2018 at 01:12:51PM -0800, Christoph Hellwig wrote: > On Tue, Jan 09, 2018 at 03:04:17PM -0500, Konrad Rzeszutek Wilk wrote: > > Totally. Thanks for taking care of it - been slammed with x86 architecture > > craziness. > > I'll take this as an Acked-by.. > Acked-by: Konrad

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Tue, Jan 09, 2018 at 01:12:51PM -0800, Christoph Hellwig wrote: > On Tue, Jan 09, 2018 at 03:04:17PM -0500, Konrad Rzeszutek Wilk wrote: > > Totally. Thanks for taking care of it - been slammed with x86 architecture > > craziness. > > I'll take this as an Acked-by.. > Acked-by: Konrad

Re: [PATCH v3] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On 12/14, Will Deacon wrote: > On Wed, Dec 13, 2017 at 02:19:37PM -0800, Stephen Boyd wrote: > > The Kryo CPUs are also affected by the Falkor 1003 errata, so > > we need to do the same workaround on Kryo CPUs. The MIDR is > > slightly more complicated here, where the PART number is not > > always

Re: [PATCH v3] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On 12/14, Will Deacon wrote: > On Wed, Dec 13, 2017 at 02:19:37PM -0800, Stephen Boyd wrote: > > The Kryo CPUs are also affected by the Falkor 1003 errata, so > > we need to do the same workaround on Kryo CPUs. The MIDR is > > slightly more complicated here, where the PART number is not > > always

Re: NFSroot regression in next with handle inode->i_version

* Jeff Layton [180109 21:14]: > On Tue, 2018-01-09 at 13:01 -0800, Tony Lindgren wrote: > > Commit 4b5bd6a8e7cf ("fs: handle inode->i_version more efficiently") > > causes NFSroot to not boot to login in Linux next on my ARM boxes. > Krzysztof Kozlowski reported this late

Re: NFSroot regression in next with handle inode->i_version

* Jeff Layton [180109 21:14]: > On Tue, 2018-01-09 at 13:01 -0800, Tony Lindgren wrote: > > Commit 4b5bd6a8e7cf ("fs: handle inode->i_version more efficiently") > > causes NFSroot to not boot to login in Linux next on my ARM boxes. > Krzysztof Kozlowski reported this late last week, and I just

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

If my documentation is up-to-date, writing IBRS does not clear the RSB (except for parts which contain an RSB that is not filled by 32 CALLs). On Tue, Jan 9, 2018 at 1:11 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 09, 2018 at 12:57:38PM -0800, Jim Mattson wrote: >>

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

If my documentation is up-to-date, writing IBRS does not clear the RSB (except for parts which contain an RSB that is not filled by 32 CALLs). On Tue, Jan 9, 2018 at 1:11 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 09, 2018 at 12:57:38PM -0800, Jim Mattson wrote: >> Before VM-entry, don't we

[PATCH v4 00/36] Hardened usercopy whitelisting

v4: - refactor reporting to include offset and remove %p - explicitly WARN by default for the whitelisting - add KVM whitelists and harden ioctl handling v3: - added LKDTM update patch - downgrade BUGs to WARNs and fail closed - add Acks/Reviews from v2 v2: - added tracing of allocation and

[PATCH v4 00/36] Hardened usercopy whitelisting

v4: - refactor reporting to include offset and remove %p - explicitly WARN by default for the whitelisting - add KVM whitelists and harden ioctl handling v3: - added LKDTM update patch - downgrade BUGs to WARNs and fail closed - add Acks/Reviews from v2 v2: - added tracing of allocation and

[PATCH 04/36] usercopy: Prepare for usercopy whitelisting

From: David Windsor This patch prepares the slab allocator to handle caches having annotations (useroffset and usersize) defining usercopy regions. This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX

[PATCH 04/36] usercopy: Prepare for usercopy whitelisting

From: David Windsor This patch prepares the slab allocator to handle caches having annotations (useroffset and usersize) defining usercopy regions. This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY whitelisting code in the last public patch of grsecurity/PaX based on my

[PATCH 02/36] usercopy: Include offset in overflow report

This refactors the hardened usercopy reporting code so that the object offset can be included in the report. Having the offset can be much more helpful in understanding usercopy bugs. Signed-off-by: Kees Cook --- include/linux/slab.h| 11 +++--

[PATCH 15/36] orangefs: Define usercopy region in orangefs_inode_cache slab cache

From: David Windsor orangefs symlink pathnames, stored in struct orangefs_inode_s.link_target and therefore contained in the orangefs_inode_cache, need to be copied to/from userspace. cache object allocation: fs/orangefs/super.c: orangefs_alloc_inode(...):

[PATCH 02/36] usercopy: Include offset in overflow report

This refactors the hardened usercopy reporting code so that the object offset can be included in the report. Having the offset can be much more helpful in understanding usercopy bugs. Signed-off-by: Kees Cook --- include/linux/slab.h| 11 +++-- include/linux/thread_info.h | 2 +

[PATCH 15/36] orangefs: Define usercopy region in orangefs_inode_cache slab cache

From: David Windsor orangefs symlink pathnames, stored in struct orangefs_inode_s.link_target and therefore contained in the orangefs_inode_cache, need to be copied to/from userspace. cache object allocation: fs/orangefs/super.c: orangefs_alloc_inode(...): ...

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Tue, Jan 09, 2018 at 03:04:17PM -0500, Konrad Rzeszutek Wilk wrote: > Totally. Thanks for taking care of it - been slammed with x86 architecture > craziness. I'll take this as an Acked-by..

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v5

On Tue, Jan 09, 2018 at 03:04:17PM -0500, Konrad Rzeszutek Wilk wrote: > Totally. Thanks for taking care of it - been slammed with x86 architecture > craziness. I'll take this as an Acked-by..

[PATCH 16/36] ufs: Define usercopy region in ufs_inode_cache slab cache

From: David Windsor The ufs symlink pathnames, stored in struct ufs_inode_info.i_u1.i_symlink and therefore contained in the ufs_inode_cache slab cache, need to be copied to/from userspace. cache object allocation: fs/ufs/super.c: ufs_alloc_inode(...):

[PATCH 16/36] ufs: Define usercopy region in ufs_inode_cache slab cache

From: David Windsor The ufs symlink pathnames, stored in struct ufs_inode_info.i_u1.i_symlink and therefore contained in the ufs_inode_cache slab cache, need to be copied to/from userspace. cache object allocation: fs/ufs/super.c: ufs_alloc_inode(...): ... ei

[PATCH 19/36] scsi: Define usercopy region in scsi_sense_cache slab cache

From: David Windsor SCSI sense buffers, stored in struct scsi_cmnd.sense and therefore contained in the scsi_sense_cache slab cache, need to be copied to/from userspace. cache object allocation: drivers/scsi/scsi_lib.c: scsi_select_sense_cache(...):

[PATCH 19/36] scsi: Define usercopy region in scsi_sense_cache slab cache

From: David Windsor SCSI sense buffers, stored in struct scsi_cmnd.sense and therefore contained in the scsi_sense_cache slab cache, need to be copied to/from userspace. cache object allocation: drivers/scsi/scsi_lib.c: scsi_select_sense_cache(...): return ... ?

[PATCH 18/36] cifs: Define usercopy region in cifs_request slab cache

From: David Windsor CIFS request buffers, stored in the cifs_request slab cache, need to be copied to/from userspace. cache object allocation: fs/cifs/cifsfs.c: cifs_init_request_bufs(): ... cifs_req_poolp =

[PATCH 18/36] cifs: Define usercopy region in cifs_request slab cache

From: David Windsor CIFS request buffers, stored in the cifs_request slab cache, need to be copied to/from userspace. cache object allocation: fs/cifs/cifsfs.c: cifs_init_request_bufs(): ... cifs_req_poolp = mempool_create_slab_pool(cifs_min_rcv,

[PATCH 17/36] vxfs: Define usercopy region in vxfs_inode slab cache

From: David Windsor vxfs symlink pathnames, stored in struct vxfs_inode_info field vii_immed.vi_immed and therefore contained in the vxfs_inode slab cache, need to be copied to/from userspace. cache object allocation: fs/freevxfs/vxfs_super.c:

[PATCH 17/36] vxfs: Define usercopy region in vxfs_inode slab cache

From: David Windsor vxfs symlink pathnames, stored in struct vxfs_inode_info field vii_immed.vi_immed and therefore contained in the vxfs_inode slab cache, need to be copied to/from userspace. cache object allocation: fs/freevxfs/vxfs_super.c: vxfs_alloc_inode(...): ...

Re: NFSroot regression in next with handle inode->i_version

On Tue, 2018-01-09 at 13:01 -0800, Tony Lindgren wrote: > Hi all, > > Commit 4b5bd6a8e7cf ("fs: handle inode->i_version more efficiently") > causes NFSroot to not boot to login in Linux next on my ARM boxes. > > Also the attempted boot seems really slow, so the reason for not > reaching login

Re: NFSroot regression in next with handle inode->i_version

On Tue, 2018-01-09 at 13:01 -0800, Tony Lindgren wrote: > Hi all, > > Commit 4b5bd6a8e7cf ("fs: handle inode->i_version more efficiently") > causes NFSroot to not boot to login in Linux next on my ARM boxes. > > Also the attempted boot seems really slow, so the reason for not > reaching login

[PATCH 13/36] befs: Define usercopy region in befs_inode_cache slab cache

From: David Windsor befs symlink pathnames, stored in struct befs_inode_info.i_data.symlink and therefore contained in the befs_inode_cache slab cache, need to be copied to/from userspace. cache object allocation: fs/befs/linuxvfs.c: befs_alloc_inode(...):

[PATCH 13/36] befs: Define usercopy region in befs_inode_cache slab cache

From: David Windsor befs symlink pathnames, stored in struct befs_inode_info.i_data.symlink and therefore contained in the befs_inode_cache slab cache, need to be copied to/from userspace. cache object allocation: fs/befs/linuxvfs.c: befs_alloc_inode(...): ...

[PATCH 20/36] net: Define usercopy region in struct proto slab cache

From: David Windsor In support of usercopy hardening, this patch defines a region in the struct proto slab cache in which userspace copy operations are allowed. Some protocols need to copy objects to/from userspace, and they can declare the region via their proto structure

[PATCH 20/36] net: Define usercopy region in struct proto slab cache

From: David Windsor In support of usercopy hardening, this patch defines a region in the struct proto slab cache in which userspace copy operations are allowed. Some protocols need to copy objects to/from userspace, and they can declare the region via their proto structure with the new usersize

<    3   4   5   6   7   8   9   10   11   12   >