grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 00/15] Dynamic allocation of memory regions and IBM vTPM v


From: Daniel Kiper
Subject: Re: [PATCH v2 00/15] Dynamic allocation of memory regions and IBM vTPM v2
Date: Thu, 23 Jun 2022 19:16:04 +0200
User-agent: NeoMutt/20170113 (1.7.2)

Huh! For some reason I missed this email... Sorry folks about that!

On Sun, May 29, 2022 at 07:55:00AM +0200, Patrick Steinhardt wrote:
> On Thu, May 19, 2022 at 06:34:48PM +0200, Daniel Kiper wrote:
> > On Wed, May 18, 2022 at 11:24:48AM -0400, Stefan Berger wrote:
> > > On 4/14/22 11:30, Daniel Kiper wrote:
> > > > On Thu, Apr 07, 2022 at 04:41:04PM +0200, Daniel Kiper wrote:
> > > > > On Mon, Mar 28, 2022 at 05:22:25PM +1100, Daniel Axtens wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > This is, at long last, an updated version of my series extending 
> > > > > > Patrick's
> > > > > > dynamic memory regions to ieee1275.
> > > > > >
> > > > > > Noteworthy changes:
> > > > > >
> > > > > >   - reworked debug prints as grub_dprintfs. Folded the ieee1275 
> > > > > > ones into the
> > > > > >     ieee1275 patches.
> > > > > >
> > > > > >   - reworked the ieee1275 runtime memory claiming to be more 
> > > > > > resilient and better
> > > > > >     documented.
> > > > > >
> > > > > >   - fixed comment style and hopefully addressed all other change 
> > > > > > requests.
> > > > > >
> > > > > >   - grub will now try asking for contiguous memory and then, if 
> > > > > > that fails, for
> > > > > >     discontiguous memory - in case region merging with the 
> > > > > > discontiguous memory
> > > > > >     is sufficient to allow the eventual allocation to succeed.
> > > > >
> > > > > Patrick, all mm and EFI code got my RB. Could you test it with your
> > > > > Argon changes? If these changes pass your tests I will merge them.
> > > >
> > > > Patrick, ping?
> > > >
> > > > To be more precise, I am thinking about the patches up to #10.
> > > >
> > > > Daniel
> > >
> > > Any way we can make progress with this series before it gets all forgotten
> > > about?
> >
> > It is not and it will not be forgotten. I am waiting for some allocator
> > tests reports. When I get them I will merge allocator stuff and review
> > the rest of the code from this patch series. Sadly folks who are going
> > to test the code are busy with other stuff. Though I am pinging them...
> >
> > Anyway, sorry for delay...
> >
> > Daniel
>
> Sorry for the delay here, and thanks for the nudge. I've found a few
> quiet moments this morning to rebase my Argon2 patch series for LUKS2 on
> top of this series and found everything to work as expected. Decrypting
> a volume with a memory hardness of 2GB RAM worked just fine on an EFI
> x64 system. So this series is:
>
>     Tested-by: Patrick Steinhardt <ps@pks.im>

Patrick, thanks a lot for doing tests!

Here I would like to thank Patrick, Stefan, Daniel, Glenn and other
folks who were working on this feature! It is very important and long
awaited improvement for the GRUB memory manager (everyone who was
looking at it knows it is one of the most complicated parts of the
GRUB). This patch set unblocks and makes possible work on Argon2,
appended signature secure boot support, IBM vTPM, etc.

If I do not hear any objections by the end of this week I will be
pushing into master v3 of this patch set [1] (Patrick, I hope you are OK
with me adding your Tested-by there) together with the other patches
which got my RB up until now.

I will be reviewing appended signature secure boot support, IBM vTPM,
etc. patches in the following weeks.

> I'm going to revive my own patch series and send it in for review
> soonish. The nice thing of having waited so long is that Argon2 support
> has meanwhile landed in libgcrypt, so that should make it easier to
> integrate it into GRUB.

Nice to hear that.

Daniel

[1] https://lists.gnu.org/archive/html/grub-devel/2022-04/msg00064.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]