On Mon, Oct 8, 2018 at 2:37 PM Thomas Gleixner wrote:
>
> Paul,
>
> On Fri, 5 Oct 2018, Paul Menzel wrote:
> > On 10/05/18 11:27, Thomas Gleixner wrote:
> > > If pcibios is enabled and used, need to look at the gory details of that
> > > first, then the W+X check has to exclude that region. We can
Paul,
On Fri, 5 Oct 2018, Paul Menzel wrote:
> On 10/05/18 11:27, Thomas Gleixner wrote:
> > If pcibios is enabled and used, need to look at the gory details of that
> > first, then the W+X check has to exclude that region. We can't do much
> > about that.
>
> That would also explain, why it only
Dear Thomas,
On 10/05/18 11:27, Thomas Gleixner wrote:
> On Thu, 4 Oct 2018, Joerg Roedel wrote:
>
>> On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
>>> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick di
On Thu, 4 Oct 2018, Joerg Roedel wrote:
> On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
> > On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
> > > Sorry for the delay and thanks for the data. A quick diff did not reveal
> > > anything obvious. I'll have a closer
On Thu, Oct 04, 2018 at 01:00:42PM +0200, Paul Menzel wrote:
> While here you write, it did not.
Read again what I said:
> and I did try marking the ISA range RO in mark_rodata_ro() but the
> machine wouldn't boot after.
and the code I pasted has this:
// init_memory_mapping(0, ISA
Dear Borislav,
On 10/04/18 12:54, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:59:18AM +0200, Paul Menzel wrote:
>> I meant just the test you did.
>
> https://lkml.kernel.org/r/20181003212255.gb28...@zn.tnic
I see. But there you write, the machine does boot.
While here you write, it did
On Thu, Oct 04, 2018 at 10:59:18AM +0200, Paul Menzel wrote:
> I meant just the test you did.
https://lkml.kernel.org/r/20181003212255.gb28...@zn.tnic
> The SSD is also used in the Lenovo X60 and T60, which are
> 32-bit systems.
And what exactly is the problem when you access it on a 64-bit OS?
Dear Borislav,
On 10/04/18 10:49, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
>> Do you have a commit, I could test.
>
> Not yet
I meant just the test you did.
> but I have a question for you: why are you running 32-bit and
> haven't moved to 64-bit al
On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
> Do you have a commit, I could test.
Not yet but I have a question for you: why are you running 32-bit and
haven't moved to 64-bit already?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the r
On Thu, Oct 04, 2018 at 10:43:18AM +0200, Joerg Roedel wrote:
> Yeah, that's what I also found out back then, the region needs to be WX.
> So we can either leave with the warning, as we know it is harmless and
> where it comes from or implement an exception in the checking code for
> that region.
On Thu, Oct 04, 2018 at 10:14:38AM +0200, Borislav Petkov wrote:
> So looking at this, BIOS_BEGIN and BIOS_END is the same range as the ISA
> range:
>
> #define ISA_START_ADDRESS 0x000a
> #define ISA_END_ADDRESS 0x0010
>
> #define BIOS_BEGIN 0x000a
> #define
Dear Borislav,
On 10/04/18 10:14, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
>> I also triggered this when working in the PTI-x32 code. It always
>> happens on a 32-bit PAE kernel for me.
>>
>> Tracking it down I ended up in (iirc) arch/x86/mm/pageattr.
On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
> I also triggered this when working in the PTI-x32 code. It always
> happens on a 32-bit PAE kernel for me.
>
> Tracking it down I ended up in (iirc) arch/x86/mm/pageattr.c
> function static_protections():
>
> /*
>
On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
> > Sorry for the delay and thanks for the data. A quick diff did not reveal
> > anything obvious. I'll have a closer look and we probably need more (other)
> > inform
On Thu, Oct 04, 2018 at 05:11:17AM +0200, Paul Menzel wrote:
> Thank you for looking into this. On what board are you able to reproduce
> this? Do you build for 32-bit or 64-bit?
32-bit partition on an AMD F14h laptop.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posti
Dear Borislav,
Am 03.10.2018 um 23:22 schrieb Borislav Petkov:
On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick diff did not reveal
anything obvious. I'll have a closer look and we probably need more (other)
information to nai
warning reports to:
[ 4.392870] x86/mm: Found insecure W+X mapping at address
0xc000/0xc000
but the machine boots fine otherwise.
Which begs the question: why do we direct-map the ISA range at
PAGE_OFFSET at all? Do we have to have virtual mappings of it at all? I
thought ISA devices
On Tue, Jul 18, 2017 at 02:11:35PM +0200, Thomas Gleixner wrote:
> On Tue, 18 Jul 2017, Piotr Gregor wrote:
> >
> > Dmesg reports insecure W+X mapping found at address
> > 8805f000/0x8805f000
> >
> > on 4.4.70 kernel patched with -rt83 patch:
>
> Does the same problem happen with
On Tue, 18 Jul 2017, Piotr Gregor wrote:
>
> Dmesg reports insecure W+X mapping found at address
> 8805f000/0x8805f000
>
> on 4.4.70 kernel patched with -rt83 patch:
Does the same problem happen with a plain 4.4.70? as well?
Thanks,
tglx
-[ cut here ]
[5.039672] WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225
note_page+0x61e/0x7e0()
[5.039673] x86/mm: Found insecure W+X mapping at address
8805f000/0x8805f000
[5.039674] Modules linked in:
[5.039677] CPU: 1 PID: 1 Comm: swapper
On Tue, 23 May 2017, Steven Rostedt wrote:
> On Tue, 23 May 2017 22:48:19 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > It's not KPROBES, it's the new fangled ftrace trampoline code. I
> > added a few printks. All the leaked W+X mappings are allocated via
> > this callchain:
>
> The trampoline
On Tue, 23 May 2017 22:48:19 +0200 (CEST)
Thomas Gleixner wrote:
> It's not KPROBES, it's the new fangled ftrace trampoline code. I
> added a few printks. All the leaked W+X mappings are allocated via
> this callchain:
The trampoline code isn't new. But it has new users because of the
introduct
On Tue, 23 May 2017, Thomas Gleixner wrote:
> On Tue, 23 May 2017, Kees Cook wrote:
> > On Tue, May 23, 2017 at 8:40 AM, Thomas Gleixner wrote:
> > > As of 4.12-rc1 one of my machines triggers the insecure W+X mapping.
> >
> > > It's consistenly 9 entries close to the beginning of the module space
On Tue, 23 May 2017, Kees Cook wrote:
> On Tue, May 23, 2017 at 8:40 AM, Thomas Gleixner wrote:
> > As of 4.12-rc1 one of my machines triggers the insecure W+X mapping.
>
> > It's consistenly 9 entries close to the beginning of the module space,
> > before the first actual module starts. See below
On Tue, May 23, 2017 at 8:40 AM, Thomas Gleixner wrote:
> As of 4.12-rc1 one of my machines triggers the insecure W+X mapping.
>
> It's consistenly 9 entries close to the beginning of the module space,
> before the first actual module starts. See below.
>
> Any ideas which avoid bisecting would be
As of 4.12-rc1 one of my machines triggers the insecure W+X mapping.
It's consistenly 9 entries close to the beginning of the module space,
before the first actual module starts. See below.
Any ideas which avoid bisecting would be appreciated.
Thanks,
tglx
---[ Modules ]---
0xc
kernel: x86/mm: Found insecure W+X mapping at
address 8800/0x8800
Jan 20 17:43:49 x001 kernel: Modules linked in:
Jan 20 17:43:49 x001 kernel: CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.4.0-3.g0567b9b-default #1
Jan 20 17:43:49 x001 kernel
1744K (880001e4c000 -
> 88000200)
> [ 15.380507] [ cut here ]
> [ 15.380746] WARNING: CPU: 4 PID: 1 at
> arch/x86/mm/dump_pagetables.c:225 note_page+0x619/0x7e0()
> [ 15.381208] x86/mm: Found insecure W+X mapping at address
> a000/0xa
28 matches
Mail list logo
