Guidelines for research on the kernel community [LWN.net]

As part of the response to last year's UMN fiasco, Kees Cook and a group of collaborators have put together a set of guidelines for researchers who are studying how the kernel-development community (or any development community, really) works. That document has just been merged into the mainline as part of the 5.18 merge window.

This document seeks to clarify what the Linux kernel community considers acceptable and non-acceptable practices when conducting such research. At the very least, such research and related activities should follow standard research ethics rules.

Mostly reasonable

Posted Mar 22, 2022 21:52 UTC (Tue) by anadav (subscriber, #99427) [Link] (5 responses)

The document is mostly reasonable. However, the example that is included in the article implies that access should be provided to the source code of the tool that found the issue.

This might not be ok with researchers who are still developing their tool. They might not even be inclined to share too many details - during the research phase - about what exactly they do. There are many reasons why a researcher would not be willing to be fully open about these issues, for instance IP and scooping.

I therefore think that if a researcher can trigger a bug without the tool that found the bug (i.e., by creating a custom test-case) or even by reasoning about the code, this should be enough.

Researchers should not be held to higher standards than everybody else.

[ Admittedly, I contributed in the past bug fixes to KVM based on bugs that were found with a tool that I could not share and was not inclined to share too many details about. ]

Mostly reasonable

Posted Mar 22, 2022 22:27 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> Researchers should not be held to higher standards than everybody else.

Suggesting that they hold themselves to a higher standard without requiring it seems fine to me.

Mostly reasonable

Posted Mar 22, 2022 23:34 UTC (Tue) by cypherpunks2 (guest, #152408) [Link] (1 responses)

While you may not have been allowed to share the tool or provide too many details for legal or contractual reasons, you should have when it's actually up to you if your goal is to improve the security or reliability of open source software. I can understand waiting some time before releasing details, but hoarding technology that can better the world is something I believe is inexcusable, especially if it is done due to the mislead belief that it's "keeping it out of the hand of bad guys".

Mostly reasonable

Posted Mar 23, 2022 4:49 UTC (Wed) by milesrout (subscriber, #126894) [Link]

I think this is taking things a little too far. It was once widely accepted that there is no obligation to share software. The "free software" idea that is IF you share software, THEN you ought to share the source code. That is conditional. There is no expectation that you ought to share every piece of software you write or use. There is no expectation that if you share the result of using software that you must share the software itself. If one's goal is to improve the security and reliability of free software while making a living and building a sustainable business then it very easily could be that the best strategy for doing that is to keep some security-bug-finding tactics close to one's chest. In the long term, having that sustainable business means that one can keep doing the bug-finding long term. A community of independent and sustainable security researchers is going to be better for the security of software in the long term than a bunch of people all just doing it in their spare time because they feel obliged to release their tools as free software, free of charge and free of encumbrances, eliminating their only potential source of revenue on which to build a sustainable business.

Mostly reasonable

Posted Mar 23, 2022 10:25 UTC (Wed) by error27 (guest, #8346) [Link]

It doesn't say they have to release the tool just that they should say when it is found by static analysis or whatever.

Static analysis bugs are reviewed differently, because with static analysis you can just say, "The tool is wrong. That combination of conditions is impossible." But if it's a bug which was found in run time, then you know the bug is real even if it seems impossible at first.

Mostly reasonable

Posted Mar 23, 2022 21:26 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

I read the text carefully and can't find either a requirement or a request that source code be provided to the tool that found an issue. It says Specifically include details about any testing, static or dynamic analysis programs, and any other tools or methods used to perform the work. There's no mention of source code.

Guidelines for research on the kernel community

Posted Mar 24, 2022 3:06 UTC (Thu) by riking (subscriber, #95706) [Link]

Thanks to the editor for your effort on developing this document.