Snp host latest #6

Replace open coded functionalify of kstrdup_and_replace() with a call. Link: https://lkml.kernel.org/r/20240213162741.3102810-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Jason Baron <jbaron@akamai.com> Cc: Jim Cromie <jim.cromie@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Found with git grep 'MODULE_AUTHOR(".*([^)]*@' Fixed with sed -i '/MODULE_AUTHOR(".*([^)]*@/{s/ (/ </g;s/)"/>"/;s/)and/> and/}' \ $(git grep -l 'MODULE_AUTHOR(".*([^)]*@') Also: in drivers/media/usb/siano/smsusb.c normalise ", INC" to ", Inc"; this is what every other MODULE_AUTHOR for this company says, and it's what the header says in drivers/sbus/char/openprom.c normalise a double-spaced separator; this is clearly copied from the copyright header, where the names are aligned on consecutive lines thusly: * Linux/SPARC PROM Configuration Driver * Copyright (C) 1996 Thomas K. Dyas (tdyas@noc.rutgers.edu) * Copyright (C) 1996 Eddie C. Dost (ecd@skynet.be) but the authorship branding is single-line Link: https://lkml.kernel.org/r/mk3geln4azm5binjjlfsgjepow4o73domjv6ajybws3tz22vb3@tarta.nabijaczleweli.xyz Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Since commit aed65af ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Make sure that new usages of the struct already enter the tree as const. Link: https://lkml.kernel.org/r/20240218-device_cleanup-checkpatch-v1-1-8b0b89c4f6b1@marliere.net Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Bring the PDF build fix into docs-next so we can ... build PDFs

…inux/kernel/git/akpm/mm

…ernel/git/arm64/linux

…/git/soc/soc.git

…/git/geert/linux-m68k.git

…/powerpc/linux.git

…/s390/linux.git

…netdev/net.git

…t/bpf/bpf.git

…t/klassert/ipsec.git

…git/wireless/wireless.git

…t/rdma/rdma.git

…/git/tiwai/sound.git

…/git/broonie/regulator.git

…/git/gregkh/tty.git

…/git/gregkh/usb.git

…/phy/linux-phy.git

…kernel/git/wbg/counter.git

…kernel/git/gregkh/char-misc.git

…/westeri/thunderbolt.git

…t/herbert/crypto-2.6.git

…/vkoul/dmaengine.git

…/git/mtd/linux.git

…/cxl/cxl.git

…l/git/kdave/linux.git

…/viro/vfs.git

…/mkp/scsi.git

…/ulfh/mmc.git

…nel/git/hyperv/linux.git

…ernel/git/conor/linux.git

…kernel/git/conor/linux.git

…/kernel/git/brgl/linux.git

…el/git/shuah/linux-kselftest.git

…t/efi/efi.git

…/sre/linux-power-supply.git

…t/jgg/iommufd.git

…/ulfh/linux-pm.git

…ux/kernel/git/andi.shyti/linux.git

…drm/drm-misc # Conflicts: # drivers/gpu/drm/tests/drm_buddy_test.c

…rnel/git/akpm/mm

…git/masahiroy/linux-kbuild.git

…kernel/git/perf/perf-tools-next.git

…t/arnd/asm-generic.git

…rnel/git/arm64/linux

…rnel/git/will/linux.git

…git/soc/soc.git

…git/amlogic/linux.git

…git/joel/bmc.git

…/git/at91/linux.git

…git/shawnguo/linux.git

…git/mediatek/linux.git

…git/gclement/mvebu.git

…git/tmlind/linux-omap.git

…git/qcom/linux.git

…geert/renesas-devel.git

…git/mmind/linux-rockchip.git

…git/krzk/linux.git

…ernel/git/sudeep.holla/linux.git

…l/git/atorgue/stm32.git

…ernel/git/sunxi/linux.git

…inux-tee.git

…git/tegra/linux.git

…it/ti/linux.git

…git/clk/linux.git

…el/git/geert/renesas-drivers.git

…/git/mips/linux.git

…git/deller/parisc-linux.git

…powerpc/linux.git

…git/riscv/linux.git # Conflicts: # arch/riscv/include/asm/bitops.h

…x/kernel/git/conor/linux.git

