| a98ce027 | 14-May-2024 |
Al Viro <viro@zeniv.linux.org.uk> |
efi_secret: clean securityfs use up
securityfs_remove() does take care of entire subtree now; no need
to mess with them individually.
NB: ->i_op replacement in there is still buggy. One shouldn't
efi_secret: clean securityfs use up
securityfs_remove() does take care of entire subtree now; no need
to mess with them individually.
NB: ->i_op replacement in there is still buggy. One shouldn't
ever modify ->i_op of live accessible inode.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
| b0ca403a | 13-May-2025 |
Cedric Xing <cedric.xing@intel.com> |
tsm-mr: Fix init breakage after bin_attrs constification by scoping non-const pointers to init phase
Commit 9bec944506fa ("sysfs: constify attribute_group::bin_attrs") enforced
the ro-after-init pri
tsm-mr: Fix init breakage after bin_attrs constification by scoping non-const pointers to init phase
Commit 9bec944506fa ("sysfs: constify attribute_group::bin_attrs") enforced
the ro-after-init principle by making elements of bin_attrs_new pointing to
const.
To align with this change, introduce a temporary variable `bap` within the
initialization loop. This improves code clarity by explicitly marking the
initialization scope and eliminates the need for type casts when assigning
to bin_attrs_new.
Signed-off-by: Cedric Xing <cedric.xing@intel.com>
Link: https://patch.msgid.link/20250513164154.10109-1-cedric.xing@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
| 7c3f259d | 07-May-2025 |
Cedric Xing <cedric.xing@intel.com> |
virt: tdx-guest: Transition to scoped_cond_guard for mutex operations
Replace mutex_lock_interruptible()/mutex_unlock() with scoped_cond_guard to
enhance code readability and maintainability.
Signe
virt: tdx-guest: Transition to scoped_cond_guard for mutex operations
Replace mutex_lock_interruptible()/mutex_unlock() with scoped_cond_guard to
enhance code readability and maintainability.
Signed-off-by: Cedric Xing <cedric.xing@intel.com>
Acked-by: Dionna Amalie Glaze <dionnaglaze@google.com>
Link: https://patch.msgid.link/20250506-tdx-rtmr-v6-7-ac6ff5e9d58a@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
| 850972bc | 07-May-2025 |
Cedric Xing <cedric.xing@intel.com> |
virt: tdx-guest: Refactor and streamline TDREPORT generation
Consolidate instances (code segments) of TDREPORT generation to improve
readability and maintainability, by refactoring each instance int
virt: tdx-guest: Refactor and streamline TDREPORT generation
Consolidate instances (code segments) of TDREPORT generation to improve
readability and maintainability, by refactoring each instance into invoking
a unified subroutine throughout the TDX guest driver. Implement proper
locking around TDG.MR.REPORT and TDG.MR.RTMR.EXTEND to avoid race inside
the TDX module. Preallocate TDREPORT buffer to reduce overhead in
subsequent TDREPORT generation.
Signed-off-by: Cedric Xing <cedric.xing@intel.com>
Acked-by: Dionna Amalie Glaze <dionnaglaze@google.com>
Link: https://patch.msgid.link/20250506-tdx-rtmr-v6-6-ac6ff5e9d58a@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
| 7515f45c | 04-Mar-2025 |
Dan Williams <dan.j.williams@intel.com> |
coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/
In preparation for creating a new drivers/virt/coco/host/ directory to
house shared host driver infrastructure for confide
coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/
In preparation for creating a new drivers/virt/coco/host/ directory to
house shared host driver infrastructure for confidential computing, move
configfs-tsm to a guest/ sub-directory. The tsm.ko module is renamed to
tsm_reports.ko. The old tsm.ko module was only ever demand loaded by
kernel internal dependencies, so it should not affect existing userspace
module install scripts.
The new drivers/virt/coco/guest/ is also a preparatory landing spot for
new / optional TSM Report mechanics like a TCB stability enumeration /
watchdog mechanism. To be added later.
Cc: Wu Hao <hao.wu@intel.com>
Cc: Yilun Xu <yilun.xu@intel.com>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Alexey Kardashevskiy <aik@amd.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://patch.msgid.link/174107246641.1288555.208426916259466774.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
| 3e385c0d | 07-Mar-2025 |
Alexey Kardashevskiy <aik@amd.com> |
virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex
Compared to the SNP Guest Request, the "Extended" version adds data pages for
receiving certificates. If not enough pa
virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex
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 <aik@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250307013700.437505-3-aik@amd.com
show more ...
|