Re: [PATCH v11 00/20] x86: Trenchboot secure dynamic launch Linux kernel support

["Jarkko Sakkinen" <jarkko@kernel.org>]

On Fri Nov 1, 2024 at 11:13 PM EET, Jarkko Sakkinen wrote:
> On Fri Nov 1, 2024 at 10:34 PM EET, Thomas Gleixner wrote:
> > On Fri, Nov 01 2024 at 12:28, Jarkko Sakkinen wrote:
> > > On Fri Sep 13, 2024 at 11:04 PM EEST, Ross Philipson wrote:
> > >> A quick note on terminology. The larger open source project itself is called
> > >> TrenchBoot, which is hosted on Github (links below). The kernel feature enabling
> > >> the use of Dynamic Launch technology is referred to as "Secure Launch" within
> > >> the kernel code. As such the prefixes sl_/SL_ or slaunch/SLAUNCH will be seen
> > >> in the code. The stub code discussed above is referred to as the SL stub.
> > >
> > > 1. I don't see any tags in most of the patches so don't get the rush. This
> > >    includes also patches for x86. Why I would care to review TPM patches
> > >    when there is over a dozen unreviewed and untested patches before it?
> > > 2. TPM patches have been in circulation in and out of the patch set
> > >    for some time now with little or no improvement.
> > >
> > > Why the sudden buzz? I have not heard much about this since last early
> > > summer.  Have to spend some time recalling what this is about anyway. I
> > > cannot trust that my tags make any sense before more reviewed/tested-by
> > > tags before the TPM patches.
> >
> > If I intend to merge the patches then I surely have looked at them
> > deeply. I don't have to send a reviewed-by just to apply them
> > afterwards.
> >
> > There was enough motion on these patches and this posting is in your
> > inbox for 6 weeks now without any reaction from you.
> >
> > The TPM changes are very much independent from the x86 specific ones, so
> > why do you want x86 review tags in order to look at the ones which are
> > specific to your subsystem especially as some of them seem to address
> > real short comings there independent of trenchboot.
>
> I think we can sort them out independently as long as we find a
> conclusion how to address locality change.

And to be fair: there was no reaction from anyone. It is mostly x86
patch set, meaning that I was waiting for some reaction first from that
side.  And I did respond to that when it came.

IMHO: let's get a solution for that one problem and then it should be
fine as far as I'm concerned.

BR, Jarkko