…git/s390/linux.git

…t/glaubitz/sh-linux.git

…nsa.git

…nux.git

…git/kdave/linux.git

….git

…tyhicks/ecryptfs.git

…inkinjeon/exfat.git

…rnel/git/cel/linux

…git/jack/linux-fs.git

…aegeuk/f2fs.git

…inux.git

…/git/cel/linux

…git/hubcap/linux

…kernel/git/ericvh/v9fs.git

…nux.git

…git/dlemoal/zonefs.git

…it/vfs/vfs.git

…git/printk/linux.git

…pci/pci.git

…kernel/git/kees/linux.git

…git/hid/hid.git

…nel/git/andi.shyti/linux.git

…git/i3c/linux.git

…l/git/groeck/linux-staging.git

# Conflicts: # drivers/staging/media/atomisp/pci/atomisp_cmd.c

…l/git/rafael/linux-pm.git

…/linux/kernel/git/vireshk/pm.git

…git/shuah/linux.git

…ulfh/linux-pm.git

…ernel/git/vireshk/pm.git

…git/rdma/rdma.git

…netdev/net-next.git

…git/bpf/bpf-next.git

…t/klassert/ipsec-next.git

…t/bluetooth/bluetooth-next.git

…git/wireless/wireless-next.git # Conflicts: # drivers/net/wireless/intel/iwlwifi/mvm/mvm.h

…git/mtd/linux.git

…/git/mtd/linux.git

…t/herbert/cryptodev-2.6.git

# Conflicts: # drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c # drivers/gpu/drm/amd/display/dc/hwss/hw_sequencer_private.h # drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c

…m-misc

…/msm.git

…git/deller/linux-fbdev.git

…git/broonie/regmap.git

…git/tiwai/sound.git

…l/git/ieee1394/linux1394.git

…git/broonie/sound.git

…nel/git/mcgrof/linux.git

…dtor/input.git

# Conflicts: # block/blk.h # include/linux/sched.h

…git/device-mapper/linux-dm.git

…git/libata/linux

…el/git/brodo/linux.git

…ulfh/mmc.git # Conflicts: # drivers/mmc/core/queue.c

…nel/git/lee/mfd.git

…ux/kernel/git/lee/backlight.git

…git/sre/linux-power-supply.git

…git/broonie/regulator.git

…pcmoore/lsm.git

…ernel/git/zohar/linux-integrity

…pcmoore/selinux.git

…jarkko/linux-tpmdd.git

…joro/iommu.git

…pcmoore/audit.git

…git/robh/linux.git # Conflicts: # Documentation/devicetree/bindings/trivial-devices.yaml

…git/krzk/linux-dt.git

…git/broonie/spi.git

…t/tip/tip.git

…iel.lezcano/linux.git

…rnel/git/ras/ras.git

…git/trace/linux-trace.git

…git/paulmck/linux-rcu.git

…kvmarm/kvmarm.git # Conflicts: # arch/arm64/kernel/cpufeature.c

…kvms390/linux.git

…git/dennis/percpu.git

…git/tj/wq.git

…git/pdx86/platform-drivers-x86.git

…x/kernel/git/chrome-platform/linux.git

…git/sre/linux-hsi.git

…rnel/git/lee/leds.git

…/kernel/git/gregkh/driver-core.git

…git/gregkh/usb.git # Conflicts: # Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml # drivers/usb/roles/class.c

…westeri/thunderbolt.git

…git/gregkh/tty.git

…ernel/git/gregkh/char-misc.git

…kernel/git/ogabbay/linux.git

…coresight/linux.git

…git/fpga/linux-fpga.git

…git/djakov/icc.git

…t/jic23/iio.git # Conflicts: # drivers/of/property.c

…phy/linux-phy.git # Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-usb.c

…vkoul/soundwire.git

…git/krzk/linux-w1.git

…nel/git/gregkh/staging.git

…nel/git/wbg/counter.git

…vkoul/dmaengine.git

…git/tj/cgroup.git

…git/jejb/scsi.git

…git/mkp/scsi.git

…git/remoteproc/linux.git # Conflicts: # drivers/remoteproc/imx_dsp_rproc.c

…rnel/git/brgl/linux.git # Conflicts: # Documentation/userspace-api/index.rst

