linux-kernel - Re: [RFC PATCH v3] selftest/x86/meltdown: Add a selftest for meltdown

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:   Wed, 16 Nov 2022 14:57:22 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>, Aaron Lu <aaron.lu@...el.com>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>,
        "Yin, Fengwei" <fengwei.yin@...el.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3] selftest/x86/meltdown: Add a selftest for meltdown

On 11/14/22 22:54, Greg KH wrote:
> On Tue, Nov 15, 2022 at 10:15:03AM +0800, Aaron Lu wrote:
>> I came to the conclusion that this work is OK to submit with all of the
>> steps I listed above (copyright notices, license terms and relicensing)
>> by strictly following all of the processes required by my employer.
>>
>> This does not include a Signed-off-by from a corporate attorney.
> Please get that, as that is what I asked for in order for us to be able
> to accept this type of change.

Hi Greg,

Can you share any more of what triggered this new requirement?

We can, for instance, be flexible on the license that this is submitted
with (original zlib versus GPLv2).  I've also been in contact with the
(presumed) original authors of this code in the past.  If there are
concerns about its provenance, I'd be happy to try to work with them to
get it in to shape.

But, I feel like I'm poking around in the dark here.  I'm not quite sure
what triggered this new requirement or quite how to remedy it.

I'm also a _bit_ worried that I as a maintainer was about to do
something wrong here.  Personally, I'm quite happy with Aaron's due
diligence here and I was *really* close to merging this code.  Is there
some documentation that could be improved here?