Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <303283d9-5f1c-8bc7-6286-ce284de012a8@oracle.com>
Date:   Mon, 6 Jun 2022 16:21:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH] Documentation/security-bugs: overhaul
Content-Language: en-US
To:     Willy Tarreau <w@1wt.eu>
Cc:     Jonathan Corbet <corbet@lwn.net>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, Amit Shah <aams@amazon.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Gustavo A . R . Silva" <gustavoars@kernel.org>,
        Jiri Kosina <jkosina@suse.cz>,
        Kees Cook <keescook@chromium.org>,
        Laura Abbott <labbott@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Solar Designer <solar@openwall.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Thorsten Leemhuis <linux@leemhuis.info>,
        Tyler Hicks <tyhicks@canonical.com>,
        Will Deacon <will@kernel.org>
References: <20220531230309.9290-1-vegard.nossum@oracle.com>
 <20220601031254.GB26318@1wt.eu>
 <42200c3e-fb39-ddab-3d68-5dfb5eb89451@oracle.com>
 <20220603064924.GC29741@1wt.eu>
From:   Vegard Nossum <vegard.nossum@oracle.com>
In-Reply-To: <20220603064924.GC29741@1wt.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d0ExT1Jxb3MzYlhvNVFmbk9tY1lta1NwVEpKUHlMZTJ3ckxqOXNTTlVtK04w?=
 =?utf-8?B?WDFaODUwUHlBRWpwV1dPYTJVUWw4Vjk3VFNERUVEMHIwd3JwaWIxWUZWenVi?=
 =?utf-8?B?a3d6dnBQVTNQdTJRMFVxU1RuR2gxL2pQL29LRFdOVzM2bkh5UDZWQTg2TEdP?=
 =?utf-8?B?RmREY0V5dnVFWVVtRXN4QTQ0TXRzTjhMVkxhOE93Q1dJOUprMW9rMkx2RWg1?=
 =?utf-8?B?cG5KRjJPSXo2T3ZSWk9rMXhyUTRUYVlLaFZBS2lqRkJuSmw2aWVGKzVEMzlX?=
 =?utf-8?B?UXp5UmFkck4vWDRKZEVZOTFscmU3aTI2Y3hRcHdYOVI3YjRqRXlzNEQ0RjA5?=
 =?utf-8?B?Ry9FckRlQTE3eHREcTBwTEVaOXY0cHZLUlRvVUpZazJEeFc4QVQ5aGVoMlBV?=
 =?utf-8?B?em9Jbi9OVCt4UUlUeVhNU1JFRkZNNWsvd0FVRmNjT3BUOG9ETWE5d0F4MGVx?=
 =?utf-8?B?NG5vcUl3VGdKT2ZjMzJHMG91Uzc0YmZUMGRHVXhyQ0pxSmFadFRhN1Q5Y2pB?=
 =?utf-8?B?aW1hSHVodFFGK05LU245aE12UTByOVNLTjF4UXRlbkhTU1ArUzRLcHNiRjkz?=
 =?utf-8?B?bWhESmdQR2ZGRzVkWCtlTjdPUFhBWThYSVZ4NktoNllGQUR6eVlLT2pFWlUr?=
 =?utf-8?B?RnE3WkFjY2t5d1dtY2ViMGxVS2hkMkxrYlViRkdIODVqc1VzVXZFOFhpdlZ4?=
 =?utf-8?B?bVJaR3FVYXBUaTl2WmdKVTRrY0doM1NsNHhiUVpuc2htODhNZW04aHJEaURx?=
 =?utf-8?B?MHd5WGNXYWJ4L1pmNWZFTjBjS1NBRlp2dlVST1V1Q09acHNLVWg5b0JRSVZy?=
 =?utf-8?B?OVB2V05zS0xWNGdXUk1Kc2ZxTU84cWVDZVl1VXYvczJocHc5S3QyMnNQQmNq?=
 =?utf-8?B?QVliVlc2ZlVob2Y5NTNhTnppVnNkVHlITEdPbG16MzlLWlpKYU5BQmR6M3hG?=
 =?utf-8?B?THZEcjBwM3VDTmF2RWRna21KMHpSa3crYXlTVEE2RlRMaGdmQmFpNjVGK0Mx?=
 =?utf-8?B?Y21HajZYdllybFUyeEdwZlkxRHM5QmtyVmlaOGRYUmZjVWtBMUUydmkzLzd5?=
 =?utf-8?B?dktZcVd0YytPSTNOU3hnVkJjdTFCUFJtOW02RUkyMFJ0M3h6RndUSXgvUExv?=
 =?utf-8?B?aFJkVU52NGZDQzdYN01nT1YyUzdaSk5zZUhPNFBSQnZ3UnB6cGdsQVVuSzlw?=
 =?utf-8?B?bzlETmN2K2NQakhkZnBNeVJBbzFGeWcvU2R3b09oSXlZS2wrSTIvY21mMW5P?=
 =?utf-8?B?UHY4Qy9YNTU5NXZNVW5nZTBFZ1FnSjZLVkY1dWh2RHNHTlBjcWhrTG9iZzVJ?=
 =?utf-8?B?aEIzUG9oVW45RW5yZ3JWMjBjUmZrNlV1cFZWenZkN0dUa29hL2YwcUFycExE?=
 =?utf-8?B?c241Z1VJTVJZbDNoa1VsMURXSEZzVUN2WjQzZ2Y2aWVvdlU3S2RRVDhjRHVy?=
 =?utf-8?B?NTg1RlN5WVhNZll6ZlAxWnBOY3dJS3dHREc1MFBFSDIrWTM2bVVNYnpnSExu?=
 =?utf-8?B?ZDAvRHlOWm0xaUdkYXVqRHNMWXZuMEdhVVhrM0JJeXpHcUZzOUwzeFYvZ2Vk?=
 =?utf-8?B?WXVHS3NnTVloUVg5YTdKdmRMTnlYN3RQVFh3ZEpEVjJmVUpiUWozSlE0RlpJ?=
 =?utf-8?B?OHhxOGphVCtCR2daZlVHbXBBbjBMMTRyLy9OSlFsZ0JiQ29KUnF0R21ZWWpv?=
 =?utf-8?B?KzdFM3E4OCt6ZHhYckhoR2FGMUtta2RlUlM4TmNxVzlxWlRUUW94Nk1EOE9h?=
 =?utf-8?B?azBRL1R0NWw4UWUxeEVFWHpFSHBWOSt4STFwREkrTlkvckNETWVDazMvUUdj?=
 =?utf-8?B?OUNpTDJhRmpTQnJQVXp0a05ERlhaNkE0cWZKNUdwclcwWERSV2w3Mk9JdzhQ?=
 =?utf-8?B?d1hzblZGZmVhM3lod3EzM0FZa2tvVDJ6OEl0cnZucEFXMjZFSmtkTHRTTTBF?=
 =?utf-8?B?cW84d3MrTzRhamdHbWdHNU9ESjhDUWx1Zk03U21kV3k2eXJwWXcwSTd1c29s?=
 =?utf-8?B?bTJZemQ1ZVBxRlFIZGwxck1UTlFYNGNVUmN2eDRaZGlMK01lTnU3ZncycUZJ?=
 =?utf-8?B?SitNbzdQL0RHMXhKNXZyYTdFUkpvaHJMalNVNUhzY2dQSWdjZ0VTY1A5dUFX?=
 =?utf-8?B?NzhCWUV1SUZNTWM4RUZXNTVvMm81UnFpWlp2MkRyOGxXUyt3MC9qR01wYXpP?=
 =?utf-8?B?dHpiVXBNY3hNcTRPMEVoUnBJcU1OVis0S05hNU14OFRqdlhpZzdXUTd6Q0dz?=
 =?utf-8?B?Y0R1RC9ydVhwSFVrK3A5bCtYa002cHRJUStIQTh1eStnckptc25IQlJVellM?=
 =?utf-8?B?bk9EQ1hoTkVOSjJPdGRYUzV5VTMycGo4WldaLzNzQzZZM0Nramtsc2x6ODdD?=
 =?utf-8?Q?V+M4o59WRBWf/Bvw=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dff59f0d-6155-4068-ad68-08da47c7e5f2
