From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FBB2308F24 for ; Wed, 17 Sep 2025 21:15:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758143719; cv=none; b=oMA3yE/xzYPAjyNyD/rKlzIKlKHfb/iT3sBbPPjzbv+OPi9c4oFOP3P8IErA2FDkIjo5/GQL2IkH+BXs4hHUSNR2ngK7uhhioFFEOuei7btg10slFNrBd0MhSsWIclUaP9Nz6OJEiQR60RsL7QxBf6HXHeb2O0oAyRwcqxwui2M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758143719; c=relaxed/simple; bh=aOsBVV1Tpb4mhK2PfFogLLFA+uKbhmaEQcibYeJBiMc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YL6cu9lG3uAwLUk8hreQiR1GrXEVzXDEthqdDgTcO3+RUQQCRkHSodU4rdj2Aomwwc/0UQ8ZDrr3lYM+q3SaxDGI6Gv0M9OUKtq7s2TFtRSzpmLs1kfRI88yoRORLAC2o8l3YFeoH9HhQHoNY5Jcq8soxxh/9mnkLuh9OG0L7uQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fRT8zgYp; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fRT8zgYp" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b4e796ad413so213700a12.2 for ; Wed, 17 Sep 2025 14:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758143717; x=1758748517; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Zf/y0HmWPOZ3dErMq/oUtcRItkhIQW6aNr62qVpQuQM=; b=fRT8zgYpLgCO77DcdRAFmm6LMK8e+40lsvfGOFFM49bwqpaQDpb263GPYNnoD6fwcn yH+7uOA9paLVsq6oljCxhOp2sBRvf+8te+AJHfr586nBzU0A5mlr3ezGqzFJQlhdK2TM OuSoJZ7AVIkhNp/sVI4NzZqexVGAhNeo3Jzq/b1taiuqa5gbZzA8/D05EXjqfa6bIlCr /ayi5vSBx9nVXSfqjAdxsuG9gGSqiOIflPi/i0i/l+WGFfmJbrgZRJt5BkX6YvdF1SJa O+SRk/eallZVUTntgulkpNZM0otK4aBuct+PNQOFGQ1c64tXzyBPEyt5otst5wTQXoKl yGvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758143717; x=1758748517; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Zf/y0HmWPOZ3dErMq/oUtcRItkhIQW6aNr62qVpQuQM=; b=KYQQDH/pLcT3hHzQYUg13TeuVTnoQ+mBYVOciOjblLed/W0xx2fIVR+TOggoVPHJYI t9ilxLda+1G2fu3bs8Ha2cpVg93PHaG3i2y+RBeP4jsZmhjEDEs4U0wMkSfC1rsHEJ1E 1CUARNcUgvbUlVLTcQFLAUVP8asYYkCNIf3AI+UlAhSlSMY2tn88ar6A/3B7P1YOaeGg dcOGE+zyw6lz/N4d5ZKY9iOiWA5C9zPhbH9+l0fWFnQtFJ4RXIUTfXJXjjAmjxONOn1P NJzUUMW4+rde4lx7AwB3wI+AGKxIc0VkihiHrRzBzebbo2lH0/rT9b5IaFxflj/fBOev JeKQ== X-Forwarded-Encrypted: i=1; AJvYcCUbPWKzUgMBtrBNqtxxBtEmj5oaqMTlDUo0CXEuEi3Cqmdsk+cTc4G1BeQQrDS7x/cb4iQF9iMpinWEkps=@vger.kernel.org X-Gm-Message-State: AOJu0YwnMzLK8UxIg03TSv3OG281dIR27p5fQOVEv7DuZHsDnjVGan6L TipdXVWp2e8jw/hIaTHIKlwDBm6Uc2qdK0rGiPB8uDZp9hLDZROwTINOpRxeT3YOZznr5H7XI3M p2ruWuA== X-Google-Smtp-Source: AGHT+IEx2ToSGxWphNk2FKfxD2yst1MtFncBvHa8DVnpZZzTslJr/R25DqHaOFbX/k7CmOZUhV/Ax0gsm+0= X-Received: from pjbst3.prod.google.com ([2002:a17:90b:1fc3:b0:330:49f5:c0b1]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:3d89:b0:252:525c:2c2c with SMTP id adf61e73a8af0-27a9f267877mr5474946637.14.1758143717363; Wed, 17 Sep 2025 14:15:17 -0700 (PDT) Date: Wed, 17 Sep 2025 14:15:15 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250912232319.429659-1-seanjc@google.com> <20250912232319.429659-19-seanjc@google.com> Message-ID: Subject: Re: [PATCH v15 18/41] KVM: x86: Don't emulate instructions affected by CET features From: Sean Christopherson To: Chao Gao Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Tom Lendacky , Mathias Krause , John Allen , Rick Edgecombe , Maxim Levitsky , Xiaoyao Li , Zhang Yi Z Content-Type: text/plain; charset="us-ascii" On Wed, Sep 17, 2025, Chao Gao wrote: > On Fri, Sep 12, 2025 at 04:22:56PM -0700, Sean Christopherson wrote: > >From: Yang Weijiang > > > >Don't emulate branch instructions, e.g. CALL/RET/JMP etc., that are > >affected by Shadow Stacks and/or Indirect Branch Tracking when said > >features are enabled in the guest, as fully emulating CET would require > >significant complexity for no practical benefit (KVM shouldn't need to > >emulate branch instructions on modern hosts). Simply doing nothing isn't > >an option as that would allow a malicious entity to subvert CET > >protections via the emulator. > > > >Note! On far transfers, do NOT consult the current privilege level and > >instead treat SHSTK/IBT as being enabled if they're enabled for User *or* > >Supervisor mode. On inter-privilege level far transfers, SHSTK and IBT > >can be in play for the target privilege level, i.e. checking the current > >privilege could get a false negative, and KVM doesn't know the target > >privilege level until emulation gets under way. > > I modified KUT's cet.c to verify that near jumps, near returns, and far > transfers (e.g., IRET) trigger the emulation failure logic added by this > patch when guests enable Shadow Stack or IBT. > > I found only one minor issue: near return instructions were not tagged with > ShadowStack. Heh, I had just found this through inspection. > The following diff fixes this issue: > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > index e4be54a677b0..b1c9816bd5c6 100644 > --- a/arch/x86/kvm/emulate.c > +++ b/arch/x86/kvm/emulate.c > @@ -4326,8 +4326,8 @@ static const struct opcode opcode_table[256] = { > X8(I(DstReg | SrcImm64 | Mov, em_mov)), > /* 0xC0 - 0xC7 */ > G(ByteOp | Src2ImmByte, group2), G(Src2ImmByte, group2), > - I(ImplicitOps | NearBranch | SrcImmU16 | IsBranch, em_ret_near_imm), > - I(ImplicitOps | NearBranch | IsBranch, em_ret), > + I(ImplicitOps | NearBranch | SrcImmU16 | IsBranch | ShadowStack, em_ret_near_imm), > + I(ImplicitOps | NearBranch | IsBranch | ShadowStack, em_ret), Tangentially directly related to this bug, I think we should manual annotation where possible. I don't see an easy way to do that for ShadowStack, but for IBT we can use IsBranch, NearBranch and the SrcXXX operance to detect IBT-affected instructions. It's obviously more complex, but programmatically detecting indirect branches should be less error prone. I'll do so in the next version. > I(DstReg | SrcMemFAddr | ModRM | No64 | Src2ES, em_lseg), > I(DstReg | SrcMemFAddr | ModRM | No64 | Src2DS, em_lseg), > G(ByteOp, group11), G(0, group11), > > > And for reference, below are the changes I made to KUT's cet.c I now have a more comprehensive set of testcases, and it can be upstreamed (relies on KVM's default behavior of injecting #UD at CPL==3 on failed emulation).