[lkml]   [2018]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86/entry/64: Fix CR3 restore order in paranoid_exit()

* Josh Poimboeuf <> wrote:

> I haven't actually seen any real-world bugs caused by this, so I'm not
> sure how theoretical it is. I just stumbled upon it in code review when
> looking for another bug.

I believe it's a real bug, but the fix is wrong with irq tracing or lockdep
enabled as Dave points out.

I think the reason we haven't seen this bug yet is that "paranoid" entry points
are limited to:

idtentry double_fault do_double_fault has_error_code=1 paranoid=2
idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
idtentry machine_check do_mce has_error_code=0 paranoid=1

Only machine_check is one that will interrupt an IRQS-off critical section
asynchronously - and machine check events are rare.

The other main asynchronous entries are NMI entries, which can be very high-freq
with perf profiling, but they are special: they don't use the 'idtentry' macro but
are open coded and restore user CR3 unconditionally so don't seem to have this



 \ /
  Last update: 2018-02-14 08:36    [W:0.058 / U:1.152 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site