…git/linusw/linux-pinctrl.git

…kernel/git/geert/renesas-drivers.git

…nel/git/ukleinek/linux.git

…shuah/linux-kselftest.git

…/shuah/linux-kselftest.git

…git/livepatching/livepatching

…ux/kernel/git/nvdimm/nvdimm.git

…/kernel/git/kees/linux.git

…joel/fsi.git

…git/srini/slimbus.git

…git/srini/nvmem.git

…git/andy/linux-auxdisplay.git

…git/mani/mhi.git

…git/krisman/unicode.git

…rnel/git/vbabka/slab.git

…mic/linux.git

# Conflicts: # Documentation/process/changes.rst

…el/git/sysctl/sysctl.git

…kernel/git/kees/linux.git

# Conflicts: # drivers/block/null_blk/main.c # drivers/tty/serial/sc16is7xx.c

…rnel/git/kees/linux.git

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Extended guest_memfd to allow backing guest memory with hugepages. This is done as a best-effort by default until a better-defined mechanism is put in place that can provide better control/assurances to userspace about hugepage allocations. When reporting the max order when KVM gets a pfn from guest_memfd, force order-0 pages if the hugepage is not fully contained by the memslot binding, e.g. if userspace requested hugepages but punches a hole in the memslot bindings in order to emulate x86's VGA hole. Link: https://lore.kernel.org/kvm/20231027182217.3615211-1-seanjc@google.com/T/#mccbd3e8bf9897f0ddbf864e6318d6f2f208b269c Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20231027182217.3615211-18-seanjc@google.com> [Allow even with CONFIG_TRANSPARENT_HUGEPAGE; dropped momentarily due to uneasiness about the API. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [mdr: based on discussion in the Link regarding original patch, make the following set of changes: - For now, don't introduce an opt-in flag to enable hugepage support. By default, just make a best-effort for PMD_ORDER allocations so that there are no false assurances to userspace that they'll get hugepages. It's better at least than the current guarantee that they will get 4K pages every time. A more proper opt-in interface can then improve on things later. - Pass GFP_NOWARN to alloc_pages() so failures are not disruptive to normal operations - Drop size checks during creation time. Instead just avoid huge allocations if they extend beyond end of the memfd. - Drop hugepage-related unit tests since everything is now handled transparently to userspace anyway. - Update commit message accordingly.] Signed-off-by: Michael Roth <michael.roth@amd.com>

filemap users like guest_memfd may use page cache pages to allocate/manage memory that is only intended to be accessed by guests via hardware protections like encryption. Writes to memory of this sort in common paths like truncation may cause unexpected behavior such writing garbage instead of zeros when attempting to zero pages, or worse, triggering hardware protections that are considered fatal as far as the kernel is concerned. Introduce a new address_space flag, AS_INACCESSIBLE, and use this initially to prevent zero'ing of pages during truncation, with the understanding that it is up to the owner of the mapping to handle this specially if needed. Link: https://lore.kernel.org/lkml/ZR9LYhpxTaTk6PJX@google.com/ Cc: Matthew Wilcox <willy@infradead.org> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

truncate_inode_pages_range() may attempt to zero pages before truncating them, and this will occur before arch-specific invalidations can be triggered via .invalidate_folio/.free_folio hooks via kvm_gmem_aops. For AMD SEV-SNP this would result in an RMP #PF being generated by the hardware, which is currently treated as fatal (and even if specifically allowed for, would not result in anything other than garbage being written to guest pages due to encryption). On Intel TDX this would also result in undesirable behavior. Set the AS_INACCESSIBLE flag to prevent the MM from attempting unexpected accesses of this sort during operations like truncation. This may also in some cases yield a decent performance improvement for guest_memfd userspace implementations that hole-punch ranges immediately after private->shared conversions via KVM_SET_MEMORY_ATTRIBUTES, since the current implementation of truncate_inode_pages_range() always ends up zero'ing an entire 4K range if it is backing by a 2M folio. Link: https://lore.kernel.org/lkml/ZR9LYhpxTaTk6PJX@google.com/ Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

