<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/virt/coco, branch v6.15</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.15</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.15'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2025-03-19T10:03:06Z</updated>
<entry>
<title>Merge tag 'v6.14-rc7' into x86/core, to pick up fixes</title>
<updated>2025-03-19T10:03:06Z</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2025-03-19T10:03:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=89771319e0f11314fcf6d22fcdd0c41e2d157ddc'/>
<id>urn:sha1:89771319e0f11314fcf6d22fcdd0c41e2d157ddc</id>
<content type='text'>
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex</title>
<updated>2025-03-07T13:09:33Z</updated>
<author>
<name>Alexey Kardashevskiy</name>
<email>aik@amd.com</email>
</author>
<published>2025-03-07T01:37:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3e385c0d6ce88ac9916dcf84267bd5855d830748'/>
<id>urn:sha1:3e385c0d6ce88ac9916dcf84267bd5855d830748</id>
<content type='text'>
Compared to the SNP Guest Request, the "Extended" version adds data pages for
receiving certificates. If not enough pages provided, the HV can report to the
VM how much is needed so the VM can reallocate and repeat.

Commit

  ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex")

moved handling of the allocated/desired pages number out of scope of said
mutex and create a possibility for a race (multiple instances trying to
trigger Extended request in a VM) as there is just one instance of
snp_msg_desc per /dev/sev-guest and no locking other than snp_cmd_mutex.

Fix the issue by moving the data blob/size and the GHCB input struct
(snp_req_data) into snp_guest_req which is allocated on stack now and accessed
by the GHCB caller under that mutex.

Stop allocating SEV_FW_BLOB_MAX_SIZE in snp_msg_alloc() as only one of four
callers needs it. Free the received blob in get_ext_report() right after it is
copied to the userspace. Possible future users of snp_send_guest_request() are
likely to have different ideas about the buffer size anyways.

Fixes: ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex")
Signed-off-by: Alexey Kardashevskiy &lt;aik@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250307013700.437505-3-aik@amd.com
</content>
</entry>
<entry>
<title>virt: sev-guest: Allocate request data dynamically</title>
<updated>2025-03-07T12:34:25Z</updated>
<author>
<name>Nikunj A Dadhania</name>
<email>nikunj@amd.com</email>
</author>
<published>2025-03-06T08:17:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ac7c06acaa3738b38e83815ac0f07140ad320f13'/>
<id>urn:sha1:ac7c06acaa3738b38e83815ac0f07140ad320f13</id>
<content type='text'>
Commit

  ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex")

narrowed the command mutex scope to snp_send_guest_request().  However,
GET_REPORT, GET_DERIVED_KEY, and GET_EXT_REPORT share the req structure in
snp_guest_dev. Without the mutex protection, concurrent requests can overwrite
each other's data. Fix it by dynamically allocating the request structure.

Fixes: ae596615d93d ("virt: sev-guest: Reduce the scope of SNP command mutex")
Closes: https://github.com/AMDESE/AMDSEV/issues/265
Reported-by: andreas.stuehrk@yaxi.tech
Signed-off-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Signed-off-by: Alexey Kardashevskiy &lt;aik@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250307013700.437505-2-aik@amd.com
</content>
</entry>
<entry>
<title>x86/mm: Reduce header dependencies in &lt;asm/set_memory.h&gt;</title>
<updated>2025-02-28T16:35:22Z</updated>
<author>
<name>Kevin Brodsky</name>
<email>kevin.brodsky@arm.com</email>
</author>
<published>2024-12-12T08:09:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=95c4cc5a585400982ae5b3bf9e3be6de71768376'/>
<id>urn:sha1:95c4cc5a585400982ae5b3bf9e3be6de71768376</id>
<content type='text'>
Commit:

  03b122da74b2 ("x86/sgx: Hook arch_memory_failure() into mainline code")

