;name" of the nvindex would
change, and it would become useless in all references from other
objects/quotes/…
This logic is explicitly mentioned in that tpm book btw, it took me a
while to grok how great that concept is, since it basically means you
don't have to be concerned about removed/readded nvindexes at all.
Lennart
--
Lennart Poettering, Berlin
e PCRs" and the above is basically what I had in
mind to implement that.
But admittedly I am talking a bit out of my ass here, since I did not
in fact implement the above. But I don't see why it wouldn't work.
> > This logic is explicitly mentioned in that tpm book btw, it took me a
> > while to grok how great that concept is, since it basically means you
> > don't have to be concerned about removed/readded nvindexes at all.
>
> Which TPM book is this?
"A practical guide to TPM 2.0". The one that always shows up in your
google searches...
Lennart
--
Lennart Poettering, Berlin
On Mo, 04.12.23 08:01, James Bottomley (james.bottom...@hansenpartnership.com)
wrote:
> On Mon, 2023-12-04 at 10:20 +0100, Lennart Poettering wrote:
> > On Fr, 01.12.23 17:23, James Bottomley
> > (james.bottom...@hansenpartnership.com) wrote:
> [...]
> > > > > I&
if (!mokx) {
if (status == EFI_NOT_FOUND)
--
2.48.1
Lennart
--
Lennart Poettering, Berlin
On Fr, 21.03.25 15:13, lee joey (joeyli.ker...@gmail.com) wrote:
> Hi Lennart,
>
> Lennart Poettering 於 2025年3月20日 週四 下午8:02寫道：
> >
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> >
> > This original commit this reverts creates a stran
o get them there, then their security value is
kinda weak anyway, because the allowlist that the keyring is is such
an extremely wide net, it's at best a denylist of bad stuff rather
than an allowlist of good stuff at this point. It's kinda undemocratic
too. But anyway, the pros and cons of SB are another discussion. I am
primarily interested in making it optional, so that you can get
security with SB and without SB, because you always have someting to
protect the boot, and always something that protects the rest.
Lennart
--
Lennart Poettering, Berlin
On Mi, 02.07.25 21:40, Mimi Zohar (zo...@linux.ibm.com) wrote:
> On Thu, 2025-03-20 at 13:02 +0100, Lennart Poettering wrote:
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> >
> > This original commit this reverts creates a strange situation: it
> &g
ic device that sprinkles "trust" magic
dust on things: you have to define your objects with a policy that
locks down access based on attestation, pins or other stuff, and it's
just not obvious what that should be here for such a kernel keyring.
Sorry, but this all seems backwards to me: what you propose weakens
the current model afaics, and you insist to be strict in the case where
an explicit request has been made to relax things by turning off SB.
Lennart
--
Lennart Poettering, Berlin
Linux then does the opposite, invents some artificial checks not
even done if SB is on!
I mean, a boot trust chain means: trust what comes before, and
authenticate/measure what comes next before you pass control to it.
But for some reason Linux makes up a different model, where if told to
not authent
