On Mon, Sep 29, 2014 at 2:37 PM, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Andy Lutomirski wrote:
>> On Mon, Sep 29, 2014 at 12:41 PM, Thomas Gleixner wrote:
>> > On Mon, 29 Sep 2014, Andy Lutomirski wrote:
>> >> On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner
>> >> wrote:
>> >> > On Mon,
On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> On Mon, Sep 29, 2014 at 12:41 PM, Thomas Gleixner wrote:
> > On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> >> On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner
> >> wrote:
> >> > On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> >> >> Presumably interrup
On Mon, Sep 29, 2014 at 1:01 PM, H. Peter Anvin wrote:
> On 09/29/2014 12:57 PM, Thomas Gleixner wrote:
>>
>>> I think we should mask the bit anyway.
>>
>> I tend to disagree. If we clear it there we need to consequentely
>> audit ALL other possibilites and if there are any we need to clear the
>>
On Mon, Sep 29, 2014 at 12:41 PM, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Andy Lutomirski wrote:
>> On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner wrote:
>> > On Mon, 29 Sep 2014, Andy Lutomirski wrote:
>> >> Presumably interrupt delivery clears NT. I haven't spotted where that's
>> >>
On Mon, 29 Sep 2014, H. Peter Anvin wrote:
> On 09/29/2014 12:57 PM, Thomas Gleixner wrote:
> >
> >> I think we should mask the bit anyway.
> >
> > I tend to disagree. If we clear it there we need to consequentely
> > audit ALL other possibilites and if there are any we need to clear the
> > bit
On 09/29/2014 12:57 PM, Thomas Gleixner wrote:
>
>> I think we should mask the bit anyway.
>
> I tend to disagree. If we clear it there we need to consequentely
> audit ALL other possibilites and if there are any we need to clear the
> bit there as well. Just to make buggy user space happy?
>
On Mon, 29 Sep 2014, H. Peter Anvin wrote:
> On 09/29/2014 12:41 PM, Thomas Gleixner wrote:
> >>
> >> If it weren't the case, then we'd be totally screwed. Fortunately, it
> >> is. I found it: SDM Volume 3 6.12.1.2 says:
> >>
> >> (On calls to exception and interrupt
> >> handlers, the processor
On Mon, 29 Sep 2014, Sebastian Lackner wrote:
> I see several issues here:
>
> * At first the behaviour is not consistent between several system
> call and return instructions. For example calling syscalls by using
> 'int' doesn't have this issue, as it clears the NT flag before
> entering kernel
On 09/29/2014 12:41 PM, Thomas Gleixner wrote:
>>
>> If it weren't the case, then we'd be totally screwed. Fortunately, it
>> is. I found it: SDM Volume 3 6.12.1.2 says:
>>
>> (On calls to exception and interrupt
>> handlers, the processor also clears the VM, RF, and NT flags in the
>> EFLAGS reg
On 29.09.2014 21:33, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Sebastian Lackner wrote:
>> On 29.09.2014 19:40, Andy Lutomirski wrote:
>> Well, the best documentation I've found is something like
>> http://www.fermimn.gov.it/linux/quarta/x86/int.htm
>>
>> which states:
>>
>> --- snip ---
>> INT
On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner wrote:
> > On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> >> Presumably interrupt delivery clears NT. I haven't spotted where that's
> >> documented yet.
> >
> > Nope, that's unrelated.
>
> If it weren
On Mon, 29 Sep 2014, Sebastian Lackner wrote:
> On 29.09.2014 19:40, Andy Lutomirski wrote:
> Well, the best documentation I've found is something like
> http://www.fermimn.gov.it/linux/quarta/x86/int.htm
>
> which states:
>
> --- snip ---
> INTERRUPT-TO-INNER-PRIVILEGE:
>[...]
>TF := 0;
On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Andy Lutomirski wrote:
>> Presumably interrupt delivery clears NT. I haven't spotted where that's
>> documented yet.
>
> Nope, that's unrelated.
If it weren't the case, then we'd be totally screwed. Fortunately, it
On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner wrote:
> On Mon, 29 Sep 2014, Andy Lutomirski wrote:
>> On 09/25/2014 12:42 PM, Anish Bhatt wrote:
>> > The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
>> > syscall entry, should also clear the nested task (NT) flag to b
On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> On 09/25/2014 12:42 PM, Anish Bhatt wrote:
> > The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
> > syscall entry, should also clear the nested task (NT) flag to be safe from
> > userspace injection. Without this fix the appl
On Mon, Sep 29, 2014 at 11:30 AM, Sebastian Lackner
wrote:
> On 29.09.2014 19:40, Andy Lutomirski wrote:
>> On 09/25/2014 12:42 PM, Anish Bhatt wrote:
>>> The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
>>> syscall entry, should also clear the nested task (NT) flag to b
On 29.09.2014 19:40, Andy Lutomirski wrote:
> On 09/25/2014 12:42 PM, Anish Bhatt wrote:
>> The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
>> syscall entry, should also clear the nested task (NT) flag to be safe from
>> userspace injection. Without this fix the applica
On 09/25/2014 12:42 PM, Anish Bhatt wrote:
> The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
> syscall entry, should also clear the nested task (NT) flag to be safe from
> userspace injection. Without this fix the application segmentation
> faults on syscall return bec
On 09/25/2014 04:00 PM, Chuck Ebbert wrote:
> #include
> #include
>
> int main()
> {
> asm volatile("pushfq \n\t" \
>"pop %rax \n\t" \
>"or $0x4000,%rax \n\t" \
>"push %rax\n\t" \
>"p
On Fri, Sep 26, 2014 at 3:00 PM, Chuck Ebbert wrote:
>
> I don't get it. Why isn't this patch acceptable, at least on x86-64
> where NT is never valid?
Why do you think it's not acceptable? Why do you raise a stink *one*
day after the patch - that seems to not be very important - is sent
out?
Wh
; Linus
> Torvalds
> Subject: Re: [PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry
>
> On Thu, 25 Sep 2014 12:42:51 -0700
> Anish Bhatt wrote:
>
> > The MSR_SYSCALL_MASK, which is responsible for clearing specific
> > EFLAGS on syscall entry, should also cle
On Thu, 25 Sep 2014 12:42:51 -0700
Anish Bhatt wrote:
> The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
> syscall entry, should also clear the nested task (NT) flag to be safe from
> userspace injection. Without this fix the application segmentation
> faults on sysca
On Thu, 25 Sep 2014 12:42:51 -0700
Anish Bhatt wrote:
> The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
> syscall entry, should also clear the nested task (NT) flag to be safe from
> userspace injection. Without this fix the application segmentation
> faults on sysca
23 matches
Mail list logo
