From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:58132 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752159AbcKVU4x (ORCPT ); Tue, 22 Nov 2016 15:56:53 -0500 Date: Tue, 22 Nov 2016 21:56:01 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Nadav Amit Cc: Paolo Bonzini , LKML , KVM list , stable@vger.kernel.org, Dmitry Vyukov , Steve Rutherford , Andrew Honig , Prasad Pandit Subject: Re: [PATCH] KVM: x86: restore IP after all far jump failures Message-ID: <20161122205600.GC12634@potion> References: <20161122192104.19836-1-rkrcmar@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: 2016-11-22 11:43-0800, Nadav Amit: > I admit my wrongdoings, but I still think the fix should have been to > remove the entire recovery logic and just return X86EMUL_UNHANDLEABLE if > something goes wrong (exception). This will kill the misbehaving process > but keep the VM running. X86EMUL_UNHANDLEABLE will kill the whole VM (on QEMU, other userspaces might handle the instruction and resume KVM). The recovery path is in the spec, which means that nothing goes wrong. I think we implement the spec quite well now, so keeping the #GP and CS recovery is slightly better, although not safer. > Otherwise, a malicious VM process, which can somehow control descriptors > (LDT?) may modify the descriptor during the emulation and get the system > to inconsistent state and prevent the VM-entry. We restore the original CS -- malicious guest would get killed on a failed VM entry anyway, so the difference is only in KVM internal error code (assuming there are no other bugs). Am I misunderstanding something?