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 ---
>> INTERRUPT-TO-INNER-PRIVILEGE:
>>    [...]
>>    TF := 0;
>>    NT := 0;
>> --- snip ---
>> (Doesn't say anything about HW interrupts though)
>>
>> This also makes sense at my opinion, since the interrupt handler has
>> to know if it should return to the previous task (when NT=1) or to
>> the same task (when NT=0).
> 
> No, it does not. Simply because Linux does not support nested tasks at
> all, because the TSS is not accessible and the TSS.back_link is
> sturdily NULL. So even if it would not explode with a #GP in IA-32e
> mode it would explode while trying to execute the instruction at NULL.

Sure, I also mentioned this in my last mail:

On 29.09.2014 20:30, Sebastian Lackner wrote:
> NT flag would be interpreted as a task return, and it would probably cause a 
> different exception,
> because the kernel never uses the task link property of the TSS.

> 
>> That might be possible. It probably makes sense to review other
>> parts of the code, for similar issues.
> 
> What's the issue? Stupid user space programs segfaulting?

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 code. Return 
instructions also don't show this issue all the time, just when it hits one of 
the problematic pieces of code.

* The kernel might execute all kind of other code (for example inside of 
drivers) and start additional threads. I didn't find any good example yet, but 
its not that unlikely, that the exception can also happen in a completely 
unrelated thread, where the kernel can not just kill the corresponding usermode 
app...

I'm fine with all kind of solutions, either it should be allowed to set NT, or 
the kernel should at least throw a proper exception, so that usermode has a 
chance to catch and handle it. At the moment the segfault is deadly, as the 
segfault handler immediately segfaults again - no chance to recover from such 
an error.

Regards,
Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to