On Sat, Apr 02, 2016 at 10:52:48PM +0200, Borislav Petkov wrote:
> On Sat, Apr 02, 2016 at 01:16:07PM -0700, Andy Lutomirski wrote:
> > I have no idea why it was explicitly unsupported, but I'm guessing it
> > was just to avoid duplicating the code. Early "ext" uaccess failures
> > are certainly not going to work, but I don't think this is a problem
> > -- there's no userspace before trap_init runs, so how exactly is an
> > "ext" uaccess going to happen in the first place?
> >
> > In any event, if it did happen in older kernels, it would have
> > immediately panicked due to that code. At least with my code it just
> > might manage to EFAULT correctly.
>
> Yeah, I was wondering what that early thing meant.
>
> Linus or tip guys probably remember what this whole deal with early
> uaccess was about. I'll try to do some git archeology tomorrow.
Yep, just as I suspected:
6a1ea279c210 ("x86, extable: Add early_fixup_exception()")
Apparently, thread_info might not have been setup yet. I'm guessing the
intention behind this no-uaccess-fixup-early is to not even attempt any
fixup due to stuff *probably* not initialized yet and so the safer thing
would be to panic instead.
I'm wondering whether making it try to EFAULT correctly is the right
thing to do... We're certainly more conservative if we panic and not
allow some silently failed attempt at recovery which looks successful,
to continue.
hpa, thoughts?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