guest_memfd pages are generally expected to be in some arch-defined initial state prior to using them for guest memory. For SEV-SNP this initial state is 'private', or 'guest-owned', and requires additional operations to move these pages into a 'private' state by updating the corresponding entries the RMP table. Allow for an arch-defined hook to handle updates of this sort, and go ahead and implement one for x86 so KVM implementations like AMD SVM can register a kvm_x86_ops callback to handle these updates for SEV-SNP guests. The preparation callback is always called when allocating/grabbing folios via gmem, and it is up to the architecture to keep track of whether or not the pages are already in the expected state (e.g. the RMP table in the case of SEV-SNP). In some cases, it is necessary to defer the preparation of the pages to handle things like in-place encryption of initial guest memory payloads before marking these pages as 'private'/'guest-owned', so also add a helper that performs the same function as kvm_gmem_get_pfn(), but allows for the preparation callback to be bypassed to allow for pages to be accessed beforehand. Link: https://lore.kernel.org/lkml/ZLqVdvsF11Ddo7Dq@google.com/ Signed-off-by: Michael Roth <michael.roth@amd.com>

In some cases, like with SEV-SNP, guest memory needs to be updated in a platform-specific manner before it can be safely freed back to the host. Wire up arch-defined hooks to the .free_folio kvm_gmem_aops callback to allow for special handling of this sort when freeing memory in response to FALLOC_FL_PUNCH_HOLE operations and when releasing the inode, and go ahead and define an arch-specific hook for x86 since it will be needed for handling memory used for SEV-SNP guests. Signed-off-by: Michael Roth <michael.roth@amd.com>

In some cases the full 64-bit error code for the KVM page fault will be needed to determine things like whether or not a fault was for a private or shared guest page, so update related code to accept the full 64-bit value so it can be plumbed all the way through to where it is needed. The accessors of fault->error_code are changed as follows: - FNAME(page_fault): change to explicitly use lower_32_bits() since that is no longer done in kvm_mmu_page_fault() - kvm_mmu_page_fault(): explicit mask with PFERR_RSVD_MASK, PFERR_NESTED_GUEST_PAGE - mmutrace: changed u32 -> u64 Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Link: https://lore.kernel.org/kvm/20230612042559.375660-1-michael.roth@amd.com/T/#mbd0b20c9a2cf50319d5d2a27b63f73c772112076 [mdr: drop references/changes to code not in current gmem tree, update commit message] Signed-off-by: Michael Roth <michael.roth@amd.com>

In some cases, such as detecting whether a page fault should be handled as a private fault or not, KVM will need to handle things differently versus the existing KVM_X86_PROTECTED_VM type. Add a new KVM_X86_SNP_VM to allow for this, along with a helper to query the vm_type. Signed-off-by: Michael Roth <michael.roth@amd.com>

When SEV-SNP is enabled globally, the hardware places restrictions on all memory accesses based on the RMP entry, whether the hypervisor or a VM, performs the accesses. When hardware encounters an RMP access violation during a guest access, it will cause a #VMEXIT(NPF) with a number of additional bits set to indicate the reasons for the #NPF. Define those here. See APM2 section 16.36.10 for more details. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: add some additional details to commit message] Signed-off-by: Michael Roth <michael.roth@amd.com>

For KVM_X86_SNP_VM, only the PFERR_GUEST_ENC_MASK flag is needed to determine with an #NPF is due to a private/shared access by the guest. Implement that handling here. Also add handling needed to deal with SNP guests which in some cases will make MMIO accesses with the encryption bit. Signed-off-by: Michael Roth <michael.roth@amd.com>

SEV-SNP relies on restricted/protected memory support to run guests, so make sure to enable that support via the CONFIG_KVM_GENERIC_PRIVATE_MEM config option. Signed-off-by: Michael Roth <michael.roth@amd.com>

Add support for AP Reset Hold being invoked using the GHCB MSR protocol, available in version 2 of the GHCB specification. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

Version 2 of the GHCB specification introduced advertisement of features that are supported by the Hypervisor. Now that KVM supports version 2 of the GHCB specification, bump the maximum supported protocol version. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

