linux-kernel - Re: [PATCH v12 16/37] x86/ptrace: Add FRED additional information to the pt

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]

Date:   Tue, 28 Nov 2023 09:18:21 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Borislav Petkov <bp@...en8.de>, Xin Li <xin3.li@...el.com>
CC:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-edac@...r.kernel.org, linux-hyperv@...r.kernel.org,
        kvm@...r.kernel.org, xen-devel@...ts.xenproject.org,
        tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
        x86@...nel.org, luto@...nel.org, pbonzini@...hat.com,
        seanjc@...gle.com, peterz@...radead.org, jgross@...e.com,
        ravi.v.shankar@...el.com, mhiramat@...nel.org,
        andrew.cooper3@...rix.com, jiangshanlai@...il.com,
        nik.borisov@...e.com
Subject: Re: [PATCH v12 16/37] x86/ptrace: Add FRED additional information to the pt_regs structure

On November 28, 2023 12:51:22 AM PST, Borislav Petkov <bp@...en8.de> wrote:
>On Mon, Oct 02, 2023 at 11:24:37PM -0700, Xin Li wrote:
>> FRED defines additional information in the upper 48 bits of cs/ss
>> fields. Therefore add the information definitions into the pt_regs
>> structure.
>> 
>> Specially introduce a new structure fred_ss to denote the FRED flags
>> above SS selector, which avoids FRED_SSX_ macros and makes the code
>> simpler and easier to read.
>> 
>> Signed-off-by: H. Peter Anvin (Intel) <hpa@...or.com>
>
>You and hpa need to go through all the patches and figure out who's the
>author that's going to land in git.
>
>Because this and others have hpa's SOB first, suggesting he's the
>author. However, the mail doesn't start with
>
>From: H. Peter Anvin (Intel) <hpa@...or.com>
>
>and then git will make *you* the author.
>
>> Tested-by: Shan Kang <shan.kang@...el.com>
>> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>> Signed-off-by: Xin Li <xin3.li@...el.com>
>
>...
>
>>  	union {
>> -		u64	ssx;	// The full 64-bit data slot containing SS
>> -		u16	ss;	// SS selector
>> +		/* SS selector */
>> +		u16		ss;
>> +		/* The extended 64-bit data slot containing SS */
>> +		u64		ssx;
>> +		/* The FRED SS extension */
>> +		struct fred_ss	fred_ss;
>
>Aha, sanity about the right comments has come to your mind in this next
>patch. :-P
>
>Just do them right in the previous one.
>
>>  	/*
>> -	 * Top of stack on IDT systems.
>> +	 * Top of stack on IDT systems, while FRED systems have extra fields
>> +	 * defined above for storing exception related information, e.g. CR2 or
>> +	 * DR6.
>
>Btw, I really appreciate the good commenting - thanks for that!
>

For Xin, mainly:

Standard practice is:

1. For a patch with relatively small modifications, or where the changes are mainly in comments or the patch message:

Keep the authorship, but put a description of what you have changed in brackets with your username at the bottom of the description, immediately before Signed-off-by:

[ xin: changed foo, bar, baz ]


2. For a patch with major rewrites:

Take authorship on the From: line, but have an Originally-by: tag (rather than a Signed-off-by: by the original author):

Originally-by: Someone Else <someone@...ewhere.dom>


3. For a patch which is fully or nearly fully your own work (a total rewrite, or based on a concept idea rather than actual code), credit the original in the patch comment:

Based on an idea by Someone Else <someone@...ewhere.dom> (optional link to lore.kernel.org).