X-MS-Exchange-CrossTenant-AuthSource: PH0PR10MB5433.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2022 14:21:51.2059
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: fBAmR30CIWjShXgq1GWpcccMM3wWk8ghG6F8JtCbcJ3+Gb9aU0LTbQOLtMKjbxkKElkK2X8s4GXb3SqwRLpmGHP/WU64WNbY9YLA5xJKgtY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5846
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-06-06_04:2022-06-02,2022-06-06 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0
 malwarescore=0 mlxlogscore=999 adultscore=0 mlxscore=0 phishscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2204290000 definitions=main-2206060066
X-Proofpoint-GUID: SQflM3O3A3GC89IhO14VJ5BOrHCR7767
X-Proofpoint-ORIG-GUID: SQflM3O3A3GC89IhO14VJ5BOrHCR7767
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 6/3/22 08:49, Willy Tarreau wrote:
> On Thu, Jun 02, 2022 at 05:34:48PM +0200, Vegard Nossum wrote:
>> I think there's also an argument for encouraging reports whether the
>> person has a patch or not, presumably it is better to know about an
>> issue so it can be prioritized against all other known issues, no?
> 
> It depends. For a few months now we've seen a huge increase of reports
> for things ranging from "if I modify this driver this way I can make it
> fail so I think it could be insecure" to "this outdated driver that is
> not enabled in any distro anymore has a one-byte info leak bug, can I
> get my CVE". There have been weeks with 2 of them every single day. It's
> obvious that there's a quest of a CVE to be held as a trophee, and that
> for a CVE, a security bug is needed, and that for this it ought to be
> demonstrated that some random bugs in certain circumstances could have
> a security impact. Thus there is a huge bias.
> 
> I would really like it if we could get back to what works fine: use> the security list only for currently exploitable bugs that are not
> trivially worked around, and please use public lists for everything
> else. It takes way longer to fix a bug in a small team having to
> forward messages to maintainers, trying to fix in a small group without
> knowing if we're going to break someone's use case than it takes when
> a non-critical issue is discussed publicly. And security fixes that
> cause regressions are the worst that can happen because they discourage
> users from regularly applying fixes. As such the vast majority of bugs
> ought to be discussed publicly, on the relevant lists. Bug given that
> some reporters are not interested in getting a bug fixed but just in
> getting a trophee, that's difficult to get a patch from them and to
> move the discussion to a public place where the fix will just be
> handled like with any regular bug.

