On Wed, Dec 11, 2024 at 4:00 PM Jason Gunthorpe wrote:
>
> On Wed, Dec 11, 2024 at 09:19:04AM +0100, Stefano Garzarella wrote:
>
> > > After that, there is no meaningful shared code here, and maybe the
> > > TPM_CHIP_FLAG_IRQ hack can be avoided too.
> >
> &g
On Wed, Dec 11, 2024 at 4:54 PM Jason Gunthorpe wrote:
>
> On Wed, Dec 11, 2024 at 04:38:29PM +0100, Stefano Garzarella wrote:
>
> > Except for the call to pops->sendrcv(buffer) the rest depends on how
> > the TCG TPM reference implementation [1] expects the request/resp
On Wed, Dec 11, 2024 at 5:31 PM Tom Lendacky wrote:
>
> On 12/10/24 08:34, Stefano Garzarella wrote:
> > From: James Bottomley
> >
> > If the SNP boot has a SVSM, probe for the vTPM device by sending a
> > SVSM_VTPM_QUERY call (function 8). The SVSM wil
On Tue, Dec 10, 2024 at 4:04 PM Jason Gunthorpe wrote:
>
> On Tue, Dec 10, 2024 at 09:55:41AM -0500, James Bottomley wrote:
> > On Tue, 2024-12-10 at 10:40 -0400, Jason Gunthorpe wrote:
> > > On Tue, Dec 10, 2024 at 03:34:23PM +0100, Stefano Garzarella wrote:
> > &
interfaces.
Signed-off-by: James Bottomley
Signed-off-by: Claudio Carvalho
[SG] changed references/links to TCG TPM repo
Signed-off-by: Stefano Garzarella
---
include/linux/tpm_platform.h| 90
drivers/char/tpm/tpm_platform.c | 141
driver
Add macros for SVSM_VTPM_QUERY and SVSM_VTPM_CMD calls as defined
in the "Secure VM Service Module for SEV-SNP Guests"
Publication # 58019 Revision: 1.00
Link:
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Signed-off-by: Stefano
Signed-off-by: Stefano Garzarella
---
arch/x86/coco/sev/core.c | 64
1 file changed, 64 insertions(+)
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index c5b0148b8c0a..ec0153fddc9e 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/
58019.pdf
[4]
https://github.com/coconut-svsm/svsm/commit/6522c67e1e414f192a6f014b122ca8a1066e3bf5
[5] https://github.com/stefano-garzarella/snp-svsm-vtpm
James Bottomley (2):
tpm: add generic platform device
x86/sev: add a SVSM vTPM platform device
Stefano Garzarella (1):
x86/sev: add SVSM
On Tue, Dec 10, 2024 at 03:34:21PM +0100, Stefano Garzarella wrote:
From: James Bottomley
This is primarily designed to support an enlightened driver for the
AMD svsm based vTPM, but it could be used by any platform which
communicates with a TPM device. The platform must fill in struct
On Thu, Dec 12, 2024 at 10:41:40AM -0500, James Bottomley wrote:
On Thu, 2024-12-12 at 16:30 +0100, Stefano Garzarella wrote:
On Thu, Dec 12, 2024 at 09:35:46AM -0500, James Bottomley wrote:
> On Thu, 2024-12-12 at 10:51 +0100, Stefano Garzarella wrote:
> > On Tue, Dec 10, 2024 at 0
On Thu, Dec 12, 2024 at 09:35:46AM -0500, James Bottomley wrote:
On Thu, 2024-12-12 at 10:51 +0100, Stefano Garzarella wrote:
On Tue, Dec 10, 2024 at 03:34:21PM +0100, Stefano Garzarella wrote:
[...]
> +static int tpm_platform_recv(struct tpm_chip *chip, u8 *buf,
> size
On Wed, Dec 11, 2024 at 12:02:49PM -0500, James Bottomley wrote:
On Wed, 2024-12-11 at 10:30 -0600, Tom Lendacky wrote:
On 12/10/24 08:34, Stefano Garzarella wrote:
[...]
> +static bool is_svsm_vtpm_send_command_supported(void)
> +{
> + struct svsm_call call = {};
>
On Wed, 11 Dec 2024 at 16:00, Jason Gunthorpe wrote:
>
> On Wed, Dec 11, 2024 at 09:19:04AM +0100, Stefano Garzarella wrote:
>
> > > After that, there is no meaningful shared code here, and maybe the
> > > TPM_CHIP_FLAG_IRQ hack can be avoided too.
> >
> &g
On Thu, Dec 19, 2024 at 05:40:58PM +0200, Jarkko Sakkinen wrote:
On Thu Dec 19, 2024 at 5:35 PM EET, Stefano Garzarella wrote:
So to use them directly in sev, we would have to move these definitions
into include/linux/tpm.h or some other file in inlcude/. Is this
acceptable for TPM maintainers
On Thu, Jan 23, 2025 at 11:50:40AM +0200, Jarkko Sakkinen wrote:
On Wed Jan 22, 2025 at 11:29 PM EET, Dionna Amalie Glaze wrote:
I can appreciate this viewpoint. It even surfaced Microsoft's fTPM
paper to me, which solves some interesting problems we need to solve
in SVSM too. So thanks for that
On Thu, Jan 23, 2025 at 01:49:34PM +0200, Jarkko Sakkinen wrote:
On Thu Jan 23, 2025 at 1:46 PM EET, Jarkko Sakkinen wrote:
On Thu Jan 23, 2025 at 12:09 PM EET, Stefano Garzarella wrote:
> On Thu, Jan 23, 2025 at 11:50:40AM +0200, Jarkko Sakkinen wrote:
> >On Wed Jan 22, 2025 at 11:
Hi Jarkko,
On Thu, 19 Dec 2024 at 17:07, Stefano Garzarella wrote:
>
> On Thu, Dec 19, 2024 at 05:40:58PM +0200, Jarkko Sakkinen wrote:
> >On Thu Dec 19, 2024 at 5:35 PM EET, Stefano Garzarella wrote:
> >> So to use them directly in sev, we would have to move these definiti
On Tue, Jan 14, 2025 at 09:07:20AM -0400, Jason Gunthorpe wrote:
On Tue, Jan 14, 2025 at 11:42:34AM +0100, Stefano Garzarella wrote:
Hi Jarkko,
On Thu, 19 Dec 2024 at 17:07, Stefano Garzarella wrote:
>
> On Thu, Dec 19, 2024 at 05:40:58PM +0200, Jarkko Sakkinen wrote:
> >On Thu
On Wed, Mar 19, 2025 at 04:58:18PM -0300, Jason Gunthorpe wrote:
On Tue, Mar 11, 2025 at 11:01:30AM +0100, Stefano Garzarella wrote:
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Let's simplify the driver by implementing th
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
It used an internal buffer to cache the response when .send() is called,
and then return it when .recv() is called.
Let's simplify the driver by impleme
From: Stefano Garzarella
Some devices do not support interrupts and provide a single operation
to send the command and receive the response on the same buffer.
To support this scenario, a driver could set TPM_CHIP_FLAG_IRQ in the
chip's flags to get recv() to be called immediately after
On Wed, Mar 19, 2025 at 08:44:22PM -0300, Jason Gunthorpe wrote:
On Tue, Mar 18, 2025 at 05:18:53PM +0100, Stefano Garzarella wrote:
I see, thanks for the clarification!
I saw that with devm_get_free_pages() I can easily allocate a
resource-managed page, so I'll do that in v4.
As a ge
On Thu, Mar 20, 2025 at 07:30:43PM +0200, Jarkko Sakkinen wrote:
On Thu, Mar 20, 2025 at 06:16:19PM +0100, Borislav Petkov wrote:
On Thu, Mar 20, 2025 at 05:03:09PM +0200, Jarkko Sakkinen wrote:
> > I can do that, I slightly prefer BIT_ULL() macro, but I don't have a strong
> > opinion on my sid
On Tue, Mar 18, 2025 at 09:54:31AM -0500, Tom Lendacky wrote:
On 3/18/25 05:38, Stefano Garzarella wrote:
On Mon, Mar 17, 2025 at 03:43:18PM +0200, Jarkko Sakkinen wrote:
On Fri, Mar 14, 2025 at 11:48:11AM -0500, Tom Lendacky wrote:
On 3/11/25 04:42, Stefano Garzarella wrote:
Add driver for
On Mon, Mar 17, 2025 at 03:34:10PM +0200, Jarkko Sakkinen wrote:
On Fri, Mar 14, 2025 at 11:56:31AM -0500, Tom Lendacky wrote:
On 3/11/25 04:42, Stefano Garzarella wrote:
> SNP platform can provide a vTPM device emulated by SVSM.
>
> The "tpm-svsm" device can be handled by
Hi Sumit, Jens,
On Thu, Mar 13, 2025 at 01:59:19PM +0100, Jens Wiklander wrote:
On Thu, Mar 13, 2025 at 10:13 AM Sumit Garg
wrote:
+ Jens
Hi Stefano,
On Tue, Mar 11, 2025 at 11:01:29AM +0100, Stefano Garzarella wrote:
> This driver does not support interrupts, and receiving the response
On Mon, Mar 17, 2025 at 03:36:26PM +0200, Jarkko Sakkinen wrote:
On Fri, Mar 14, 2025 at 10:27:07AM -0500, Tom Lendacky wrote:
On 3/11/25 04:42, Stefano Garzarella wrote:
> Add two new functions to probe and send commands to the SVSM vTPM.
> They leverage the two calls defined by the AM
On Mon, Mar 17, 2025 at 03:43:18PM +0200, Jarkko Sakkinen wrote:
>On Fri, Mar 14, 2025 at 11:48:11AM -0500, Tom Lendacky wrote:
>> On 3/11/25 04:42, Stefano Garzarella wrote:
>> > Add driver for the vTPM defined by the AMD SVSM spec [1].
>> >
>> > The specifi
On Tue, 1 Apr 2025 at 00:59, James Bottomley
wrote:
>
> On Mon, 2025-03-31 at 15:23 -0700, Dionna Amalie Glaze wrote:
> > On Mon, Mar 31, 2025 at 2:26 PM James Bottomley
> > wrote:
> > >
> > > On Mon, 2025-03-31 at 13:56 -0700, Dionna Amalie Glaze wrote:
> > > [...]
> > > > I might be unclear on
From: Stefano Garzarella
SNP platform can provide a vTPM device emulated by SVSM.
The "tpm-svsm" device can be handled by the platform driver added
by the previous commit in drivers/char/tpm/tpm_svsm.c
Register the device unconditionally. The support check (e.g. SVSM,
0:58:00AM +0100, Stefano Garzarella wrote:
> [...]
> > > > @@ -65,6 +89,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> > > > *chip, void *buf, size_t bufsiz)
> > > > ssize_t len = 0;
> > > > u32 count, ordinal;
> > > >
On Wed, Mar 26, 2025 at 10:37:09PM +0200, Jarkko Sakkinen wrote:
On Wed, Mar 26, 2025 at 05:58:33PM +0200, Jarkko Sakkinen wrote:
On Wed, Mar 26, 2025 at 04:57:47PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 26, 2025 at 11:34:01AM -0300, Jason Gunthorpe wrote:
> > On Wed, Mar 26, 2025 at 02:11:
On Wed, Mar 26, 2025 at 06:53:51PM +0200, Jarkko Sakkinen wrote:
On Thu, Mar 20, 2025 at 04:24:32PM +0100, Stefano Garzarella wrote:
From: Stefano Garzarella
Some devices do not support interrupts and provide a single operation
to send the command and receive the response on the same buffer
On Wed, Mar 26, 2025 at 07:14:22PM +0200, Jarkko Sakkinen wrote:
On Tue, Mar 25, 2025 at 06:20:48PM +0100, Stefano Garzarella wrote:
On Tue, Mar 25, 2025 at 09:56:53AM -0700, Dionna Amalie Glaze wrote:
> On Mon, Mar 24, 2025 at 3:47 AM Stefano Garzarella
wrote:
> >
> >
atus || chip->flags & TPM_CHIP_FLAG_IRQ)
goto out_recv;
Anyway, those are small things, the patch LGTM and it's a great cleanup
for ftpm and the svsm driver I'm developing!
Reviewed-by: Stefano Garzarella
stop = jiffies + tpm_calc_ordinal_duration(c
On Thu, Mar 27, 2025 at 03:02:32PM +0200, Jarkko Sakkinen wrote:
On Thu, Mar 27, 2025 at 10:48:17AM +0100, Stefano Garzarella wrote:
On Wed, Mar 26, 2025 at 06:53:51PM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 20, 2025 at 04:24:32PM +0100, Stefano Garzarella wrote:
> > From
On Thu, Mar 27, 2025 at 03:23:39PM +0200, Jarkko Sakkinen wrote:
On Thu, Mar 27, 2025 at 10:58:00AM +0100, Stefano Garzarella wrote:
On Wed, Mar 26, 2025 at 06:18:38PM +0200, Jarkko Sakkinen wrote:
> From: Jarkko Sakkinen
>
> tpm_ftpm_tee does not require chip->status, chip->ca
/20250403100943.120738-1-sgarz...@redhat.com/
Stefano Garzarella (4):
tpm: add buf_size parameter in the .send callback
tpm: support devices with synchronous send()
tpm/tpm_ftpm_tee: support TPM_CHIP_FLAG_SYNC
tpm/tpm_svsm: support TPM_CHIP_FLAG_SYNC
drivers/char/tpm/tpm_ftpm_tee.h | 4 -
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need to impl
On Wed, Apr 09, 2025 at 02:16:40PM -0500, Tom Lendacky wrote:
On 4/9/25 13:45, Borislav Petkov wrote:
On Wed, Apr 09, 2025 at 11:07:49AM -0500, Tom Lendacky wrote:
So the vTPM driver wouldn't change, just snp_init_platform_device():
if (snp_vmpl && platform_device_register(&tpm_svsm_de
From: Stefano Garzarella
Add two new functions to probe and send commands to the SVSM vTPM.
They leverage the two calls defined by the AMD SVSM specification [1]
for the vTPM protocol: SVSM_VTPM_QUERY and SVSM_VTPM_CMD.
Expose snp_svsm_vtpm_send_command() to be used by a tpm driver.
[1
From: Stefano Garzarella
Add driver for the vTPM defined by the AMD SVSM spec [1].
The specification defines a protocol that a SEV-SNP guest OS can use to
discover and talk to a vTPM emulated by the Secure VM Service Module (SVSM)
in the guest context, but at a more privileged level (VMPL0
From: Stefano Garzarella
Helpers for the SVSM_VTPM_CMD calls used by the vTPM protocol defined by
the AMD SVSM spec [1].
The vTPM protocol follows the Official TPM 2.0 Reference Implementation
(originally by Microsoft, now part of the TCG) simulator protocol.
[1] "Secure VM Service Modul
From: Stefano Garzarella
SNP platform can provide a vTPM device emulated by SVSM.
The "tpm-svsm" device can be handled by the platform driver added
by the previous commit in drivers/char/tpm/tpm_svsm.c
Register the platform device only when SVSM is available and it
supports vTPM c
.ca...@linux.ibm.com/
[2] https://github.com/coconut-svsm/linux/tree/svsm
[3] "Secure VM Service Module for SEV-SNP Guests"
Publication # 58019 Revision: 1.00
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[4]
https://github.com/coco
On Tue, Apr 08, 2025 at 01:00:12PM +0200, Borislav Petkov wrote:
On Thu, Apr 03, 2025 at 12:09:42PM +0200, Stefano Garzarella wrote:
@@ -2697,6 +2702,9 @@ static int __init snp_init_platform_device(void)
if (platform_device_register(&sev_guest_device))
return -EN
On Wed, 9 Apr 2025 at 18:08, Tom Lendacky wrote:
>
> On 4/9/25 06:31, Borislav Petkov wrote:
> > On Wed, Apr 09, 2025 at 12:43:01PM +0200, Stefano Garzarella wrote:
> >> Sorry, maybe I missed something.
> >>
> >> tpm_svsm.c registers the d
On Wed, 9 Apr 2025 at 14:22, James Bottomley
wrote:
>
> On Wed, 2025-04-09 at 13:31 +0200, Borislav Petkov wrote:
> > On Wed, Apr 09, 2025 at 12:43:01PM +0200, Stefano Garzarella wrote:
> > > Sorry, maybe I missed something.
> > >
> > &g
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need the 4KB int
On Mon, Mar 31, 2025 at 08:34:42PM +0300, Jarkko Sakkinen wrote:
On Mon, Mar 31, 2025 at 12:38:56PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
Add driver for the vTPM defined by the AMD SVSM spec [1].
The specification defines a protocol that a SEV-SNP guest OS can use to
On Mon, Mar 10, 2025 at 12:30:06PM +0100, Borislav Petkov wrote:
On Fri, Feb 28, 2025 at 06:07:16PM +0100, Stefano Garzarella wrote:
+bool snp_svsm_vtpm_probe(void)
+{
+ struct svsm_call call = {};
+ u64 send_cmd_mask = 0;
+ u64 platform_cmds;
+ u64 features;
+ int
On Tue, Apr 08, 2025 at 01:28:20PM +0200, Borislav Petkov wrote:
On Tue, Apr 08, 2025 at 01:08:36PM +0200, Stefano Garzarella wrote:
We discussed a bit on v3, but I'm open to change it:
https://lore.kernel.org/linux-integrity/nrn4ur66lz2ocbkkjl2bgiex3xbp552szerfhalsaefunqxf7p@ki7xf66zrf6u
From: Stefano Garzarella
In preparation for the next commit, add a new `buf_size` parameter to
the `.send` callback in `tpm_class_ops` which contains the entire buffer
size. In this patch it is pretty much ignored by all drivers, but it will
be used in the next patch.
Also rename the previous
On Fri, 4 Apr 2025 at 20:59, Dionna Amalie Glaze wrote:
>
> On Fri, Apr 4, 2025 at 11:37 AM Stefano Garzarella
> wrote:
> >
> > On Fri, 4 Apr 2025 at 19:32, Dionna Amalie Glaze
> > wrote:
> > >
> > > On Thu, Apr 3, 2025 at 3:10 AM Stefano G
On Thu, 3 Apr 2025 at 21:05, Jarkko Sakkinen wrote:
>
> On Thu, Apr 03, 2025 at 12:09:41PM +0200, Stefano Garzarella wrote:
> > From: Stefano Garzarella
> >
> > Add driver for the vTPM defined by the AMD SVSM spec [1].
> >
> > The specification defines a prot
On Wed, 9 Apr 2025 at 12:21, Borislav Petkov wrote:
>
> On Tue, Apr 08, 2025 at 01:54:07PM +0200, Stefano Garzarella wrote:
> > I see, so IIUC I can just apply the following change to this patch and avoid
> > to export snp_svsm_vtpm_probe() at all, right?
> >
> >
On Tue, Apr 08, 2025 at 06:31:30PM +0300, Jarkko Sakkinen wrote:
On Tue, Apr 08, 2025 at 10:32:06AM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the
On Fri, Apr 11, 2025 at 11:43:24AM +0100, Sudeep Holla wrote:
On Fri, Apr 11, 2025 at 01:37:31PM +0300, Jarkko Sakkinen wrote:
On Fri, Apr 11, 2025 at 10:08:56AM +0100, Yeoreum Yun wrote:
> For secure partition with multi service, tpm_ffa_crb can access tpm
> service with direct message request
turn values are
always defined, preventing undefined behavior if the unexpected
happens.
Signed-off-by: Purva Yeshi
---
V1 -
https://lore.kernel.org/all/20250409205536.210202-1-purvayeshi...@gmail.com/
V2 - Update commit message to clarify patch adds a sanity check
LGTM!
Reviewed-by: Stefano Garza
On Mon, 14 Apr 2025 at 16:57, Stefano Garzarella wrote:
>
> From: Stefano Garzarella
>
> This driver does not support interrupts, and receiving the response is
> synchronous with sending the command.
>
> So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
>
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need the 4KB int
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
return responses in the same buffer used for commands. This way we
don't need to impl
//lore.kernel.org/linux-integrity/z8sfidehsg6ra...@kernel.org/
[2]
https://lore.kernel.org/linux-integrity/20250410135118.133240-1-sgarz...@redhat.com/
Stefano Garzarella (4):
tpm: add buf_size parameter in the .send callback
tpm: support devices with synchronous send()
tpm/tpm_ftpm_tee: sup
irect message ABI or unsupported ABI version
Signed-off-by: Yeoreum Yun
---
drivers/char/tpm/tpm_crb_ffa.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
LGTM!
Reviewed-by: Stefano Garzarella
diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
On Wed, Apr 30, 2025 at 06:49:37PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 14, 2025 at 04:56:53PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set
On Wed, Apr 30, 2025 at 06:39:58PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 14, 2025 at 04:56:50PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
In preparation for the next commit, add a new `buf_size` parameter to
the `.send` callback in `tpm_class_ops` which contains the entire
On Wed, Apr 30, 2025 at 06:47:51PM +0300, Jarkko Sakkinen wrote:
On Mon, Apr 14, 2025 at 04:56:52PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
So we can set
From: Stefano Garzarella
In preparation for the next commit, add a new `buf_size` parameter to
the `.send` callback in `tpm_class_ops` which contains the entire buffer
size. In this patch it is pretty much ignored by all drivers, but it will
be used in the next patch.
Also rename the previous
On Thu, Apr 10, 2025 at 09:14:58AM +0300, Jarkko Sakkinen wrote:
On Thu, Apr 10, 2025 at 02:25:36AM +0530, Purva Yeshi wrote:
Fix Smatch-detected error:
drivers/char/tpm/tpm-buf.c:208 tpm_buf_read_u8() error:
uninitialized symbol 'value'.
drivers/char/tpm/tpm-buf.c:225 tpm_buf_read_u16() error:
On Tue, Apr 15, 2025 at 08:57:12AM +0100, Yeoreum Yun wrote:
Instread of pr_xxx() macro, use dev_xxx() to print log.
Signed-off-by: Yeoreum Yun
---
drivers/char/tpm/tpm_crb_ffa.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/
nsmit().
Instead of abusing TPM_CHIP_FLAG_IRQ, introduce a new callback
send_recv(). If that callback is defined, it is called in
tpm_try_transmit() to send the command and receive the response on
the same buffer in a single call.
Suggested-by: Jason Gunthorpe
Signed-off-by: Stefano Garzarella
---
in
On Fri, Feb 28, 2025 at 08:28:19PM -0400, Jason Gunthorpe wrote:
On Fri, Feb 28, 2025 at 06:07:19PM +0100, Stefano Garzarella wrote:
+/*
+ * tpm_svsm_remove() lives in .exit.text. For drivers registered via
+ * module_platform_driver_probe() this is ok because they cannot get unbound
+ * at
On Sat, Mar 01, 2025 at 03:45:10AM +0200, Jarkko Sakkinen wrote:
On Fri, Feb 28, 2025 at 06:07:17PM +0100, Stefano Garzarella wrote:
+ int (*send_recv)(struct tpm_chip *chip, u8 *buf, size_t buf_len,
+size_t to_send);
Please describe the meaning and purpose of
On Fri, Feb 28, 2025 at 08:30:09PM -0400, Jason Gunthorpe wrote:
On Fri, Feb 28, 2025 at 06:07:14PM +0100, Stefano Garzarella wrote:
I put RFC back in because we haven't yet decided if this is the best
approach to support SVSM vTPM, but I really like to receive feedbacks
especially fro
On Sat, Mar 01, 2025 at 03:51:46AM +0200, Jarkko Sakkinen wrote:
On Fri, Feb 28, 2025 at 06:07:19PM +0100, Stefano Garzarella wrote:
Add driver for the vTPM defined by the AMD SVSM spec [1].
The specification defines a protocol that a SEV-SNP guest OS can use to
discover and talk to a vTPM
On Mon, Mar 03, 2025 at 08:06:43AM -0600, Tom Lendacky wrote:
On 2/28/25 11:07, Stefano Garzarella wrote:
Some devices do not support interrupts and provide a single operation
to send the command and receive the response on the same buffer.
To support this scenario, a driver could set
On Sat, Mar 01, 2025 at 03:48:35AM +0200, Jarkko Sakkinen wrote:
On Fri, Feb 28, 2025 at 06:07:18PM +0100, Stefano Garzarella wrote:
This is primarily designed to support an enlightened driver for the
The commit message is half-way cut.
I.e. it lacks the explanation of "this".
On Mon, Mar 03, 2025 at 08:28:45AM -0600, Tom Lendacky wrote:
On 2/28/25 11:07, Stefano Garzarella wrote:
This is primarily designed to support an enlightened driver for the
AMD SVSM based vTPM, but it could be used by any TPM driver which
communicates with a TPM device implemented through the
On Thu, Mar 06, 2025 at 11:52:46PM +0200, Jarkko Sakkinen wrote:
On Wed, Mar 05, 2025 at 03:02:29PM -0400, Jason Gunthorpe wrote:
On Wed, Mar 05, 2025 at 10:04:25AM +0100, Stefano Garzarella wrote:
> Jason suggested the send_recv() ops [2], which I liked, but if you prefer to
> avoid t
On Fri, Mar 07, 2025 at 12:15:34AM +0200, Jarkko Sakkinen wrote:
On Wed, Mar 05, 2025 at 10:04:25AM +0100, Stefano Garzarella wrote:
On Tue, Mar 04, 2025 at 10:21:55PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 04, 2025 at 06:56:02PM +0200, Jarkko Sakkinen wrote:
> > On Mon, 2025-03
On Sat, Mar 01, 2025 at 03:48:35AM +0200, Jarkko Sakkinen wrote:
On Fri, Feb 28, 2025 at 06:07:18PM +0100, Stefano Garzarella wrote:
This is primarily designed to support an enlightened driver for the
The commit message is half-way cut.
I.e. it lacks the explanation of "this".
On Mon, Mar 10, 2025 at 12:08:34PM +0100, Borislav Petkov wrote:
On Fri, Feb 28, 2025 at 06:07:15PM +0100, Stefano Garzarella wrote:
Add macros for SVSM_VTPM_QUERY and SVSM_VTPM_CMD calls as defined
in the "Secure VM Service Module for SEV-SNP Guests"
Publication # 58019 Revision:
On Mon, Mar 10, 2025 at 02:51:33PM +0100, Borislav Petkov wrote:
On Mon, Mar 10, 2025 at 08:27:37AM -0500, Tom Lendacky wrote:
I don't think anything needs to be checked or printed.
Yes.
Ack, I removed the check and the print.
@Boris I also removed `ret` to continue the slimming, so the end
otocol.
Signed-off-by: Stefano Garzarella
---
arch/x86/coco/sev/core.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 2166bdff88b7..a2383457889e 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2664,6 +26
.req_complete_mask and .req_complete_val are set to 0.
[1] "Secure VM Service Module for SEV-SNP Guests"
Publication # 58019 Revision: 1.00
Signed-off-by: Stefano Garzarella
---
v3:
- removed send_recv() ops and followed the ftpm driver implementing .status,
.req_com
uests"
Publication # 58019 Revision: 1.00
Co-developed-by: James Bottomley
Signed-off-by: James Bottomley
Co-developed-by: Claudio Carvalho
Signed-off-by: Claudio Carvalho
Signed-off-by: Stefano Garzarella
---
v3:
- renamed header and prefix to make clear it's related to the SVSM vTPM
pro
ux/tree/svsm
[3] "Secure VM Service Module for SEV-SNP Guests"
Publication # 58019 Revision: 1.00
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[4]
https://github.com/coconut-svsm/svsm/commit/6522c67e1e414f192a6f014b122ca8a1066e3bf
rvice Module for SEV-SNP Guests"
Publication # 58019 Revision: 1.00
Co-developed-by: James Bottomley
Signed-off-by: James Bottomley
Co-developed-by: Claudio Carvalho
Signed-off-by: Claudio Carvalho
Signed-off-by: Stefano Garzarella
---
v3:
- removed link to the spec because those URLs ar
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Let's simplify the driver by implementing the new send_recv() op.
Signed-off-by: Stefano Garzarella
---
Note: this is based on "[PATCH v3 0/4] Enlightened vTPM support for S
lore.kernel.org/linux-integrity/z8sfidehsg6ra...@kernel.org/
[2]
https://lore.kernel.org/linux-integrity/20250311094225.35129-1-sgarz...@redhat.com/
Stefano Garzarella (3):
tpm: add send_recv() op in tpm_class_ops
tpm/tpm_ftpm_tee: use send_recv() op
tpm/tpm_svsm: use send_recv() op
d
it is called in
tpm_try_transmit() to send the command and receive the response on
the same buffer in a single call.
Suggested-by: Jason Gunthorpe
Signed-off-by: Stefano Garzarella
---
include/linux/tpm.h | 2 ++
drivers/char/tpm/tpm-interface.c | 7 +++
2 files changed, 9 inser
vision: 1.00
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[4]
https://github.com/coconut-svsm/svsm/commit/6522c67e1e414f192a6f014b122ca8a1066e3bf5
[5] https://github.com/stefano-garzarella/snp-svsm-vtpm
Stefano Garzarella (6):
x86/sev: add
Add macros for SVSM_VTPM_QUERY and SVSM_VTPM_CMD calls as defined
in the "Secure VM Service Module for SEV-SNP Guests"
Publication # 58019 Revision: 1.00
Link:
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Signed-off-by: Stefano
Signed-off-by: James Bottomley
Co-developed-by: Claudio Carvalho
Signed-off-by: Claudio Carvalho
Signed-off-by: Stefano Garzarella
---
James, Claudio are you fine with the Cdb, Sob?
The code is pretty much similar to what was in the initial RFC, but I
changed the context for that I reset the
otocol.
Signed-off-by: Stefano Garzarella
---
arch/x86/coco/sev/core.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 4158e447d645..7e91fae7d43a 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2680,6 +26
Bottomley
Signed-off-by: James Bottomley
Co-developed-by: Claudio Carvalho
Signed-off-by: Claudio Carvalho
Signed-off-by: Stefano Garzarella
---
James, Claudio are you fine with the Cdb, Sob?
The code is based to what was in the initial RFC, but I removed the
tpm_platform module, moved some code in
ublication # 58019 Revision: 1.00
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
Signed-off-by: Stefano Garzarella
---
drivers/char/tpm/tpm_svsm.c | 120
drivers/char/tpm/Kconfig| 10 +++
drivers/char/tp
p, so that
we can also remove the 4KB internal buffer used to cache the response.
Signed-off-by: Stefano Garzarella
---
Note: I don't know how to test this driver, so I just build it.
If someone can test it, or tell me how to do, it will be great!
---
drivers/char/tpm/tpm_ftpm_tee.h | 4 --
dr
1 - 100 of 144 matches
Mail list logo