... added &lt;linux/mm.h&gt; to &lt;asm/set_memory.h&gt; to provide some helpers.

However the following commit:

  b3fdf9398a16 ("x86/mce: relocate set{clear}_mce_nospec() functions")

... moved the inline definitions someplace else, and now &lt;asm/set_memory.h&gt;
just declares a bunch of mostly self-contained functions.

No need for the whole &lt;linux/mm.h&gt; inclusion to declare functions; just
remove that include. This helps avoid circular dependency headaches
(e.g. if &lt;linux/mm.h&gt; ends up including &lt;linux/set_memory.h&gt;).

This change requires a couple of include fixups not to break the
build:

* &lt;asm/smp.h&gt;: including &lt;asm/thread_info.h&gt; directly relies on
  &lt;linux/thread_info.h&gt; having already been included, because the
  former needs the BAD_STACK/NOT_STACK constants defined in the
  latter. This is no longer the case when &lt;asm/smp.h&gt; is included from
  some driver file - just include &lt;linux/thread_info.h&gt; to stay out
  of trouble.

* sev-guest.c relies on &lt;asm/set_memory.h&gt; including &lt;linux/mm.h&gt;,
  so we just need to make that include explicit.

[ mingo: Cleaned up the changelog ]

Signed-off-by: Kevin Brodsky &lt;kevin.brodsky@arm.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: David Hildenbrand &lt;david@redhat.com&gt;
Link: https://lore.kernel.org/r/20241212080904.2089632-3-kevin.brodsky@arm.com
</content>
</entry>
<entry>
<title>Merge tag 'x86_sev_for_v6.14_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2025-01-21T17:00:31Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-01-21T17:00:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=13b6931c44969ff057ad2a3aa1c20a1b28b79b6f'/>
<id>urn:sha1:13b6931c44969ff057ad2a3aa1c20a1b28b79b6f</id>
<content type='text'>
Pull x86 SEV updates from Borislav Petkov:

 - A segmented Reverse Map table (RMP) is a across-nodes distributed
   table of sorts which contains per-node descriptors of each node-local
   4K page, denoting its ownership (hypervisor, guest, etc) in the realm
   of confidential computing. Add support for such a table in order to
   improve referential locality when accessing or modifying RMP table
   entries

 - Add support for reading the TSC in SNP guests by removing any
   interference or influence the hypervisor might have, with the goal of
   making a confidential guest even more independent from the hypervisor

* tag 'x86_sev_for_v6.14_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/sev: Add the Secure TSC feature for SNP guests
  x86/tsc: Init the TSC for Secure TSC guests
  x86/sev: Mark the TSC in a secure TSC guest as reliable
  x86/sev: Prevent RDTSC/RDTSCP interception for Secure TSC enabled guests
  x86/sev: Prevent GUEST_TSC_FREQ MSR interception for Secure TSC enabled guests
  x86/sev: Change TSC MSR behavior for Secure TSC enabled guests
  x86/sev: Add Secure TSC support for SNP guests
  x86/sev: Relocate SNP guest messaging routines to common code
  x86/sev: Carve out and export SNP guest messaging init routines
  virt: sev-guest: Replace GFP_KERNEL_ACCOUNT with GFP_KERNEL
  virt: sev-guest: Remove is_vmpck_empty() helper
  x86/sev/docs: Document the SNP Reverse Map Table (RMP)
  x86/sev: Add full support for a segmented RMP table
  x86/sev: Treat the contiguous RMP table as a single RMP segment
  x86/sev: Map only the RMP table entries instead of the full RMP range
  x86/sev: Move the SNP probe routine out of the way
  x86/sev: Require the RMPREAD instruction after Zen4
  x86/sev: Add support for the RMPREAD instruction
  x86/sev: Prepare for using the RMPREAD instruction to access the RMP
