lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Feb 2021 19:22:45 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Matthew Garrett <mjg59@...f.ucam.org>
Cc:     Matthew Garrett <matthewgarrett@...gle.com>,
        linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-pm@...r.kernel.org, keyrings@...r.kernel.org,
        zohar@...ux.ibm.com, jejb@...ux.ibm.com, corbet@....net,
        rjw@...ysocki.net, Matthew Garrett <mjg59@...gle.com>
Subject: Re: [PATCH 3/9] security: keys: trusted: Parse out individual
 components of the key blob

On Mon, Feb 22, 2021 at 07:36:27AM +0000, Matthew Garrett wrote:
> On Sat, Feb 20, 2021 at 05:05:36AM +0200, Jarkko Sakkinen wrote:
> > On Sat, Feb 20, 2021 at 01:32:49AM +0000, Matthew Garrett wrote:
> > > Performing any sort of state validation of a sealed TPM blob requires
> > > being able to access the individual members in the response. Parse the
> > > blob sufficiently to be able to stash pointers to each member, along
> > > with the length.
> > > 
> > > Signed-off-by: Matthew Garrett <mjg59@...gle.com>
> > 
> > I'll just say LGTM for now. Did not see anything obviously wrong in
> > the code change (and does make sense to nitpick minor things just
> > yet).
> > 
> > Need to understand the whole use case just a little bit better.
> 
> I wrote this up with some more detail at 
> https://mjg59.dreamwidth.org/55845.html - it seemed longer than
> appropriate for a commit message, but if you'd like more detail
> somewhere I can certainly add it.

Thanks (bookmarked). I'll read it before reviewing +1 version.

Requiring a config flag is something that slows down adoption in the
stock kernels.

Since we are talking about hibernate the decision whether to have this
feature set, does not have to be something that needs to be changed
dynamically to a running system.

So: maybe the best compromise would be to have it kernel command line
option? That way it's easier feature to adapt (e.g. with GRUB
configuration) and to enable in the kernel.

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