The next generation of SEV is called SEV-SNP (Secure Nested Paging). SEV-SNP builds upon existing SEV and SEV-ES functionality while adding new hardware-based security protection. SEV-SNP adds strong memory encryption and integrity protection to help prevent malicious hypervisor-based attacks such as data replay, memory re-mapping, and more, to create an isolated execution environment. Implement some initial infrastructure in KVM to check/report when SNP is enabled on the system. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: commit fixups, use similar ASID reporting as with SEV/SEV-ES] Signed-off-by: Michael Roth <michael.roth@amd.com>

TODO: move to using common KVM_SEV_INIT2 interface. The flag discovery mechanism also needs to be changed since it provides no mechanism for discovery outside of trying to trigger the error path by guessing at unimplemented flags. May went to leverage something similar to the KVM_SEV_INIT2 VMSA feature machinery for this as well which involves a KVM device ioctl to return the feature bitmap. The KVM_SNP_INIT command is used by the hypervisor to initialize the SEV-SNP platform context. In a typical workflow, this command should be the first command issued. When creating SEV-SNP guest, the VMM must use this command instead of the KVM_SEV_INIT or KVM_SEV_ES_INIT. The flags value must be zero, it will be extended in future SNP support to communicate the optional features (such as restricted INT injection etc). Co-developed-by: Pavan Kumar Paluri <papaluri@amd.com> Signed-off-by: Pavan Kumar Paluri <papaluri@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

KVM_SEV_SNP_LAUNCH_START begins the launch process for an SEV-SNP guest. The command initializes a cryptographic digest context used to construct the measurement of the guest. If the guest is expected to be migrated, the command also binds a migration agent (MA) to the guest. For more information see the SEV-SNP specification. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: hold sev_deactivate_lock when calling SEV_CMD_SNP_DECOMMISSION] Signed-off-by: Michael Roth <michael.roth@amd.com>

The KVM_SEV_SNP_LAUNCH_UPDATE command can be used to insert data into the guest's memory. The data is encrypted with the cryptographic context created with the KVM_SEV_SNP_LAUNCH_START. In addition to the inserting data, it can insert a two special pages into the guests memory: the secrets page and the CPUID page. While terminating the guest, reclaim the guest pages added in the RMP table. If the reclaim fails, then the page is no longer safe to be released back to the system and leak them. For more information see the SEV-SNP specification. Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>

TODO: see if ID block / Author Key enabled bits can be set automatically rather than exposed directly via KVM API. See if there are other opportunities to architect things in user-facing APIs. The KVM_SEV_SNP_LAUNCH_FINISH finalize the cryptographic digest and stores it as the measurement of the guest at launch. While finalizing the launch flow, it also issues the LAUNCH_UPDATE command to encrypt the VMSA pages. If its an SNP guest, then VMSA was added in the RMP entry as a guest owned page and also removed from the kernel direct map so flush it later after it is transitioned back to hypervisor state and restored in the direct map. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Harald Hoyer <harald@profian.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: always measure BSP first to get consistent launch measurements] Signed-off-by: Michael Roth <michael.roth@amd.com>

SEV-SNP guests are required to perform a GHCB GPA registration. Before using a GHCB GPA for a vCPU the first time, a guest must register the vCPU GHCB GPA. If hypervisor can work with the guest requested GPA then it must respond back with the same GPA otherwise return -1. On VMEXIT, verify that the GHCB GPA matches with the registered value. If a mismatch is detected, then abort the guest. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

SEV-SNP VMs can ask the hypervisor to change the page state in the RMP table to be private or shared using the Page State Change MSR protocol as defined in the GHCB specification. When using gmem, private/shared memory is allocated through separate pools, and KVM relies on userspace issuing a KVM_SET_MEMORY_ATTRIBUTES KVM ioctl to tell the KVM MMU whether or not a particular GFN should be backed by private memory or not. Forward these page state change requests to userspace so that it can issue the expected KVM ioctls. The KVM MMU will handle updating the RMP entries when it is ready to map a private page into a guest. Define a new KVM_EXIT_VMGEXIT for exits of this type, and structure it so that it can be extended for other cases where VMGEXITs need some level of handling in userspace. Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>

SEV-SNP VMs can ask the hypervisor to change the page state in the RMP table to be private or shared using the Page State Change NAE event as defined in the GHCB specification version 2. Forward these requests to userspace as KVM_EXIT_VMGEXITs, similar to how it is done for requests that don't use a GHCB page. Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>

