From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934536AbcCOIto (ORCPT ); Tue, 15 Mar 2016 04:49:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58055 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932247AbcCOItd (ORCPT ); Tue, 15 Mar 2016 04:49:33 -0400 Subject: Re: [PATCH v3 3/5] x86/paravirt: Add paravirt_{read,write}_msr To: Andy Lutomirski , Linus Torvalds References: <56E6C492.5060308@redhat.com> Cc: xen-devel , Arjan van de Ven , X86 ML , Andrew Morton , KVM list , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Borislav Petkov From: Paolo Bonzini Message-ID: <56E7CC96.7080301@redhat.com> Date: Tue, 15 Mar 2016 09:49:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/03/2016 18:02, Andy Lutomirski wrote: > On Mon, Mar 14, 2016 at 9:58 AM, Linus Torvalds > wrote: >> >> On Mar 14, 2016 9:53 AM, "Andy Lutomirski" 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