From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 B3F6B19E975 for ; Tue, 23 Sep 2025 15:04:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758639888; cv=none; b=dY87P/GPCVWX27WLKn9xIcdbACc+WKulRU74Jjh4G65STqq4vQGoUTtNr2UsHuoTJu2+IHeEKfMn8q4drR7AP6pkRTplKckEa+h8wwsC7nMPwdC3yJcGC9ZRVmZfbPGPFiBdYhMrkNbRbOyjK7OENNITiRAzx4lU2c41qxGaaJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758639888; c=relaxed/simple; bh=ozbjkzsxrfDX5twIBmcTO2kHly5O52Kundnyuo+ro30=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bbIWz4ZxWdD1N9hPjcUWeliNczXtSOLWybdczeLc2zGgrf+DfznVK4U6Hds5/VKR7Zxvg/bTFypLyXDb+jO9WZ4Y4+RLVr7x1zS7AvbGfg44XE5Oz/F1vNCrpEYTYAEJTpr76I6ANQVfOFButmx3+AJlf/QcXbcaFkXYnT1jSpA= 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=TZkEjTGb; arc=none smtp.client-ip=209.85.214.201 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="TZkEjTGb" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2697c4e7354so55815375ad.0 for ; Tue, 23 Sep 2025 08:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758639886; x=1759244686; 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=ErECzswpmXilrcdrqAzLrqqOTo2DOFzxXEwQQ/WZhFU=; b=TZkEjTGbTXzsIa3SiFaheml5bXlNHtUwac+3yWdW46MRtKjEqTLUXqgLnWzQAOZDIT lFPxz98OQqXm+GZExC8zaXWf2QPh+8lifBwdnuyTFZV1kuW7yqr0fXXVE3ZcErJjaAkO fodudtlZIF7IU3BnoRKfVNDqzUCrEtqajtBBGETeDHLsqK8lB7hTx6w48yBlmRm031x1 9r+jSEXpF7ejbyWVUsw0UJzdTSKELFWJ8CLi9Dr+QtlWU8APLOqxkM3UV4CWvw3AQIkf uj6CkQwYROF9w9Hd0oW0/BAiSvPA/Iofm2RWelHtv8fgUCFyvic0crhtaU+zOTRu+GQS 1NyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758639886; x=1759244686; 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=ErECzswpmXilrcdrqAzLrqqOTo2DOFzxXEwQQ/WZhFU=; b=WbJxBVe+dE+oHMOIz0XXw89k40vXWAn09RdJeWMIB+kqfDpwgfpx5w4Pvu0yX0zlt5 5tNfA76WYAhT4lF7KMNUyX2AuO+JhxEi0KAat0QJh7CAmG4hksjXpIjEyDQPyVgbwnGy qYTOuGXjVMeTLpiQpzeqM9E4sXSq22XkE5P87Kfk3lyiageiJF962wJQZSvl3h15i5xv rqrxW1PwTmSWGUnjtU1cokvi0wkF7LamlwdVrSTEbLAy1zpsF066DBr5Ee6TL61MVPZU pJ1uwvKcn/08o6ssajrx2L7LPocV2RfjQpo7f9U8Dyblx8H7xyzWLyT0X22ftWHpCyYm rivQ== X-Forwarded-Encrypted: i=1; AJvYcCX1QquiGATzFelYbwdX1ooFhufFyP5N+KKdiFePjOi2Dy9ozl4bwzqYRt6kN+AUO91Lx7H0TNwZmKfsgXw=@vger.kernel.org X-Gm-Message-State: AOJu0YyPEyjsPMGIA4AziUdRiq1kcY6LRt8VYRGDX1FMpPZMs8sWR6S1 xay2cclAJr0eWJ5dV00wf078sfxi6zjCFmMjPV4XJZMU1/sqncBMqp4vdguKbs0CyT7hlIEyRzq wXIJloA== X-Google-Smtp-Source: AGHT+IF4ZDboFmV40ApjmHOAmwOGV2D+zkJJCq8GgZtfkHMqT5N+FHSoPo4NgY8Mi/pKYS+mmYiwXpjMrwQ= X-Received: from pjbsj18.prod.google.com ([2002:a17:90b:2d92:b0:32e:a3c3:df27]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ecce:b0:26c:4280:4860 with SMTP id d9443c01a7336-27cd7268870mr34596895ad.8.1758639886056; Tue, 23 Sep 2025 08:04:46 -0700 (PDT) Date: Tue, 23 Sep 2025 08:04:44 -0700 In-Reply-To: <5dbc1100-6685-4eac-aa04-07f5621d3979@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250919223258.1604852-1-seanjc@google.com> <20250919223258.1604852-28-seanjc@google.com> <5dbc1100-6685-4eac-aa04-07f5621d3979@intel.com> Message-ID: Subject: Re: [PATCH v16 27/51] KVM: x86: Disable support for IBT and SHSTK if allow_smaller_maxphyaddr is true From: Sean Christopherson To: Xiaoyao Li Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Tom Lendacky , Mathias Krause , John Allen , Rick Edgecombe , Chao Gao , Binbin Wu , Maxim Levitsky , Zhang Yi Z , Xin Li Content-Type: text/plain; charset="us-ascii" On Tue, Sep 23, 2025, Xiaoyao Li wrote: > On 9/20/2025 6:32 AM, Sean Christopherson wrote: > > Make IBT and SHSTK virtualization mutually exclusive with "officially" > > supporting setups with guest.MAXPHYADDR < host.MAXPHYADDR, i.e. if the > > allow_smaller_maxphyaddr module param is set. Running a guest with a > > smaller MAXPHYADDR requires intercepting #PF, and can also trigger > > emulation of arbitrary instructions. Intercepting and reacting to #PFs > > doesn't play nice with SHSTK, as KVM's MMU hasn't been taught to handle > > Shadow Stack accesses, and emulating arbitrary instructions doesn't play > > nice with IBT or SHSTK, as KVM's emulator doesn't handle the various side > > effects, e.g. doesn't enforce end-branch markers or model Shadow Stack > > updates. > > > > Note, hiding IBT and SHSTK based solely on allow_smaller_maxphyaddr is > > overkill, as allow_smaller_maxphyaddr is only problematic if the guest is > > actually configured to have a smaller MAXPHYADDR. However, KVM's ABI > > doesn't provide a way to express that IBT and SHSTK may break if enabled > > in conjunction with guest.MAXPHYADDR < host.MAXPHYADDR. I.e. the > > alternative is to do nothing in KVM and instead update documentation and > > hope KVM users are thorough readers. > > KVM_SET_CPUID* can return error to userspace. So KVM can return -EINVAL when > userspace sets a smaller maxphyaddr with SHSTK/IBT enabled. Generally speaking, I don't want to police userspace's vCPU model. For allow_smaller_maxphyaddr in particular, I want to actively discourage its use. The entire concept is inherently flawed, e.g. only works for a relative narrow use case. And IIRC, Sierra Forest and future Atom-based server CPUs will be straight up incompatible with allow_smaller_maxphyaddr due to them setting accessed/dirty bits before generating the EPT Violation, which is what killed allow_smaller_maxphyaddr with NPT. I.e. allow_smaller_maxphyaddr is doomed, and I want to help it die. If someone really, really wants to enable CET on hosts with allow_smaller_maxphyaddr=true, then they can send patches and we can sort out how to communicate the various incompatibilities to userspace.