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
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
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
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
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
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
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, 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,
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,
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
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
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?
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
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
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
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
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: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
>
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
>
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)
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)
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 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)
> >
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)
> >
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
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
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
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
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 nail that down.
Just a brain dump of what I've found out so
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 nail that down.
Just a brain dump of what I've found out so
34 matches
Mail list logo