While resolving the RMP page fault, there may be cases where the page level between the RMP entry and TDP does not match and the 2M RMP entry must be split into 4K RMP entries. Or a 2M TDP page need to be broken into multiple of 4K pages. To keep the RMP and TDP page level in sync, zap the gfn range after splitting the pages in the RMP entry. The zap should force the TDP to gets rebuilt with the new page level. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

When SEV-SNP is enabled in the guest, the hardware places restrictions on all memory accesses based on the contents of the RMP table. When hardware encounters RMP check failure caused by the guest memory access it raises the #NPF. The error code contains additional information on the access type. See the APM volume 2 for additional information. When using gmem, RMP faults resulting from mismatches between the state in the RMP table vs. what the guest expects via its page table result in KVM_EXIT_MEMORY_FAULTs being forwarded to userspace to handle. This means the only expected case that needs to be handled in the kernel is when the page size of the entry in the RMP table is larger than the mapping in the nested page table, in which case a PSMASH instruction needs to be issued to split the large RMP entry into individual 4K entries so that subsequent accesses can succeed. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>

In preparation to support SEV-SNP AP Creation, use a variable that holds the VMSA physical address rather than converting the virtual address. This will allow SEV-SNP AP Creation to set the new physical address that will be used should the vCPU reset path be taken. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>

Add support for the SEV-SNP AP Creation NAE event. This allows SEV-SNP guests to alter the register state of the APs on their own. This allows the guest a way of simulating INIT-SIPI. A new event, KVM_REQ_UPDATE_PROTECTED_GUEST_STATE, is created and used so as to avoid updating the VMSA pointer while the vCPU is running. For CREATE The guest supplies the GPA of the VMSA to be used for the vCPU with the specified APIC ID. The GPA is saved in the svm struct of the target vCPU, the KVM_REQ_UPDATE_PROTECTED_GUEST_STATE event is added to the vCPU and then the vCPU is kicked. For CREATE_ON_INIT: The guest supplies the GPA of the VMSA to be used for the vCPU with the specified APIC ID the next time an INIT is performed. The GPA is saved in the svm struct of the target vCPU. For DESTROY: The guest indicates it wishes to stop the vCPU. The GPA is cleared from the svm struct, the KVM_REQ_UPDATE_PROTECTED_GUEST_STATE event is added to vCPU and then the vCPU is kicked. The KVM_REQ_UPDATE_PROTECTED_GUEST_STATE event handler will be invoked as a result of the event or as a result of an INIT. The handler sets the vCPU to the KVM_MP_STATE_UNINITIALIZED state, so that any errors will leave the vCPU as not runnable. Any previous VMSA pages that were installed as part of an SEV-SNP AP Creation NAE event are un-pinned. If a new VMSA is to be installed, the VMSA guest page is pinned and set as the VMSA in the vCPU VMCB and the vCPU state is set to KVM_MP_STATE_RUNNABLE. If a new VMSA is not to be installed, the VMSA is cleared in the vCPU VMCB and the vCPU state is left as KVM_MP_STATE_UNINITIALIZED to prevent it from being run. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: add handling for gmem] Signed-off-by: Michael Roth <michael.roth@amd.com>

GHCB version 2 adds support for a GHCB-based termination request that a guest can issue when it reaches an error state and wishes to inform the hypervisor that it should be terminated. Implement support for that similarly to GHCB MSR-based termination requests that are already available to SEV-ES guests via earlier versions of the GHCB protocol. See 'Termination Request' in the 'Invoking VMGEXIT' section of the GHCB specification for more details. Signed-off-by: Michael Roth <michael.roth@amd.com>

This will handle RMP table updates and direct map changes needed to put a page into a private state before mapping it into an SEV-SNP guest. Signed-off-by: Michael Roth <michael.roth@amd.com>

Implement a platform hook to do the work of restoring the direct map entries of gmem-managed pages and transitioning the corresponding RMP table entries back to the default shared/hypervisor-owned state. Signed-off-by: Michael Roth <michael.roth@amd.com>

