Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935524AbcKVXSp (ORCPT ); Tue, 22 Nov 2016 18:18:45 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:36608 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933573AbcKVXSk (ORCPT ); Tue, 22 Nov 2016 18:18:40 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: [PATCH] KVM: x86: restore IP after all far jump failures From: Nadav Amit In-Reply-To: <20161122205600.GC12634@potion> Date: Tue, 22 Nov 2016 15:18:28 -0800 Cc: Paolo Bonzini , LKML , KVM list , stable@vger.kernel.org, Dmitry Vyukov , Steve Rutherford , Andrew Honig , Prasad Pandit Message-Id: <217EBCAE-2976-41C1-9F5C-4B54C1FB2D6E@gmail.com> References: <20161122192104.19836-1-rkrcmar@redhat.com> <20161122205600.GC12634@potion> To: =?utf-8?B?UmFkaW0gS3LEjW3DocWZ?= X-Mailer: Apple Mail (2.3251) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uAMNIoGH017400 Content-Length: 1565 Lines: 38 > On Nov 22, 2016, at 12:56 PM, Radim Krčmář wrote: > > 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). I don’t think so. If CPL is not 0, handle_emulation_failure() will be called and will inject #UD. > > 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? Most likely you are right, but after doing one mistake, I don’t want to be accountable for another. Note there is another problematic case in em_ret_far(). If an exception occurs when RIP is assigned, the RSP updates (of emulate_pop() ) are not going to be reverted. Can it be used for anything malicious? I don’t know. Nadav