</content>
</entry>
<entry>
<title>Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux</title>
<updated>2025-01-21T05:21:49Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-01-21T05:21:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9ad09c4f2868540130ad2d5dfe265f55c75c1705'/>
<id>urn:sha1:9ad09c4f2868540130ad2d5dfe265f55c75c1705</id>
<content type='text'>
Pull arm64 updates from Will Deacon:
 "We've got a little less than normal thanks to the holidays in
  December, but there's the usual summary below. The highlight is
  probably the 52-bit physical addressing (LPA2) clean-up from Ard.

  Confidential Computing:

   - Register a platform device when running in CCA realm mode to enable
     automatic loading of dependent modules

  CPU Features:

   - Update a bunch of system register definitions to pick up new field
     encodings from the architectural documentation

   - Add hwcaps and selftests for the new (2024) dpISA extensions

  Documentation:

   - Update EL3 (firmware) requirements for booting Linux on modern
     arm64 designs

   - Remove stale information about the kernel virtual memory map

  Miscellaneous:

   - Minor cleanups and typo fixes

  Memory management:

   - Fix vmemmap_check_pmd() to look at the PMD type bits

   - LPA2 (52-bit physical addressing) cleanups and minor fixes

   - Adjust physical address space depending upon whether or not LPA2 is
     enabled

  Perf and PMUs:

   - Add port filtering support for NVIDIA's NVLINK-C2C Coresight PMU

   - Extend AXI filtering support for the DDR PMU on NXP IMX SoCs

   - Fix Designware PCIe PMU event numbering

   - Add generic branch events for the Apple M1 CPU PMU

   - Add support for Marvell Odyssey DDR and LLC-TAD PMUs

   - Cleanups to the Hisilicon DDRC and Uncore PMU code

   - Advertise discard mode for the SPE PMU

   - Add the perf users mailing list to our MAINTAINERS entry"

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (64 commits)
  Documentation: arm64: Remove stale and redundant virtual memory diagrams
  perf docs: arm_spe: Document new discard mode
  perf: arm_spe: Add format option for discard mode
  MAINTAINERS: Add perf list for drivers/perf/
  arm64: Remove duplicate included header
  drivers/perf: apple_m1: Map generic branch events
  arm64: rsi: Add automatic arm-cca-guest module loading
  kselftest/arm64: Add 2024 dpISA extensions to hwcap test
  KVM: arm64: Allow control of dpISA extensions in ID_AA64ISAR3_EL1
  arm64/hwcap: Describe 2024 dpISA extensions to userspace
  arm64/sysreg: Update ID_AA64SMFR0_EL1 to DDI0601 2024-12
  arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented
  drivers/perf: hisi: Set correct IRQ affinity for PMUs with no association
  arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu()
  arm64: mm: Test for pmd_sect() in vmemmap_check_pmd()
  arm64/mm: Replace open encodings with PXD_TABLE_BIT
  arm64/mm: Rename pte_mkpresent() as pte_mkvalid()
  arm64/sysreg: Update ID_AA64ISAR2_EL1 to DDI0601 2024-09
  arm64/sysreg: Update ID_AA64ZFR0_EL1 to DDI0601 2024-09
  arm64/sysreg: Update ID_AA64FPFR0_EL1 to DDI0601 2024-09
  ...
</content>
</entry>
<entry>
<title>arm64: rsi: Add automatic arm-cca-guest module loading</title>
<updated>2025-01-08T13:58:49Z</updated>
<author>
<name>Jeremy Linton</name>
<email>jeremy.linton@arm.com</email>
</author>
<published>2024-12-20T18:12:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a1edec22457e6fabc5450a6eea7fdc0e1b6dab31'/>
<id>urn:sha1:a1edec22457e6fabc5450a6eea7fdc0e1b6dab31</id>
<content type='text'>
The TSM module provides guest identification and attestation when a
guest runs in CCA realm mode. By creating a dummy platform device,
let's ensure the module is automatically loaded. The udev daemon loads
the TSM module after it receives a device addition event. Once that
happens, it can be used earlier in the boot process to decrypt the
rootfs.

