From 93de2a6a4b91b72607136dd656edf03fb399d27f Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Wed, 23 Sep 2026 09:37:21 -0700 Subject: KVM: SEV: Do cache maintenance on the source VM during intra-host migration Manually perform cache maintenance on the source VM during intra-host migration to ensure no stale data is left in CPU caches after the VM is destroyed. Because the source VM is "converted" to a non-SEV VM, KVM's memory reclaim flows won't trigger cache maintenance, e.g. when all guest memory is reclaimed in response to detaching from the mmu_notifier. Note, relying on the destination VM to do cache maintenance isn't an option as KVM doesn't require identical guest memory configurations, i.e. the source VM may have access to memory that the destination VM does not. Enforcing equivalent memory configurations is infeasible, as it would require a *deep* comparison of memslots, e.g. to verify that not only are the memslot identical, but what the memslots point at is also identical. Fixes: b56639318bb2 ("KVM: SEV: Add support for SEV intra host migration") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson Message-ID: <20260923163721.1584779-3-seanjc@google.com> Signed-off-by: Paolo Bonzini --- Documentation/crypto/intro.rst | 74 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/crypto/intro.rst (limited to 'Documentation/crypto/intro.rst') diff --git a/Documentation/crypto/intro.rst b/Documentation/crypto/intro.rst new file mode 100644 index 000000000..9aa89ebbf --- /dev/null +++ b/Documentation/crypto/intro.rst @@ -0,0 +1,74 @@ +Kernel Crypto API Interface Specification +========================================= + +Introduction +------------ + +The kernel crypto API offers a rich set of cryptographic ciphers as well +as other data transformation mechanisms and methods to invoke these. +This document contains a description of the API and provides example +code. + +To understand and properly use the kernel crypto API a brief explanation +of its structure is given. Based on the architecture, the API can be +separated into different components. Following the architecture +specification, hints to developers of ciphers are provided. Pointers to +the API function call documentation are given at the end. + +The kernel crypto API refers to all algorithms as "transformations". +Therefore, a cipher handle variable usually has the name "tfm". Besides +cryptographic operations, the kernel crypto API also knows compression +transformations and handles them the same way as ciphers. + +The kernel crypto API serves the following entity types: + +- consumers requesting cryptographic services + +- data transformation implementations (typically ciphers) that can be + called by consumers using the kernel crypto API + +This specification is intended for consumers of the kernel crypto API as +well as for developers implementing ciphers. This API specification, +however, does not discuss all API calls available to data transformation +implementations (i.e. implementations of ciphers and other +transformations (such as CRC or even compression algorithms) that can +register with the kernel crypto API). + +Note: The terms "transformation" and cipher algorithm are used +interchangeably. + +Terminology +----------- + +The transformation implementation is an actual code or interface to +hardware which implements a certain transformation with precisely +defined behavior. + +The transformation object (TFM) is an instance of a transformation +implementation. There can be multiple transformation objects associated +with a single transformation implementation. Each of those +transformation objects is held by a crypto API consumer or another +transformation. Transformation object is allocated when a crypto API +consumer requests a transformation implementation. The consumer is then +provided with a structure, which contains a transformation object (TFM). + +The structure that contains transformation objects may also be referred +to as a "cipher handle". Such a cipher handle is always subject to the +following phases that are reflected in the API calls applicable to such +a cipher handle: + +1. Initialization of a cipher handle. + +2. Execution of all intended cipher operations applicable for the handle + where the cipher handle must be furnished to every API call. + +3. Destruction of a cipher handle. + +When using the initialization API calls, a cipher handle is created and +returned to the consumer. Therefore, please refer to all initialization +API calls that refer to the data structure type a consumer is expected +to receive and subsequently to use. The initialization API calls have +all the same naming conventions of crypto_alloc\*. + +The transformation context is private data associated with the +transformation object. -- cgit v1.3.1