linux-kernel - Re: [PATCH v6 05/21] x86/fpu: Make XFD initialization in __fpstate

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]

Message-ID: <761a554a-d13f-f1fb-4faf-ca7ed28d4d3a@redhat.com>
Date:   Mon, 10 Jan 2022 15:18:26 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Borislav Petkov <bp@...en8.de>,
        "Tian, Kevin" <kevin.tian@...el.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Zeng, Guang" <guang.zeng@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Wang, Wei W" <wei.w.wang@...el.com>,
        "Zhong, Yang" <yang.zhong@...el.com>
Subject: Re: [PATCH v6 05/21] x86/fpu: Make XFD initialization in
 __fpstate_reset() a function argument

On 1/10/22 09:52, Borislav Petkov wrote:
> On Mon, Jan 10, 2022 at 05:15:44AM +0000, Tian, Kevin wrote:
>> Thanks for pointing it out! Actually this is one area which we didn't get
>> a clear answer from 'submitting-patches.rst'
> 
> Are you sure? I see
> 
> "Any further SoBs (Signed-off-by:'s) following the author's SoB are from
> people handling and transporting the patch, but were not involved in its
> development. SoB chains should reflect the **real** route a patch took
> as it was propagated to the maintainers and ultimately to Linus, with
> the first SoB entry signalling primary authorship of a single author."

Say a patch went A->B->C->A->D and all of {A,B,C} were involved in the 
development at different times.  The above text says "any further SoBs 
are from people not involved in its development", in other words it 
doesn't cover the case of multiple people handling different versions of 
a patch submission.

The only clear thing from the text would be "do not remove/move the 
author's Signed-off-by", but apart from that it's wild wild west and 
there are contradictions everywhere.

For example:

1) checkpatch.pl wants "Co-developed-by" to be immediately followed by 
"Signed-off-by".  Should we imply that all SoB entries preceded by 
Co-developed-by do not exactly reflect the route that the patch took 
(since there could be multiple back and forth)?

2) if the author sends the patches but has co-developers, should they be 
first (because they're the author) or last (because they're the one 
actually sending the patch out)?

Any consistent rules that I could come up with are too baroque to be 
practical:

1) a sequence consisting of {SoB,Co-developed-by,SoB} does not 
necessarily reflect a chain from the first signoff to the second signoff

2) if you are a maintainer committing a patch so that it will go to 
Linus, just add your SoB line.

3) if you pick up someone else's branch or posted series, and you are 
not in the existing SoB chain, you must add a Co-developed-by and SoB 
line for yourself.  Do not use the document the changes in brackets: 
that is only done by the maintainers when they make changes and do not 
repost for review.

The maintainers must already have a bad case of Stockholm syndrome for 
not having automated this kind of routine check, but it would be even 
worse if we were to inflict this on the developers.  In the end, IMHO 
the real rules that matter are:

- there should be a SoB line for the author

- the submitter must always have the last SoB line

- SoB lines shall never be removed

- maintainers should prefer merge commits when moving commits from one 
tree to the other

- merge commits should have a SoB line too

Everything else, including the existence of Co-developed-by lines, is an 
unnecessary complication.

Paolo