linux-kernel - Re: [GIT PULL 00/13] First batch of EFI updates for v4.13

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Jun 2017 09:35:23 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>
Subject: Re: [GIT PULL 00/13] First batch of EFI updates for v4.13

On 5 June 2017 at 09:07, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>
>> (trim cc)
>>
>> On 2 June 2017 at 13:51, Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>> > The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:
>> >
>> >   Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)
>> >
>> > are available in the git repository at:
>> >
>> >   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next
>> >
>> > for you to fetch changes up to 3acbd5a24ab9d9a82c56d9018f4d340fa574b91d:
>> >
>> >   efi: arm: enable DMI/SMBIOS (2017-06-02 13:38:56 +0000)
>> >
>> > ----------------------------------------------------------------
>> > First batch of EFI changes for v4.13:
>> > - rework the EFI capsule loader to allow for workarounds for non-compliant
>> >   firmware to be implemented more easily and in a more self contained
>> >   manner (Ard)
>> > - implement a capsule loader quirk for Quark X102x, which prepends a
>> >   security header in a non-compliant way (Jan Kiszka)
>> > - enable SMBIOS/DMI support for the ARM architecture (Ard)
>> > - add EFI_PGT_DUMP support for x86_32 and kexec (Sai Praneeth)
>> > - some other cleanups
>> >
>> > ----------------------------------------------------------------
>> > Andy Lutomirski (1):
>> >       x86/efi: Clean up efi CR3 save/restore
>> >
>> > Ard Biesheuvel (4):
>> >       efi/capsule-loader: Use a cached copy of the capsule header
>> >       efi/capsule-loader: Redirect calls to efi_capsule_setup_info via weak alias
>> >       efi/capsule-loader: Use page addresses rather than struct page pointers
>> >       efi: arm: enable DMI/SMBIOS
>> >
>> > Fabian Frederick (1):
>> >       efi/capsule: Remove NULL test on kmap()
>> >
>> > Geliang Tang (1):
>> >       efi/efi_test: Use memdup_user() helper
>> >
>> > Jan Kiszka (5):
>> >       efi/capsule: Fix return code on failing kmap/vmap
>> >       efi/capsule: Remove pr_debug on ENOMEM or EFAULT
>> >       efi/capsule: Clean up pr_err/info messages
>> >       efi/capsule: Adjust return type of efi_capsule_setup_info
>> >       efi/capsule: Add support for Quark security header
>> >
>> > Sai Praneeth (1):
>> >       x86/efi: Add EFI_PGT_DUMP support for x86_32 and kexec
>> >
>>
>> All,
>>
>> I just noticed that this patch lacks my signoff. This is due to the
>> fact that Matt queued this particular patch, and I didn't update the
>> branch to add my sob, so it is only signed off by Matt not me.
>>
>> How should we handle this now, and in the future? Matt and I share
>> maintainership responsibilities, and so everything that gets queued
>> into the EFI tree may be treated as signed off by either and/or the
>> both of us. For multi-maintainer trees that get pulled directly, this
>> is usually not an issue AFAIK, but given that Ingo is the one that
>> deals with EFI usually, and prefers to apply the patches individually,
>> this may  get flagged as a missing signoff.
>
> So the root problem is that that's not the proper usage of SOB: SOB tracks the
> true propagation of patches, it's not an Acked-by tag.
>
> What should be added instead in such cases is an Acked-by or Reviewed-by from your
> co-maintainer when you apply the patch - and a SOB of yourself. That is how we are
> doing it in -tip: you'll see that 99% of the patches there get signed off by only
> one of the co-maintainers.
>

OK, so by that reasoning, having a mix of patches sob'ed by Matt xor
sob'ed by me in the same pull request is fine. Are all patches in -tip
acked/rb'd by the co-maintainers that did not do the signoff? If not,
why should that requirement exist for the EFI tree?

>> In any case, I am happy to respin the patches, re-sign the tag etc if this is
>> deemed necessary.
>
> It would be nice to fix your SOB flow: the maintainer who queues up a patch should
> add the SOB, and add an Acked-by of the co-maintainer if the co-maintainer agrees
> with the patch as well. The tree should typically not be rebased after that point
> (especially not by the other co-maintainer) - that's just indicative of a messy
> workflow.
>

OK, so this is exactly what we have in the queue right now, and what I
sent the pull request for.

-- 
Ard.