From: Patrick Steinhardt <ps@pks.im>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: Stefan Berger <stefanb@linux.ibm.com>,
Daniel Axtens <dja@axtens.net>,
leif@nuviainc.com
Subject: Re: [PATCH v2 00/15] Dynamic allocation of memory regions and IBM vTPM v2
Date: Fri, 24 Jun 2022 08:16:40 +0200 [thread overview]
Message-ID: <YrVWyFxo92AWjvsj@xps> (raw)
In-Reply-To: <20220623171604.reemwtpfl4h5wuvy@tomti.i.net-space.pl>
[-- Attachment #1: Type: text/plain, Size: 4165 bytes --]
On Thu, Jun 23, 2022 at 07:16:04PM +0200, Daniel Kiper wrote:
> 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.
Yes, I am. I noticed at a later point that I accidentally tested v2 and
already re-did the tests on v3 with the same results.
Patrick
> 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
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2022-06-24 6:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-28 6:22 [PATCH v2 00/15] Dynamic allocation of memory regions and IBM vTPM v2 Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 01/15] grub-shell: only pass SeaBIOS fw_opt in for x86 BIOS platforms Daniel Axtens
2022-04-06 17:18 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 02/15] mm: assert that we preserve header vs region alignment Daniel Axtens
2022-04-06 17:20 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 03/15] mm: when adding a region, merge with region after as well as before Daniel Axtens
2022-04-07 13:55 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 04/15] mm: debug support for region operations Daniel Axtens
2022-04-07 13:57 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 05/15] mm: Drop unused unloading of modules on OOM Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 06/15] mm: Allow dynamically requesting additional memory regions Daniel Axtens
2022-04-07 14:02 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 07/15] efi: mm: Always request a fixed number of pages on init Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 08/15] efi: mm: Extract function to add memory regions Daniel Axtens
2022-04-07 14:08 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 09/15] efi: mm: Pass up errors from `add_memory_regions ()` Daniel Axtens
2022-04-07 14:15 ` Daniel Kiper
2022-03-28 6:22 ` [PATCH v2 10/15] efi: mm: Implement runtime addition of pages Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 11/15] ieee1275: request memory with ibm, client-architecture-support Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 12/15] ieee1275: drop len -= 1 quirk in heap_init Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 13/15] ieee1275: support runtime memory claiming Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 14/15] [RFC] Add memtool module with memory allocation stress-test Daniel Axtens
2022-03-28 6:22 ` [PATCH v2 15/15] ibmvtpm: Add support for trusted boot using a vTPM 2.0 Daniel Axtens
2022-04-07 14:41 ` [PATCH v2 00/15] Dynamic allocation of memory regions and IBM vTPM v2 Daniel Kiper
2022-04-14 15:30 ` Daniel Kiper
2022-05-18 15:24 ` Stefan Berger
2022-05-19 16:34 ` Daniel Kiper
2022-05-29 5:55 ` Patrick Steinhardt
2022-06-23 17:16 ` Daniel Kiper
2022-06-24 6:16 ` Patrick Steinhardt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YrVWyFxo92AWjvsj@xps \
--to=ps@pks.im \
--cc=dja@axtens.net \
--cc=grub-devel@gnu.org \
--cc=leif@nuviainc.com \
--cc=stefanb@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.