Signed-off-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: Steven Price &lt;steven.price@arm.com&gt;
Link: https://lore.kernel.org/r/20241220181236.172060-2-jeremy.linton@arm.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/sev: Relocate SNP guest messaging routines to common code</title>
<updated>2025-01-07T10:16:46Z</updated>
<author>
<name>Nikunj A Dadhania</name>
<email>nikunj@amd.com</email>
</author>
<published>2025-01-06T12:46:24Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1e0b23b5d2d18b2bd2c66d8214072d700a8c350d'/>
<id>urn:sha1:1e0b23b5d2d18b2bd2c66d8214072d700a8c350d</id>
<content type='text'>
At present, the SEV guest driver exclusively handles SNP guest messaging. All
routines for sending guest messages are embedded within it.

To support Secure TSC, SEV-SNP guests must communicate with the AMD Security
Processor during early boot. However, these guest messaging functions are not
accessible during early boot since they are currently part of the guest
driver.

Hence, relocate the core SNP guest messaging functions to SEV common code and
provide an API for sending SNP guest messages.

No functional change, but just an export symbol added for
snp_send_guest_request() and dropped the export symbol on
snp_issue_guest_request() and made it static.

Signed-off-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lore.kernel.org/r/20250106124633.1418972-5-nikunj@amd.com
</content>
</entry>
<entry>
<title>x86/sev: Carve out and export SNP guest messaging init routines</title>
<updated>2025-01-07T09:33:20Z</updated>
<author>
<name>Nikunj A Dadhania</name>
<email>nikunj@amd.com</email>
</author>
<published>2025-01-06T12:46:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c5529418d05079384af4dbbb6f6156344c2ffce2'/>
<id>urn:sha1:c5529418d05079384af4dbbb6f6156344c2ffce2</id>
<content type='text'>
Currently, the sev-guest driver is the only user of SNP guest messaging. All
routines for initializing SNP guest messaging are implemented within the
sev-guest driver and are not available during early boot.

In preparation for adding Secure TSC guest support, carve out APIs to allocate
and initialize the guest messaging descriptor context and make it part of
coco/sev/core.c. As there is no user of sev_guest_platform_data anymore,
remove the structure.

Signed-off-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lore.kernel.org/r/20250106124633.1418972-4-nikunj@amd.com
</content>
</entry>
<entry>
<title>virt: sev-guest: Replace GFP_KERNEL_ACCOUNT with GFP_KERNEL</title>
<updated>2025-01-07T09:26:20Z</updated>
<author>
<name>Nikunj A Dadhania</name>
<email>nikunj@amd.com</email>
</author>
<published>2025-01-06T12:46:22Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=864884a0c29cc610a859b5210158112fd8675fe1'/>
<id>urn:sha1:864884a0c29cc610a859b5210158112fd8675fe1</id>
<content type='text'>
Replace GFP_KERNEL_ACCOUNT with GFP_KERNEL in the sev-guest driver code.
GFP_KERNEL_ACCOUNT is typically used for accounting untrusted userspace
allocations. After auditing the sev-guest code, the following changes are
necessary:

  * snp_init_crypto(): Use GFP_KERNEL as this is a trusted device probe
    path.

Retain GFP_KERNEL_ACCOUNT in the following cases for robustness and
specific path requirements:

  * alloc_shared_pages(): Although all allocations are limited, retain
    GFP_KERNEL_ACCOUNT for future robustness.

  * get_report() and get_ext_report(): These functions are on the unlocked
    ioctl path and should continue using GFP_KERNEL_ACCOUNT.

Suggested-by: Borislav Petkov &lt;bp@alien8.de&gt;
Signed-off-by: Nikunj A Dadhania &lt;nikunj@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/r/20250106124633.1418972-3-nikunj@amd.com
</content>
</entry>
</feed>
