kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>, <kvm@vger.kernel.org>
Subject: Re: [kvm-unit-tests PATCH 1/8] x86: Avoid top-most page for vmalloc on x86-64
Date: Mon, 23 Jun 2025 12:50:36 +0800	[thread overview]
Message-ID: <aFjdHImRR1zEjpdf@intel.com> (raw)
In-Reply-To: <20250620153912.214600-2-minipli@grsecurity.net>

On Fri, Jun 20, 2025 at 05:39:05PM +0200, Mathias Krause wrote:
>The x86-64 implementation of setup_mmu() doesn't initialize 'vfree_top'
>and leaves it at its zero-value. This isn't wrong per se, however, it
>leads to odd configurations when the first vmalloc/vmap page gets
>allocated. It'll be the very last page in the virtual address space --
>which is an interesting corner case -- but its boundary will probably
>wrap. It does so for CET's shadow stack, at least, which loads the
>shadow stack pointer with the base address of the mapped page plus its
>size, i.e. 0xffffffff_fffff000 + 4096, which wraps to 0x0.
>
>The CPU seems to handle such configurations just fine. However, it feels
>odd to set the shadow stack pointer to "NULL".

Not sure if adjusting this is necessary. As a unit test, exercising this corner
case might be beneficial. But I don't have a strong opinion. So,

Reviewed-by: Chao Gao <chao.gao@intel.com>

>
>To avoid the wrapping, ignore the top most page by initializing
>'vfree_top' to just one page below.

Nit: this makes the comment in test_lam_sup() stale, specifically "KUT
initializes vfree_top to 0 for X86_64". So, that comment needs an update.

  reply	other threads:[~2025-06-23  4:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-20 15:39 [kvm-unit-tests PATCH 0/8] x86: CET fixes and enhancements Mathias Krause
2025-06-20 15:39 ` [kvm-unit-tests PATCH 1/8] x86: Avoid top-most page for vmalloc on x86-64 Mathias Krause
2025-06-23  4:50   ` Chao Gao [this message]
2025-06-20 15:39 ` [kvm-unit-tests PATCH 2/8] x86/cet: Fix flushing shadow stack mapping Mathias Krause
2025-06-20 15:39 ` [kvm-unit-tests PATCH 3/8] x86/cet: Use NONCANONICAL for non-canonical address Mathias Krause
2025-06-20 15:39 ` [kvm-unit-tests PATCH 4/8] x86/cet: Make shadow stack less fragile Mathias Krause
2025-06-20 15:39 ` [kvm-unit-tests PATCH 5/8] x86/cet: Avoid unnecessary function pointer casts Mathias Krause
2025-06-20 15:39 ` [kvm-unit-tests PATCH 6/8] x86/cet: Simplify IBT test Mathias Krause
2025-06-23  5:32   ` Chao Gao
2025-06-20 15:39 ` [kvm-unit-tests PATCH 7/8] x86/cet: Track and verify #CP error code Mathias Krause
2025-06-20 15:39 ` [kvm-unit-tests PATCH 8/8] x86/cet: Test far returns too Mathias Krause
2025-06-23  5:50   ` Chao Gao
2025-06-23  2:36 ` [kvm-unit-tests PATCH 0/8] x86: CET fixes and enhancements Chao Gao
2025-06-23 13:57   ` Mathias Krause
2025-06-23 14:17     ` Sean Christopherson
     [not found] <d6f116b2-1c42-4fde-831b-b23fa6791e74@grsecurity.net>
2025-06-23 20:28 ` [kvm-unit-tests PATCH 1/8] x86: Avoid top-most page for vmalloc on x86-64 Mathias Krause

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aFjdHImRR1zEjpdf@intel.com \
    --to=chao.gao@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=minipli@grsecurity.net \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).