On Tue, Dec 15, 2015 at 11:07:09PM +0100, Pavel Machek wrote:
> Mystery solved, and prize goes to the lguest.
But that splat has nowhere lguest in it. Are you saying, you don't see
any more splats if you disable lguest?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On Tue 2015-12-15 22:33:59, Borislav Petkov wrote:
> On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote:
> > [0.00] Base memory trampoline at [c009b000] 9b000 size 16384
> > [0.00] [ cut here ]
> > [0.00] WARNING: CPU: 0 PID: 0 at
> >
On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote:
> [0.00] Base memory trampoline at [c009b000] 9b000 size 16384
> [0.00] [ cut here ]
> [0.00] WARNING: CPU: 0 PID: 0 at
> ./arch/x86/include/asm/pgtable.h:357
Hi!
> > I tried applying:
> >
> > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
> > paging
> >
> > but I still get
> >
> > [2.691897] x86/mm: Found insecure W+X mapping at address
> > ffe69000/0xffe69000
>
> This may be an insane suggestion, but how about we try to
On Tue, Dec 15, 2015 at 11:06:38AM -0800, Linus Torvalds wrote:
> We want to *warn* about PAGE_RW without PAGE_NX. No?
Ah yes, we do:
note_page:
...
if (st->check_wx && (pr & _PAGE_RW) && !(pr & _PAGE_NX)) {
I got confused, sorry.
--
Regards/Gruss,
Boris.
ECO tip #101:
On Tue, Dec 15, 2015 at 10:40 AM, Andy Lutomirski wrote:
>
> Shouldn't we switch those two lines?
No. This is for debugging Pavel's issue. If somehow the
__supported_pte_mask ends up having NX clear again (memory scribble,
whatever), we very explicitly would want to catch that.
I'm *not*
On Tue, Dec 15, 2015 at 10:30 AM, Borislav Petkov wrote:
> On Tue, Dec 15, 2015 at 09:45:40AM -0800, Linus Torvalds wrote:
>>
>> +static inline int kernel_write_execute_prot(pgprotval_t protval)
>> +{
>> + return !(protval & _PAGE_USER) &&
>> + !(protval & _PAGE_NX) &&
On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek wrote:
>
> I tried applying:
>
> [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
> paging
>
> but I still get
>
> [2.691897] x86/mm: Found insecure W+X mapping at address
> ffe69000/0xffe69000
This may be an insane
On Tue 2015-12-15 08:28:12, H. Peter Anvin wrote:
> On 12/15/15 06:08, Pavel Machek wrote:
> >
> > But it still says:
> >
> > address sizes : 32 bits physical, 32 bits virtual
> >
> > I thought pae would be 36bit virtual?
> >
>
> It should be unless the CPU reports otherwise, which your
On Tue, Dec 15, 2015 at 9:45 AM, Linus Torvalds
wrote:
> On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek wrote:
>>
>> I tried applying:
>>
>> [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
>> paging
>>
>> but I still get
>>
>> [2.691897] x86/mm: Found insecure W+X
On Tue, Dec 15, 2015 at 09:45:40AM -0800, Linus Torvalds wrote:
> On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek wrote:
> >
> > I tried applying:
> >
> > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
> > paging
> >
> > but I still get
> >
> > [2.691897] x86/mm: Found
On 12/15/15 06:08, Pavel Machek wrote:
>
> But it still says:
>
> address sizes : 32 bits physical, 32 bits virtual
>
> I thought pae would be 36bit virtual?
>
It should be unless the CPU reports otherwise, which your CPU probably
does (a CPUID dump might be useful.)
-hpa
--
To
On Tue 2015-12-15 05:26:00, Arjan van de Ven wrote:
> On 12/14/2015 11:56 PM, Pavel Machek wrote:
> >On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
> >>
> >>>That's weird. The only API to do that seems to be manually setting
> >>>kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why
On 12/14/2015 11:56 PM, Pavel Machek wrote:
On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
That's weird. The only API to do that seems to be manually setting
kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
kmap_prot a variable on x86 at all? It has exactly one writer,
On Mon 2015-12-14 14:25:10, Andy Lutomirski wrote:
> On Mon, Dec 14, 2015 at 1:24 PM, Arjan van de Ven
> wrote:
> >
> >> That's weird. The only API to do that seems to be manually setting
> >> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
> >> kmap_prot a variable on x86 at
On 12/15/15 06:08, Pavel Machek wrote:
>
> But it still says:
>
> address sizes : 32 bits physical, 32 bits virtual
>
> I thought pae would be 36bit virtual?
>
It should be unless the CPU reports otherwise, which your CPU probably
does (a CPUID dump might be useful.)
-hpa
--
To
On Tue, Dec 15, 2015 at 9:45 AM, Linus Torvalds
wrote:
> On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek wrote:
>>
>> I tried applying:
>>
>> [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
>> paging
>>
>> but I still get
>>
>> [
On Tue, Dec 15, 2015 at 11:06:38AM -0800, Linus Torvalds wrote:
> We want to *warn* about PAGE_RW without PAGE_NX. No?
Ah yes, we do:
note_page:
...
if (st->check_wx && (pr & _PAGE_RW) && !(pr & _PAGE_NX)) {
I got confused, sorry.
--
Regards/Gruss,
Boris.
ECO tip #101:
On Tue, Dec 15, 2015 at 10:40 AM, Andy Lutomirski wrote:
>
> Shouldn't we switch those two lines?
No. This is for debugging Pavel's issue. If somehow the
__supported_pte_mask ends up having NX clear again (memory scribble,
whatever), we very explicitly would want to catch
On Tue, Dec 15, 2015 at 09:45:40AM -0800, Linus Torvalds wrote:
> On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek wrote:
> >
> > I tried applying:
> >
> > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
> > paging
> >
> > but I still get
> >
> > [2.691897]
On Tue 2015-12-15 08:28:12, H. Peter Anvin wrote:
> On 12/15/15 06:08, Pavel Machek wrote:
> >
> > But it still says:
> >
> > address sizes : 32 bits physical, 32 bits virtual
> >
> > I thought pae would be 36bit virtual?
> >
>
> It should be unless the CPU reports otherwise, which your
On Tue, Dec 15, 2015 at 10:30 AM, Borislav Petkov wrote:
> On Tue, Dec 15, 2015 at 09:45:40AM -0800, Linus Torvalds wrote:
>>
>> +static inline int kernel_write_execute_prot(pgprotval_t protval)
>> +{
>> + return !(protval & _PAGE_USER) &&
>> +
On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek wrote:
>
> I tried applying:
>
> [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
> paging
>
> but I still get
>
> [2.691897] x86/mm: Found insecure W+X mapping at address
> ffe69000/0xffe69000
This may be an
On Mon 2015-12-14 14:25:10, Andy Lutomirski wrote:
> On Mon, Dec 14, 2015 at 1:24 PM, Arjan van de Ven
> wrote:
> >
> >> That's weird. The only API to do that seems to be manually setting
> >> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
> >> kmap_prot
On Tue 2015-12-15 22:33:59, Borislav Petkov wrote:
> On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote:
> > [0.00] Base memory trampoline at [c009b000] 9b000 size 16384
> > [0.00] [ cut here ]
> > [0.00] WARNING: CPU: 0 PID: 0 at
> >
On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote:
> [0.00] Base memory trampoline at [c009b000] 9b000 size 16384
> [0.00] [ cut here ]
> [0.00] WARNING: CPU: 0 PID: 0 at
> ./arch/x86/include/asm/pgtable.h:357
On Tue, Dec 15, 2015 at 11:07:09PM +0100, Pavel Machek wrote:
> Mystery solved, and prize goes to the lguest.
But that splat has nowhere lguest in it. Are you saying, you don't see
any more splats if you disable lguest?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On 12/14/2015 11:56 PM, Pavel Machek wrote:
On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
That's weird. The only API to do that seems to be manually setting
kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
kmap_prot a variable on x86 at all? It has exactly one writer,
Hi!
> > I tried applying:
> >
> > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling
> > paging
> >
> > but I still get
> >
> > [2.691897] x86/mm: Found insecure W+X mapping at address
> > ffe69000/0xffe69000
>
> This may be an insane suggestion, but how about we try to
On Tue 2015-12-15 05:26:00, Arjan van de Ven wrote:
> On 12/14/2015 11:56 PM, Pavel Machek wrote:
> >On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
> >>
> >>>That's weird. The only API to do that seems to be manually setting
> >>>kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why
On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
>
> >That's weird. The only API to do that seems to be manually setting
> >kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
> >kmap_prot a variable on x86 at all? It has exactly one writer, and
> >that's the code that
On Mon, Dec 14, 2015 at 1:24 PM, Arjan van de Ven wrote:
>
>> That's weird. The only API to do that seems to be manually setting
>> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
>> kmap_prot a variable on x86 at all? It has exactly one writer, and
>> that's the code that
That's weird. The only API to do that seems to be manually setting
kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
kmap_prot a variable on x86 at all? It has exactly one writer, and
that's the code that initializes it in the first place. Shouldn't we
#define kmap_prot
On Mon, Dec 14, 2015 at 12:26 PM, Pavel Machek wrote:
> Hi!
>
>> > I know. But either someone cares, and it should be fixes, or noone
>> > cares, and the check should be removed.
>>
>> Someone cares, and it should be scheduled to be fixed for 4.5. The EFI
>> mapping changes that were required to
Hi!
> > I know. But either someone cares, and it should be fixes, or noone
> > cares, and the check should be removed.
>
> Someone cares, and it should be scheduled to be fixed for 4.5. The EFI
> mapping changes that were required to avoid the warning were much too
> big and late to make 4.4.
>
On Mon, Dec 14, 2015 at 1:07 AM, Pavel Machek wrote:
>
> I know. But either someone cares, and it should be fixes, or noone
> cares, and the check should be removed.
Someone cares, and it should be scheduled to be fixed for 4.5. The EFI
mapping changes that were required to avoid the warning
On Mon 2015-12-14 09:04:03, Pavel Machek wrote:
> Hi!
>
> > Kernel complains:
>
> And now, we are at -rc5, and kernel still complains...
>
> ...with a back trace, which is clearly completely useless, and just
> there to make it scary and make people report.
>
> Problem is... noone cares for
On Mon, Dec 14, 2015 at 10:07:26AM +0100, Pavel Machek wrote:
> I know. But either someone cares, and it should be fixes, or noone
> cares, and the check should be removed.
Someone cares.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this
On Mon 2015-12-14 09:58:03, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 09:04:03AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > Kernel complains:
> >
> > And now, we are at -rc5, and kernel still complains...
>
> You can disable CONFIG_DEBUG_WX in your .config:
>
> 54727e6e950a ("x86:
On Mon, Dec 14, 2015 at 09:04:03AM +0100, Pavel Machek wrote:
> Hi!
>
> > Kernel complains:
>
> And now, we are at -rc5, and kernel still complains...
You can disable CONFIG_DEBUG_WX in your .config:
54727e6e950a ("x86: don't make DEBUG_WX default to 'y' even with DEBUG_RODATA")
--
On Mon 2015-12-14 09:04:03, Pavel Machek wrote:
> Hi!
>
> > Kernel complains:
>
> And now, we are at -rc5, and kernel still complains...
>
> ...with a back trace, which is clearly completely useless, and just
> there to make it scary and make people report.
>
> Problem is... noone cares for
On Mon, Dec 14, 2015 at 10:07:26AM +0100, Pavel Machek wrote:
> I know. But either someone cares, and it should be fixes, or noone
> cares, and the check should be removed.
Someone cares.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this
On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
>
> >That's weird. The only API to do that seems to be manually setting
> >kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
> >kmap_prot a variable on x86 at all? It has exactly one writer, and
> >that's the code that
Hi!
> > I know. But either someone cares, and it should be fixes, or noone
> > cares, and the check should be removed.
>
> Someone cares, and it should be scheduled to be fixed for 4.5. The EFI
> mapping changes that were required to avoid the warning were much too
> big and late to make 4.4.
>
On Mon 2015-12-14 09:58:03, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 09:04:03AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > Kernel complains:
> >
> > And now, we are at -rc5, and kernel still complains...
>
> You can disable CONFIG_DEBUG_WX in your .config:
>
> 54727e6e950a ("x86:
On Mon, Dec 14, 2015 at 1:07 AM, Pavel Machek wrote:
>
> I know. But either someone cares, and it should be fixes, or noone
> cares, and the check should be removed.
Someone cares, and it should be scheduled to be fixed for 4.5. The EFI
mapping changes that were required to avoid
On Mon, Dec 14, 2015 at 1:24 PM, Arjan van de Ven wrote:
>
>> That's weird. The only API to do that seems to be manually setting
>> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
>> kmap_prot a variable on x86 at all? It has exactly one writer, and
>>
On Mon, Dec 14, 2015 at 12:26 PM, Pavel Machek wrote:
> Hi!
>
>> > I know. But either someone cares, and it should be fixes, or noone
>> > cares, and the check should be removed.
>>
>> Someone cares, and it should be scheduled to be fixed for 4.5. The EFI
>> mapping changes that
That's weird. The only API to do that seems to be manually setting
kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is
kmap_prot a variable on x86 at all? It has exactly one writer, and
that's the code that initializes it in the first place. Shouldn't we
#define kmap_prot
On Mon, Dec 14, 2015 at 09:04:03AM +0100, Pavel Machek wrote:
> Hi!
>
> > Kernel complains:
>
> And now, we are at -rc5, and kernel still complains...
You can disable CONFIG_DEBUG_WX in your .config:
54727e6e950a ("x86: don't make DEBUG_WX default to 'y' even with DEBUG_RODATA")
--
50 matches
Mail list logo