Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3496710pxk; Mon, 28 Sep 2020 20:57:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/A5pjq5ZzgURndDOyhxPCJlqxNFr0pEfsn8g5c24ODCdtRCGAcb+XDNsqO9HKBn4Fc/lK X-Received: by 2002:a50:fe0f:: with SMTP id f15mr1113069edt.235.1601351867353; Mon, 28 Sep 2020 20:57:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601351867; cv=none; d=google.com; s=arc-20160816; b=nyEFyBIVinAnqbo8CPAINCCz6OsjO92ErDjHZJyqdeMxjxi5M51Qw1Lnw8QvyVzFwB ICQAIjeHFpODwyBmm7T1XXJvQrV8woI0C2NJB1CwRu1gZgBIlzpR8EhNxn+RA8rtdeVW Pf+K++s578VaOSZCMJBtvXuvRpO+dXs2li30e7Rfx06yEasn923T2xgrIzIXVTqRNYWB di4gLGEXVhlrIR/hRmEGWWdvDkzXd00MVyMcw6Kn914PEn0QtPHoF5NzVc9vXMuQB6p0 qFlTUnAjx0s2QeJYnq8ydju/zXNqdJ732SpvGdnp2q6YPoUxqaXXRxNlLKU8ymFxRrdM MzSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=8GoSxNICFnA5rsPUxFbAdLKBKi8BKZnbRs/jY3jKskA=; b=XClBixqs8Q72Nzdmn9K+/iHztCLJhTeJM0ZWwqcZc1Dgd7cGpT5uy2AftXStHBcZDa RNkdl1EMT1aYewVxIgpbDG7ElwdtGlk9FkGCdOH2CUoWlyfhYY9lUQ3YTJC9KWKZ0bHa lpWxkY0sZsRCQryfJRwRpHRhaZut7Di+tA8i2RPxlZ4NBFs66chOxlfS+ZC5VapKDf/O Y+pVHgTARdZYscLI5tTH+P3pAgSiCJRpTfSmPFn1xNgBAxUrLv1jiS2adU/iVjt65NTM Scr1zXw3f6wPV4jG3C8QMWS2tpnhX1e5EOiz3YQSAty47j4sftVvwzd84wEtoKbxmE4x qtxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c5si1887914ejs.330.2020.09.28.20.57.14; Mon, 28 Sep 2020 20:57:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727350AbgI2DxB (ORCPT + 99 others); Mon, 28 Sep 2020 23:53:01 -0400 Received: from mga17.intel.com ([192.55.52.151]:63648 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726064AbgI2DxB (ORCPT ); Mon, 28 Sep 2020 23:53:01 -0400 IronPort-SDR: PSaEE/V5kVTMc36yVcOWeJpjD34M9z807+uZ24Zso1zXqmppG7Q2ixEgmsccYYVMXTcpMy2Tmf pe4j83Qo97zg== X-IronPort-AV: E=McAfee;i="6000,8403,9758"; a="142130338" X-IronPort-AV: E=Sophos;i="5.77,316,1596524400"; d="scan'208";a="142130338" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 20:52:59 -0700 IronPort-SDR: hteUO/I0NkRZCWCqDL3H7Bh47P1tPJPqBYjCk6dgjVJo4jwAQFholEK4c5dCMLnGrHfNswXOR4 bEWpDRx0rI0A== X-IronPort-AV: E=Sophos;i="5.77,316,1596524400"; d="scan'208";a="457102758" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.160]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 20:52:59 -0700 Date: Mon, 28 Sep 2020 20:52:57 -0700 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Huacai Chen , Aleksandar Markovic , linux-mips@vger.kernel.org, Paul Mackerras , kvm-ppc@vger.kernel.org, Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda Subject: Re: [RFC PATCH 3/3] KVM: x86: Use KVM_BUG/KVM_BUG_ON to handle bugs that are fatal to the VM Message-ID: <20200929035257.GH31514@linux.intel.com> References: <20200923224530.17735-1-sean.j.christopherson@intel.com> <20200923224530.17735-4-sean.j.christopherson@intel.com> <878scze4l5.fsf@vitty.brq.redhat.com> <20200924181134.GB9649@linux.intel.com> <87k0wichht.fsf@vitty.brq.redhat.com> <20200925171233.GC31528@linux.intel.com> <731dd323-8c66-77ff-cf15-4bbdea34bcf9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <731dd323-8c66-77ff-cf15-4bbdea34bcf9@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 25, 2020 at 11:06:10PM +0200, Paolo Bonzini wrote: > On 25/09/20 19:12, Sean Christopherson wrote: > >> Do we actually want to prevent *all* ioctls? E.g. when 'vm bugged' > >> condition is triggered userspace may want to extract some information to > >> assist debugging but even things like KVM_GET_[S]REGS will just return > >> -EIO. I'm not sure it is generally safe to enable *everything* (except > >> for KVM_RUN which should definitely be forbidden) so maybe your approach > >> is preferable. > > > > The answer to this probably depends on the answer to the first question of > > when it's appropriate to use KVM_BUG(). E.g. if we limit usage to fatal or > > dangrous cases, then blocking all ioctls() is probably the right thing do do. > > I think usage should be limited to dangerous cases, basically WARN_ON > level. However I agree with Vitaly that KVM_GET_* should be allowed. Makes sense. On the topic of feedback from Vitaly, while dredging through my mailbox I rediscovered his suggestion of kvm->kvm_internal_bug (or maybe just kvm->internal_bug) instead of kvm->vm_bugged[*]. Like past me, I like the "internal" variants better. [*] https://lkml.kernel.org/r/20190930153358.GD14693@linux.intel.com > The other question is whether to return -EIO or KVM_EXIT_INTERNAL_ERROR. > The latter is more likely to be handled already by userspace. And probably less confusing for unsuspecting users. E.g. -EIO is most likely to be interpreted as "I screwed up", whereas KVM_EXIT_INTERNAL_ERROR will correctly be read as "KVM screwed up".