On Thu, Mar 09, 2017 at 03:26:02PM -0800, Linus Torvalds wrote:
> Maybe it's the lguest games with PGE that need to be removed?
Btw, tglx suggested something else the other day: warn when we're
changing boot_cpu_data x86_capability bits *after* alternatives have
run. The reasoning behind it being
On 03/10/2017 12:44 AM, Borislav Petkov wrote:
On Thu, Mar 09, 2017 at 03:26:02PM -0800, Linus Torvalds wrote:
So should all of commit ("c109bf95992b x86/cpufeature: Remove
cpu_has_pge") just be reverted (and then marked for stable)?
Or do we have some alternate plan?
I think we want to do th
On Thu, Mar 09, 2017 at 03:26:02PM -0800, Linus Torvalds wrote:
> So should all of commit ("c109bf95992b x86/cpufeature: Remove
> cpu_has_pge") just be reverted (and then marked for stable)?
>
> Or do we have some alternate plan?
I think we want to do this:
diff --git a/arch/x86/include/asm/tlbf
On Thu, Mar 9, 2017 at 2:48 PM, Borislav Petkov wrote:
>
> I guess we could return to doing boot_cpu_has() in __flush_tlb_all()
> then. I mean, the timing-sensitivity argument is meh - killing global
> TLB entries a bit faster doesn't bring me a whole lot when I have to go
> and walk pagetable and
On Thu, Mar 09, 2017 at 11:11:17PM +0100, Daniel Borkmann wrote:
> Yeah, I just tried that out and it had no effect unfortunately, the
> static_cpu_has() was still 1.
Right, just as I thought.
I guess we could return to doing boot_cpu_has() in __flush_tlb_all()
then. I mean, the timing-sensitivit
On 03/09/2017 11:07 PM, Borislav Petkov wrote:
On Thu, Mar 09, 2017 at 10:55:47PM +0100, Borislav Petkov wrote:
Can you make that:
setup_clear_cpu_cap(X86_FEATURE_PGE);
and see if it fixes your issue?
Hmm, in reading the thread a bit more, that might not work. If I see it
correctly,
On Thu, Mar 09, 2017 at 10:32:12PM +0100, Daniel Borkmann wrote:
> get_online_cpus();
> if (boot_cpu_has(X86_FEATURE_PGE)) { /* We have a broader idea of
> "global". */
> /* Remember that this was originally set (for cleanup). */
> cpu_had_pge = 1;
>
On Thu, Mar 09, 2017 at 10:55:47PM +0100, Borislav Petkov wrote:
> Can you make that:
>
> setup_clear_cpu_cap(X86_FEATURE_PGE);
>
> and see if it fixes your issue?
Hmm, in reading the thread a bit more, that might not work. If I see it
correctly, lguest does
clear_cpu_cap(&boot_cpu_data,
[ + Borislav ]
On 03/09/2017 07:31 PM, Daniel Borkmann wrote:
On 03/09/2017 07:15 PM, Linus Torvalds wrote:
On Thu, Mar 9, 2017 at 10:10 AM, Linus Torvalds
wrote:
Very odd. We should always have PGE (0x0080) set in cr4 (if the CPU
supports it).
Daniel, do you see the code in probe_page_siz
On 03/09/2017 07:15 PM, Linus Torvalds wrote:
On Thu, Mar 9, 2017 at 10:10 AM, Linus Torvalds
wrote:
Very odd. We should always have PGE (0x0080) set in cr4 (if the CPU
supports it).
Daniel, do you see the code in probe_page_size_mask() triggering?
/* Enable PGE if available */
On Thu, Mar 9, 2017 at 10:10 AM, Linus Torvalds
wrote:
>
> Very odd. We should always have PGE (0x0080) set in cr4 (if the CPU
> supports it).
Daniel, do you see the code in probe_page_size_mask() triggering?
/* Enable PGE if available */
if (boot_cpu_has(X86_FEATURE_PGE)) {
On Thu, Mar 9, 2017 at 9:51 AM, Daniel Borkmann wrote:
>
> What I see is that original cr4 is 0x610. The cpu_tlbstate.cr4 is
> consistent to native_read_cr4() and since cr4 is != 0, it tells me
> based on the comment in native_read_cr4() that cr4 seems to be
> supported. Thus, meaning we end up wi
From: Daniel Borkmann
Date: Thu, 09 Mar 2017 18:51:03 +0100
> I added some debugging around __native_flush_tlb_global_irq_disabled()
> and if I understand it correctly, the idea of cr4 is that we need to
> toggle X86_CR4_PGE in order to trigger a TLB flush.
>
> What I see is that original cr4 is
On 03/09/2017 03:49 PM, Thomas Gleixner wrote:
On Thu, 9 Mar 2017, Daniel Borkmann wrote:
On 03/09/2017 02:10 PM, Thomas Gleixner wrote:
On Thu, 9 Mar 2017, Daniel Borkmann wrote:
With regard to CPA_FLUSHTLB that Linus mentioned, when I investigated
code paths in change_page_attr_set_clr(), I
On Thu, Mar 9, 2017 at 6:53 AM, Daniel Borkmann wrote:
>
> Fwiw, I tried switching from using cr4
> (__native_flush_tlb_global_irq_disabled())
> to slower cr3 (__native_flush_tlb()) in "-cpu kvm64" mode, and it looks like
> it also lets all test cases pass (rodata_test, test_setmem, test_bpf), no
On 03/09/2017 02:25 PM, Daniel Borkmann wrote:
On 03/09/2017 02:10 PM, Thomas Gleixner wrote:
On Thu, 9 Mar 2017, Daniel Borkmann wrote:
With regard to CPA_FLUSHTLB that Linus mentioned, when I investigated
code paths in change_page_attr_set_clr(), I did see that CPA_FLUSHTLB
was set each time
On Thu, 9 Mar 2017, Daniel Borkmann wrote:
> On 03/09/2017 02:10 PM, Thomas Gleixner wrote:
> > On Thu, 9 Mar 2017, Daniel Borkmann wrote:
> > > With regard to CPA_FLUSHTLB that Linus mentioned, when I investigated
> > > code paths in change_page_attr_set_clr(), I did see that CPA_FLUSHTLB
> > > w
On 03/09/2017 02:10 PM, Thomas Gleixner wrote:
On Thu, 9 Mar 2017, Daniel Borkmann wrote:
With regard to CPA_FLUSHTLB that Linus mentioned, when I investigated
code paths in change_page_attr_set_clr(), I did see that CPA_FLUSHTLB
was set each time we switched attrs and a cpa_flush_range() was
pe
On Wed, 8 Mar 2017, Linus Torvalds wrote:
> Adding x86 people too, since this seems to be something off about
> ARCH_HAS_SET_MEMORY for x86-32.
>
> The code seems to be shared between x86-32 and 64, I'm not seeing why
> set_memory_r[ow]() should fail on one but not the other.
Indeed.
> Consider
On Thu, 9 Mar 2017, Daniel Borkmann wrote:
> With regard to CPA_FLUSHTLB that Linus mentioned, when I investigated
> code paths in change_page_attr_set_clr(), I did see that CPA_FLUSHTLB
> was set each time we switched attrs and a cpa_flush_range() was
> performed (with the correct number of pages
On 03/09/2017 06:36 AM, Kees Cook wrote:
On Wed, Mar 8, 2017 at 3:55 PM, Laura Abbott wrote:
On 03/08/2017 02:36 PM, Kees Cook wrote:
On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
[ 28.474232] rodata_test: test data was not read only
[...]
In my tests so far, I've never been abl
On Wed, Mar 8, 2017 at 3:55 PM, Laura Abbott wrote:
> On 03/08/2017 02:36 PM, Kees Cook wrote:
>> On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
>>> [ 28.474232] rodata_test: test data was not read only
>>> [...]
>>
>> In my tests so far, I've never been able to get rodata_test to fail
On Wed, Mar 08, 2017 at 02:43:44PM -0800, Linus Torvalds wrote:
On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
The issue seems to be accessing buff first (can be read or write access)
and then doing set_memory_ro() doesn't make it read-only immediately,
meaning the subsequent call into
On 03/08/2017 02:36 PM, Kees Cook wrote:
> On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
>> [ 28.474232] rodata_test: test data was not read only
>> [...]
>
> In my tests so far, I've never been able to get rodata_test to fail
> (Qemu 2.5.0, Ubuntu). I'll retry with your .config and se
On 03/08/2017 11:36 PM, Kees Cook wrote:
On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
[ 28.474232] rodata_test: test data was not read only
[...]
In my tests so far, I've never been able to get rodata_test to fail
(Qemu 2.5.0, Ubuntu). I'll retry with your .config and see if I can
On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
>
> The issue seems to be accessing buff first (can be read or write access)
> and then doing set_memory_ro() doesn't make it read-only immediately,
> meaning the subsequent call into probe_kernel_write() will succeed without
> error.
>
> Then
On Wed, Mar 8, 2017 at 2:27 PM, Daniel Borkmann wrote:
> [ 28.474232] rodata_test: test data was not read only
> [...]
In my tests so far, I've never been able to get rodata_test to fail
(Qemu 2.5.0, Ubuntu). I'll retry with your .config and see if I can
recheck under Qemu 2.7.1. Do you see the
[ + Kees, Laura, and Dave ]
On 03/08/2017 08:25 PM, Linus Torvalds wrote:
Adding x86 people too, since this seems to be something off about
ARCH_HAS_SET_MEMORY for x86-32.
The code seems to be shared between x86-32 and 64, I'm not seeing why
set_memory_r[ow]() should fail on one but not the oth
Adding x86 people too, since this seems to be something off about
ARCH_HAS_SET_MEMORY for x86-32.
The code seems to be shared between x86-32 and 64, I'm not seeing why
set_memory_r[ow]() should fail on one but not the other.
Considering that it seems to be flaky even on 32-bit, maybe it's
timing-
On 03/02/2017 09:23 PM, Fengguang Wu wrote:
[...]
I confirm that the below patch provided by Daniel fixes the above
issues on mainline kernel, too. Where should this patch be sent to?
If nobody objects, I could send it to -net tree via Dave due to being
BPF related, but I don't mind sending it
On Wed, Mar 01, 2017 at 08:54:26PM +0800, Fengguang Wu wrote:
Hi all,
Is it BPF triggering BUGs all over the places?
It looks so, and here is a fix.
1e74a2eb1f Merge tag 'gcc-plugins-v4.11-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
005c3490e9 Revert "ath10k: Search S
31 matches
Mail list logo