In the case of SEV-SNP, whether or not a 2MB page can be mapped via a 2MB mapping in the guest's nested page table depends on whether or not any subpages within the range have already been initialized as private in the RMP table. The existing mixed-attribute tracking in KVM is insufficient here, for instance: - gmem allocates 2MB page - guest issues PVALIDATE on 2MB page - guest later converts a subpage to shared - SNP host code issues PSMASH to split 2MB RMP mapping to 4K - KVM MMU splits NPT mapping to 4K At this point there are no mixed attributes, and KVM would normally allow for 2MB NPT mappings again, but this is actually not allowed because the RMP table mappings are 4K and cannot be promoted on the hypervisor side, so the NPT mappings must still be limited to 4K to match this. Add a hook to determine the max NPT mapping size in situations like this. Signed-off-by: Michael Roth <michael.roth@amd.com>

With SNP/guest_memfd, private/encrypted memory should not be mappable, and MMU notifications for HVA-mapped memory will only be relevant to unencrypted guest memory. Therefore, the rationale behind issuing a wbinvd_on_all_cpus() in sev_guest_memory_reclaimed() should not apply for SNP guests and can be ignored. Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: Add some clarifications in commit] Signed-off-by: Michael Roth <michael.roth@amd.com>

Add a module parameter than can be used to enable or disable the SEV-SNP feature. Now that KVM contains the support for the SNP set the GHCB hypervisor feature flag to indicate that SNP is supported. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>

Version 2 of GHCB specification added support for the SNP Guest Request Message NAE event. The event allows for an SEV-SNP guest to make requests to the SEV-SNP firmware through hypervisor using the SNP_GUEST_REQUEST API defined in the SEV-SNP firmware specification. This is used by guests primarily to request attestation reports from firmware. There are other request types are available as well, but the specifics of what guest requests are being made are opaque to the hypervisor, which only serves as a proxy for the guest requests and firmware responses. Implement handling for these events. Co-developed-by: Alexey Kardashevskiy <aik@amd.com> Signed-off-by: Alexey Kardashevskiy <aik@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> [mdr: ensure FW command failures are indicated to guest, drop extended request handling to be re-written as separate patch, massage commit] Signed-off-by: Michael Roth <michael.roth@amd.com>

These commands can be used to create a transaction such that commands that update the reported TCB, such as SNP_SET_CONFIG/SNP_COMMIT, and updates to userspace-supplied certificates, can be handled atomically relative to any extended guest requests issued by any SNP guests while the updates are taking place. Without this interface, there is a risk that a guest will be given certificate information that does not correspond to the VCEK/VLEK used to sign a particular attestation report unless all the running guests are paused in advance, which would cause disruption to all guests in the system even if no attestation requests are being made. Even then, care is needed to ensure that KVM does not pass along certificate information that was fetched from userspace in advance of the guest being paused. This interface also provides some versatility with how similar firmware maintenance activity can be handled in the future without passing unnecessary management complexity on to userspace. Signed-off-by: Michael Roth <michael.roth@amd.com>

Version 2 of GHCB specification added support for the SNP Extended Guest Request Message NAE event. This event serves a nearly identical purpose to the previously-added SNP_GUEST_REQUEST event, but allows for additional certificate data to be supplied via an additional guest-supplied buffer to be used mainly for verifying the signature of an attestation report as returned by firmware. This certificate data is supplied by userspace, so unlike with SNP_GUEST_REQUEST events, SNP_EXTENDED_GUEST_REQUEST events are first forwarded to userspace via a KVM_EXIT_VMGEXIT exit type, and then the firmware request is made only afterward. Implement handling for these events. Since there is a potential for race conditions where the userspace-supplied certificate data may be out-of-sync relative to the reported TCB that firmware will use when signing attestation reports, make use of the transaction/synchronization mechanisms added by the SNP_SET_CONFIG_{START,END} SEV device ioctls such that the guest will be told to retry the request when an update to reported TCB or userspace-supplied certificates may have occurred or is in progress while an extended guest request is being processed. Signed-off-by: Michael Roth <michael.roth@amd.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Snp host latest #6

Snp host latest #6

Commits on Feb 20, 2024

Commits on Feb 21, 2024

Snp host latest #6

Are you sure you want to change the base?

Snp host latest #6

Commits on Feb 20, 2024

Commits on Feb 21, 2024