I think this points to a bigger problem, but not with CVEs being held up
as trophies. There's already a huge monetary incentive to find bugs and
sell them as 0-days so IMHO we _should_ be encouraging people to find
bugs and either fix or report them, whether privately or publicly. If
having CVEs helps with that, that ought to be a good thing...

If you think a reported issue is not security-relevant, can you not
simply ask/encourage the reporter to make a public post instead?

If the security team is swamped with legitimate, security-relevant
reports, then that sounds like an issue with manpower and/or
organization. In my (admittedly limited) experience, Linus tends to be
one of the first to reply, so maybe having a designated person or group
to triage issues (maybe in a rota system) before engaging the rest of
the team could take some of the pressure off?

> I don't know how to adjust the wording but I think that the spirit is
> there. By the way there's something I would like to see added as well
> to this, which is the the ultimate goal is that a bug fixed is perfectly
> understood and documented. So either the details of the cause of the bug
> are in the commit message, or the researchers prefer not to publish them
> yet because they intend to present them at a conference or in a blog
> article (pretty common), which will serve as a reference for to get all
> the gory details. But in this case there must be a reasonable delay, it's
> not acceptable that the details of the problem are withheld for months.
> 
> As such I think that we could mention something along:
> 
>   Upon reporters' request in case a forthcoming presentation of the issue
>   is planned, it may occasionally be accepted to temporarily keep out some
>   of the detailed impacts of the issue, however the security team reserves
>   the right to publicize these details if no other publication happens in
>   a reasonable time frame or as soon as the fixes are found to cause a
>   regression.
> 
> Because quite frankly, not being able to explain exactly why a patch is
> done this way and not slightly differently is not acceptable.

This unfortunately directly contradicts the current policy as stated:

"All other information submitted to the security list and any followup
discussions of the report are treated confidentially even after the
embargo has been lifted, in perpetuity."

So again, unless there's a clear consensus to change this, I wouldn't be
comfortable making the change now.

If I could make a different suggestion (which is in the same spirit as
the rewrite, actually), the security team could encourage the reporter
to report to linux-distros once there is a patch or the patch is public
-- that way, it's: 1) not on the security team to disclose anything, 2)
distros get a heads up on the patch, and 3) everybody gets to know about
the security impact of the bug when it is eventually posted to
oss-security within 1-2 weeks.

Thanks for your comments/explanations, it certainly helps to have more
perspective.


Vegard