[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr
On 14/03/2016 18:02, Andy Lutomirski wrote: > On Mon, Mar 14, 2016 at 9:58 AM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> On Mar 14, 2016 9:53 AM, "Andy Lutomirski" <luto@xxxxxxxxxxxxxx> wrote: >>> >>> Can you clarify? KVM uses the native version, and the native version >>> only oopses with this series applied if panic_on_oops is set. >> >> Can we please remove that idiocy? >> >> There is no reason to panic whatsoever. Seriously. What's the upside of that >> logic? > > I imagine that people who set panic_on_oops want their systems to stop > running user code if something happens that could corrupt the state or > if there's any sign that user code is trying some non-deterministic > exploit. So I'm guessing that they'd want this type of "the kernel > screwed up -- abort" to actually result in a panic. > > As a concrete, although somewhat silly, example, suppose that a write > to MSR_SYSENTER_STACK fails. If that happened, then user code could > subsequently try to take over the kernel by evil manipulation of TF > and/or perf. > > I'd be okay with removing this too, though, since arranging for MSR > access to fail seems unlikely as an exploit vector. > > Borislav: SUSE actually uses panic_on_oops, right? What's their goal? RHEL also does, and it's mostly to trap kernel page faults before they do more damage such as filesystem corruption. The debug kernel has panic_on_oops=0, while the production kernel has panic_on_oops=1. Paolo _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |