On Sat, 13 Apr 2024 at 11:37, Qinkun Bao wrote:
>
...
> >
> > I think it is a bad idea to go and apply changes all across the boot
> > software ecosystem to measure the same assets into different
> > measurement protocols. I'mm afraid it creates technical debt that will
> > come and bite us in the
Hi all,
Thank you all for the feedback.
> > In Intel, we had discussed and we did see the potential security risk. As I
> > mentioned in the first email, "In case that any the guest component only
> > knows one of vTPM or RTMR, and only extends one of vTPM or RTMR, but the
> > other one only v
; linux-c...@lists.linux.dev; Aktas, Erdem
; Peter Gonda ; Johnson, Simon P
; Xiang, Qinglan
Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for
coexistance of vTPM and RTMR.
On 4/11/24 05:33, Ard Biesheuvel wrote:
> On Thu, 11 Apr 2024 at 12:29, Gerd Hoffmann wr
On 4/11/24 05:33, Ard Biesheuvel wrote:
On Thu, 11 Apr 2024 at 12:29, Gerd Hoffmann wrote:
On Thu, Apr 11, 2024 at 09:56:48AM +, Yao, Jiewen wrote:
Please allow me to clarify what you are proposing:
Do you mean in vTPM case, we extend both, but we only need TCG event log, NOT
CC event lo
On Thu, 11 Apr 2024 at 12:29, Gerd Hoffmann wrote:
>
> On Thu, Apr 11, 2024 at 09:56:48AM +, Yao, Jiewen wrote:
> > Please allow me to clarify what you are proposing:
> > Do you mean in vTPM case, we extend both, but we only need TCG event log,
> > NOT CC event log?
>
> Elsewhere in this thre
On Thu, Apr 11, 2024 at 09:56:48AM +, Yao, Jiewen wrote:
> Please allow me to clarify what you are proposing:
> Do you mean in vTPM case, we extend both, but we only need TCG event log, NOT
> CC event log?
Elsewhere in this thread it was mentioned that writing both vTPM and
RTMR events to the
ject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option
> for
> coexistance of vTPM and RTMR.
>
> Hi,
>
> > Given that RTMR is a proper subset of vTPM (modulo the PCR/RTMR index
> > conversion), I feel that it should be the CoCo firmware's
> >
Hi,
> Given that RTMR is a proper subset of vTPM (modulo the PCR/RTMR index
> conversion), I feel that it should be the CoCo firmware's
> responsibility to either:
> - expose RTMR and not vTPM
> - expose vTPM, and duplicate each measurement into RTMR as they are taken
That approach looks good
Hello all,
On Thu, 11 Apr 2024 at 03:20, Yao, Jiewen wrote:
>
> Hi Dionna/Qinkun
> I am not sure if systemd is the last software in guest we need to patch to
> support coexistence to extend the measurement.
> Are you aware of any other Linux guest software needs to be updated? Such as
> Linux I
Hi Jiewen,
Thank you!
On Wed, Apr 10, 2024 at 3:20 PM Yao, Jiewen wrote:
>
> Hi Dionna/Qinkun
> I am not sure if systemd is the last software in guest we need to patch to
> support coexistence to extend the measurement.
The direct boot patch needs to be patched as well. Here is the link.
efi/l
Hi Dionna/Qinkun
I am not sure if systemd is the last software in guest we need to patch to
support coexistence to extend the measurement.
Are you aware of any other Linux guest software needs to be updated? Such as
Linux IMA (Integrity Measurement Architecture)?
To move this forward.
In Intel,
On Fri, Mar 22, 2024 at 07:56:53AM -0700, Dionna Amalie Glaze wrote:
> On Fri, Mar 22, 2024 at 1:52 AM Gerd Hoffmann wrote:
> >
> > On Fri, Mar 22, 2024 at 02:39:20AM +, Yao, Jiewen wrote:
> > > Please aware that this option will cause potential security risk.
> > >
> > > In case that any the
From: Qinkun Bao
The UEFI v2.10 spec defines the protocol EFI_CC_MEASUREMENT_PROTOCOL
to enable (for example) RTMR-based boot measurement for TDX VMs.
With the current UEFI spec’s “should not” wording and EDK2
implementation, TPM measurement in TDVF is disabled when
RTMR measurement is enabled.
On Fri, Mar 22, 2024 at 7:57 AM Dionna Amalie Glaze
wrote:
>
> On Fri, Mar 22, 2024 at 1:52 AM Gerd Hoffmann wrote:
> >
> > On Fri, Mar 22, 2024 at 02:39:20AM +, Yao, Jiewen wrote:
> > > Please aware that this option will cause potential security risk.
> > >
> > > In case that any the guest c
On Mon, Mar 25, 2024 at 6:07 AM Mikko Ylinen
wrote:
>
> > >
> > > Looking at systemd-boot I see it will likewise not measure to both RTMR
> > > and vTPM, but with reversed priority (use vTPM not RTMR in case both are
> > > present).
> > >
> >
> > Interesting. Thanks for this report. We'll push for
On Fri, Mar 22, 2024 at 1:52 AM Gerd Hoffmann wrote:
>
> On Fri, Mar 22, 2024 at 02:39:20AM +, Yao, Jiewen wrote:
> > Please aware that this option will cause potential security risk.
> >
> > In case that any the guest component only knows one of vTPM or RTMR,
> > and only extends one of vTPM
On Fri, Mar 22, 2024 at 02:39:20AM +, Yao, Jiewen wrote:
> Please aware that this option will cause potential security risk.
>
> In case that any the guest component only knows one of vTPM or RTMR,
> and only extends one of vTPM or RTMR, but the other one only verifies
> the other, then the ch
Please aware that this option will cause potential security risk.
In case that any the guest component only knows one of vTPM or RTMR, and only
extends one of vTPM or RTMR, but the other one only verifies the other, then
the chain of trust is broken.
This solution is secure if and only if all gu
On Thu, Mar 21, 2024 at 9:59 AM qinkun Bao wrote:
>
> From: Qinkun Bao
>
> The UEFI v2.10 spec defines the protocol EFI_CC_MEASUREMENT_PROTOCOL
> to enable (for example) RTMR-based boot measurement for TDX VMs.
> With the current UEFI spec’s “should not” wording and EDK2
> implementation, TPM mea
19 matches
Mail list logo
