On Wed, Sep 5, 2018 at 2:35 PM, Dave Hansen wrote:
> On 09/04/2018 02:27 PM, Andy Lutomirski wrote:
>> Also, I doubt it matters right here, but !X86_PF_USER isn't quite the
>> same thing as "originating from kernel code" -- it can also be user
>> code that does a CPL0 access due to exception deliv
On 09/04/2018 02:27 PM, Andy Lutomirski wrote:
> Also, I doubt it matters right here, but !X86_PF_USER isn't quite the
> same thing as "originating from kernel code" -- it can also be user
> code that does a CPL0 access due to exception delivery or access to a
> descriptor table. Which you saw ple
On Tue, Sep 4, 2018 at 2:21 PM, Dave Hansen wrote:
> On 09/04/2018 12:56 PM, Andy Lutomirski wrote:
>> I have no objection to this patch.
>>
>> Dave, why did you think that we could get a PK fault on the vsyscall
>> page, even on kernels that still marked it executable? Sure, you
>> could get an
On 09/04/2018 12:56 PM, Andy Lutomirski wrote:
> I have no objection to this patch.
>
> Dave, why did you think that we could get a PK fault on the vsyscall
> page, even on kernels that still marked it executable? Sure, you
> could get an instruction in the vsyscall page to get a PK fault, but
>
On Tue, Sep 4, 2018 at 12:50 PM, Sean Christopherson
wrote:
> Cc-ing Jann and Andy.
>
> On Tue, Aug 07, 2018 at 10:29:20AM -0700, Sean Christopherson wrote:
>> Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
>> isn't enforced, and so we should never see X86_PF_PK set on a
>> kernel
Cc-ing Jann and Andy.
On Tue, Aug 07, 2018 at 10:29:20AM -0700, Sean Christopherson wrote:
> Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
> isn't enforced, and so we should never see X86_PF_PK set on a
> kernel address fault. WARN once to capture the issue in case we
> somehow
> On Aug 30, 2018, at 7:38 PM, Jann Horn wrote:
>
>> On Tue, 7 Aug 2018 Dave Hansen wrote:
>>
>>> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
>>> if (unlikely(fault_in_kernel_space(address))) {
>>> + /*
>>> + * We should never encounter a protection keys
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel addr
On 08/30/2018 03:40 AM, Thomas Gleixner wrote:
> Given the time span you should be close to ground water with your digging
> by now.
So, turns out that we start our spurious_fault() code with this check:
> if (error_code != (X86_PF_WRITE | X86_PF_PROT) &&
> error_code != (X86_
On Tue, 7 Aug 2018, Dave Hansen wrote:
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > +* We should never encounter a protection keys fault on a
> > +* kernel address as kernel address are al
On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> if (unlikely(fault_in_kernel_space(address))) {
> + /*
> + * We should never encounter a protection keys fault on a
> + * kernel address as kernel address are always mapped with
> + * _PAGE
Kernel addresses are always mapped with _PAGE_USER=0, i.e. PKRU
isn't enforced, and so we should never see X86_PF_PK set on a
kernel address fault. WARN once to capture the issue in case we
somehow don't die, e.g. the access originated in userspace.
Remove a similar check and its comment from spu
12 matches
Mail list logo
