요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
설문조사가 권장되지 않는 이유
researcher-guidelines.rst:47-69Maintainer나 contributor에게 email 설문을 보내는 방식은 일반적으로 권장되지 않는다. Kernel 개발은 참여자 모두가 patch, review, 기술 토론에서 서로 이익을 얻는 구조지만, 설문 응답은 바쁜 개발자에게 일방적으로 시간을 요구하면서 kernel community에 직접적인 결과를 돌려주지 못하는 경우가 많다.
Kernel 개발자는 이미 매우 많은 mail을 처리한다. 대량 설문은 유효한 contribution 시간을 소모하면서도 응답률이 낮아 통계적으로 유용한 표본을 얻기 어렵다.
대안은 developer event에 참가해 연구 목적과 참여자가 얻는 이익을 설명하는 session을 열고 직접 대화하는 것이다. 이 방식은 단답형 설문보다 맥락이 풍부한 자료를 얻을 수 있고, community도 연구자의 분석과 통찰을 되돌려 받을 수 있다.
연구 결과로 patch를 보낼 때
researcher-guidelines.rst:71-101Patch 전송은 개발자와의 직접 상호 작용이다. 개발자는 선의의 contribution을 받을 것에는 동의했지만, 일부러 결함이나 취약점을 넣은 patch 또는 토론을 오도하는 정보를 받을 것에는 동의하지 않았다.
고의로 잘못된 patch는 review 시간과 개발자의 의욕을 소모하고, contributor 개인과 소속 조직에 대한 신뢰를 훼손하며, 이후 정상적인 contributor에게 제공할 review 자원까지 약화한다. 결함이 실제 사용자에게 도달하면 software 안전도 직접 위협한다.
반대로 static analysis, dynamic analysis, fuzzing 같은 연구 도구가 재현 가능한 결함을 찾고 검증된 fix를 만들었다면 Linux 개발 참여로 이어지는 것이 바람직하다. 알려진 bug를 하나 더 나열하는 것보다 검토 가능한 patch를 제공하는 편이 훨씬 유용하다.
- 제출 전 development-process.rst와 submitting-patches.rst를 읽는다.
- 일반 bug는 reporting-issues.rst, security 문제는 security-bugs.rst 절차를 따른다.
- Patch만 보내고 끝내지 말고 review 의견에 답하고 수정판을 계속 관리한다.
연구 patch의 commit message에 들어갈 내용
researcher-guidelines.rst:103-155개발자가 연구 결과의 신뢰도와 fix의 적절성을 판단하려면 commit message만으로 결함의 도달 경로, 영향, 발견 방법과 검증 범위를 재구성할 수 있어야 한다.
- 발견한 문제가 정확히 무엇인지 기술한다.
- 실행 중인 system에서 어떤 입력과 상태를 거쳐 해당 code path에 도달하는지 설명한다.
- 문제가 발생했을 때 crash, leak, corruption, privilege change 등 어떤 영향이 생기는지 적는다.
- 사용한 test, static·dynamic analysis program, 도구와 방법을 구체적으로 밝힌다.
- 문제를 발견한 Linux version을 적는다. 최신 release 또는 최근 linux-next를 사용하는 것이 강하게 권장된다.
- 무엇을 바꿨고 그 변경이 옳다고 판단한 이유를 설명한다.
- Build test와 runtime test의 architecture, configuration, compiler와 결과를 적는다.
- 원인을 도입한 commit을 확인해 Fixes: tag로 남긴다.
- 사전 review를 받았다면 실제 reviewer의 Reviewed-by: tag를 포함한다.
원문의 예시는 probe 실패 경로에서 64-byte slab object를 해제하지 않는 driver bug를 다룬다. 어떤 device 응답에서 leak이 생기는지, 자체 static analyzer가 어느 release의 어느 줄을 지적했는지, fix 뒤 어느 architecture를 build했고 runtime test는 장비가 없어 수행하지 못했다는 한계까지 적는다. 확인하지 않은 검증을 했다고 쓰지 않는 점도 중요한 보고 원칙이다.
첫 기여자의 사전 검토와 문의 창구
researcher-guidelines.rst:156-170첫 contribution이라면 public mailing list에 게시하기 전에 Linux contribution 경험이 있는 사람에게 비공개 검토를 받는 것이 권장된다. 이미 내부 review를 강화하라는 요청을 받은 조직이나 연구자에게는 이 단계가 필수다.
검토자는 결과 patch에 Reviewed-by tag로 표시한다. 특히 같은 조직 안에서 kernel contribution 경험자를 찾아 commit message, scope, test와 coding style을 점검하면 public reviewer의 부담을 크게 줄일 수 있다.
내부 reviewer를 찾기 어렵거나 이 지침의 기대 수준을 확인해야 한다면 Linux Foundation Technical Advisory Board의 비공개 mailing list인 [email protected]에 문의할 수 있다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
.. _researcher_guidelines:
Researcher Guidelines
+++++++++++++++++++++
The Linux kernel community welcomes transparent research on the Linux
kernel, the activities involved in producing it, and any other byproducts
of its development. Linux benefits greatly from this kind of research, and
most aspects of Linux are driven by research in one form or another.
The community greatly appreciates if researchers can share preliminary
findings before making their results public, especially if such research
involves security. Getting involved early helps both improve the quality
of research and ability for Linux to improve from it. In any case,
sharing open access copies of the published research with the community
is recommended.
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. For more background on research ethics
generally, ethics in technology, and research of developer communities
in particular, see:
* `History of Research Ethics <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
* `IEEE Ethics <https://www.ieee.org/about/ethics/index.html>`_
* `Developer and Researcher Views on the Ethics of Experiments on Open-Source Projects <https://arxiv.org/pdf/2112.13217.pdf>`_
The Linux kernel community expects that everyone interacting with the
project is participating in good faith to make Linux better. Research on
any publicly-available artifact (including, but not limited to source
code) produced by the Linux kernel community is welcome, though research
on developers must be distinctly opt-in.
Passive research that is based entirely on publicly available sources,
including posts to public mailing lists and commits to public
repositories, is clearly permissible. Though, as with any research,
standard ethics must still be followed.
Active research on developer behavior, however, must be done with the
explicit agreement of, and full disclosure to, the individual developers
involved. Developers cannot be interacted with/experimented on without
consent; this, too, is standard research ethics.
Surveys
=======
Research often takes the form of surveys sent to maintainers or
contributors. As a general rule, though, the kernel community derives
little value from these surveys. The kernel development process works
because every developer benefits from their participation, even working
with others who have different goals. Responding to a survey, though, is a
one-way demand placed on busy developers with no corresponding benefit to
themselves or to the kernel community as a whole. For this reason, this
method of research is discouraged.
Kernel community members already receive far too much email and are likely
to perceive survey requests as just another demand on their time. Sending
such requests deprives the community of valuable contributor time and is
unlikely to yield a statistically useful response.
As an alternative, researchers should consider attending developer events,
hosting sessions where the research project and its benefits to the
participants can be explained, and interacting directly with the community
there. The information received will be far richer than that obtained from
an email survey, and the community will gain from the ability to learn from
your insights as well.
Patches
=======
To help clarify: sending patches to developers *is* interacting
with them, but they have already consented to receiving *good faith
contributions*. Sending intentionally flawed/vulnerable patches or
contributing misleading information to discussions is not consented
to. Such communication can be damaging to the developer (e.g. draining
time, effort, and morale) and damaging to the project by eroding
the entire developer community's trust in the contributor (and the
contributor's organization as a whole), undermining efforts to provide
constructive feedback to contributors, and putting end users at risk of
software flaws.
Participation in the development of Linux itself by researchers, as
with anyone, is welcomed and encouraged. Research into Linux code is
a common practice, especially when it comes to developing or running
analysis tools that produce actionable results.
When engaging with the developer community, sending a patch has
traditionally been the best way to make an impact. Linux already has
plenty of known bugs -- what's much more helpful is having vetted fixes.
Before contributing, carefully read the appropriate documentation:
* Documentation/process/development-process.rst
* Documentation/process/submitting-patches.rst
* Documentation/admin-guide/reporting-issues.rst
* Documentation/process/security-bugs.rst
Then send a patch (including a commit log with all the details listed
below) and follow up on any feedback from other developers.
When sending patches produced from research, the commit logs should
contain at least the following details, so that developers have
appropriate context for understanding the contribution. Answer:
* What is the specific problem that has been found?
* How could the problem be reached on a running system?
* What effect would encountering the problem have on the system?
* How was the problem found? Specifically include details about any
testing, static or dynamic analysis programs, and any other tools or
methods used to perform the work.
* Which version of Linux was the problem found on? Using the most recent
release or a recent linux-next branch is strongly preferred (see
Documentation/process/howto.rst).
* What was changed to fix the problem, and why it is believed to be correct?
* How was the change build tested and run-time tested?
* What prior commit does this change fix? This should go in a "Fixes:"
tag as the documentation describes.
* Who else has reviewed this patch? This should go in appropriate
"Reviewed-by:" tags; see below.
For example::
From: Author <author@email>
Subject: [PATCH] drivers/foo_bar: Add missing kfree()
The error path in foo_bar driver does not correctly free the allocated
struct foo_bar_info. This can happen if the attached foo_bar device
rejects the initialization packets sent during foo_bar_probe(). This
would result in a 64 byte slab memory leak once per device attach,
wasting memory resources over time.
This flaw was found using an experimental static analysis tool we are
developing, LeakMagic[1], which reported the following warning when
analyzing the v5.15 kernel release:
path/to/foo_bar.c:187: missing kfree() call?
Add the missing kfree() to the error path. No other references to
this memory exist outside the probe function, so this is the only
place it can be freed.
x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
11.2 show no new warnings, and LeakMagic no longer warns about this
code path. As we don't have a FooBar device to test with, no runtime
testing was able to be performed.
[1] https://url/to/leakmagic/details
Reported-by: Researcher <researcher@email>
Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
Signed-off-by: Author <author@email>
Reviewed-by: Reviewer <reviewer@email>
If you are a first time contributor it is recommended that the patch
itself be vetted by others privately before being posted to public lists.
(This is required if you have been explicitly told your patches need
more careful internal review.) These people are expected to have their
"Reviewed-by" tag included in the resulting patch. Finding another
developer familiar with Linux contribution, especially within your own
organization, and having them help with reviews before sending them to
the public mailing lists tends to significantly improve the quality of the
resulting patches, and there by reduces the burden on other developers.
If no one can be found to internally review patches and you need
help finding such a person, or if you have any other questions
related to this document and the developer community's expectations,
please reach out to the private Technical Advisory Board mailing list:
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Kernel 연구와 기본 윤리
1-40Linux kernel community는 Linux kernel, kernel을 만드는 활동, 개발 과정에서 생기는 그 밖의 결과물을 투명하게 연구하는 일을 환영한다. Linux의 많은 부분이 다양한 형태의 연구에서 큰 도움을 받고 있다.
특히 보안과 관련된 연구라면 결과를 공개하기 전에 예비 발견 내용을 community와 공유하는 것이 좋다. 일찍 협력하면 연구의 품질을 높이고 Linux가 연구 결과를 바탕으로 개선될 가능성도 커진다. 출판된 연구는 open-access 사본을 community와 공유하기를 권한다.
이 문서는 kernel community가 받아들일 수 있는 연구 방식과 받아들일 수 없는 방식을 명확히 한다. 최소한 일반적인 연구 윤리 규칙을 따라야 한다.
- 연구 윤리의 역사
https://www.unlv.edu/research/ORI-HSR/history-ethics - IEEE Ethics
https://www.ieee.org/about/ethics/index.html - Open-source project 실험 윤리에 대한 developer와 researcher의 관점
https://arxiv.org/pdf/2112.13217.pdf
Community는 project와 상호작용하는 모든 사람이 Linux를 개선하려는 선의로 참여한다고 기대한다. Source code를 포함해 공개된 결과물을 연구하는 것은 환영하지만 developer 개인을 대상으로 하는 연구는 명확한 opt-in 방식이어야 한다. 공개 mailing list 게시물과 public repository commit처럼 공개 자료만 이용하는 수동적 연구는 허용되지만 일반 연구 윤리는 여전히 적용된다.
Developer를 대상으로 하는 능동적 연구
42-45Developer 행동에 관한 능동적 연구는 관련 developer 개인의 명시적인 동의를 받고 연구 내용을 완전히 공개한 상태에서만 수행해야 한다. 동의 없이 developer와 상호작용하거나 developer를 실험 대상으로 삼아서는 안 된다.
Email survey를 권장하지 않는 이유
47-69연구자가 maintainer나 contributor에게 survey를 보내는 경우가 많지만 kernel community는 일반적으로 이런 survey에서 얻는 가치가 작다고 본다. Kernel 개발 절차에서는 목표가 다른 사람과 협력하더라도 참여자 모두가 참여로부터 이익을 얻는다. 반면 survey 응답은 바쁜 developer에게 일방적으로 시간을 요구하면서 developer 자신이나 전체 community에 대응하는 이익을 주지 못한다.
Kernel community 구성원은 이미 지나치게 많은 email을 받으므로 survey 요청을 또 하나의 시간 요구로 인식할 가능성이 높다. 이런 요청은 가치 있는 contributor 시간을 빼앗고 통계적으로 유용한 응답도 얻기 어렵다.
대안으로 developer event에 참석해 연구 project와 참여자가 얻을 이익을 설명하는 session을 열고 community와 직접 대화하는 방법을 고려한다. Email survey보다 훨씬 풍부한 정보를 얻을 수 있고 community도 연구자의 통찰을 함께 배울 수 있다.
연구에서 나온 patch도 선의의 기여여야 한다
71-101Developer에게 patch를 보내는 행위도 분명한 상호작용이다. Developer가 동의한 것은 선의의 기여를 받는 일이지 의도적으로 결함이나 취약점을 넣은 patch 또는 토론을 오도하는 정보를 받는 일이 아니다.
그런 communication은 developer의 시간, 노력, 사기를 소모하고 contributor와 그 소속 조직에 대한 전체 community의 신뢰를 무너뜨린다. Contributor에게 건설적인 feedback을 제공하려는 노력도 약화시키며 end user를 software defect 위험에 빠뜨릴 수 있다.
다른 누구와 마찬가지로 researcher가 Linux 개발에 직접 참여하는 것은 환영하고 권장한다. 실행 가능한 결과를 만드는 static 또는 dynamic analysis tool을 개발하고 실행하는 연구도 흔하다. 이미 알려진 bug는 많으므로 단순한 bug 보고보다 검토된 fix를 제공하는 것이 훨씬 유용하다.
- Documentation/process/development-process.rst
- Documentation/process/submitting-patches.rst
- Documentation/admin-guide/reporting-issues.rst
- Documentation/process/security-bugs.rst
기여 전에 이 문서를 세심하게 읽고, 아래 세부 사항을 담은 commit log와 함께 patch를 보낸 뒤 다른 developer의 feedback에 대응한다.
연구 patch의 commit log에 답할 질문
103-121- 발견한 구체적인 문제는 무엇인가?
- Running system에서 어떤 경로로 문제에 도달할 수 있는가?
- 문제가 발생하면 system에 어떤 영향이 생기는가?
- 문제를 어떻게 찾았는가? 사용한 test, static/dynamic analysis program, 도구와 방법을 구체적으로 적는다.
- 어떤 Linux version에서 발견했는가? 최신 release 또는 최근 linux-next branch 사용을 강하게 권장한다.
- 문제를 고치기 위해 무엇을 바꾸었고 왜 그 변경이 올바르다고 판단하는가?
- 변경을 어떤 방식으로 build test와 runtime test했는가?
- 어느 이전 commit의 문제를 고치는가? 문서에 설명된 Fixes: tag에 기록한다.
- 누가 patch를 검토했는가? 적절한 Reviewed-by: tag에 기록한다.
연구 결과 patch의 commit log 예
123-154From: Author <author@email>
Subject: [PATCH] drivers/foo_bar: Add missing kfree()
The error path in foo_bar driver does not correctly free the allocated
struct foo_bar_info. This can happen if the attached foo_bar device
rejects the initialization packets sent during foo_bar_probe(). This
would result in a 64 byte slab memory leak once per device attach,
wasting memory resources over time.
This flaw was found using an experimental static analysis tool we are
developing, LeakMagic[1], which reported the following warning when
analyzing the v5.15 kernel release:
path/to/foo_bar.c:187: missing kfree() call?
Add the missing kfree() to the error path. No other references to this
memory exist outside the probe function, so this is the only place it
can be freed.
x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC 11.2
show no new warnings, and LeakMagic no longer warns about this code path.
As we don't have a FooBar device to test with, no runtime testing was
able to be performed.
[1] https://url/to/leakmagic/details
Reported-by: Researcher <researcher@email>
Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
Signed-off-by: Author <author@email>
Reviewed-by: Reviewer <reviewer@email>예시는 foo_bar_probe()의 error path에서 struct foo_bar_info를 해제하지 않아 device attach마다 64 byte slab leak이 생기는 문제를 설명한다. LeakMagic이라는 실험적 static analyzer와 대상 kernel version, warning 위치를 밝히고, kfree() 추가가 올바른 이유와 x86_64·arm64 build 결과, 실제 device가 없어 runtime test하지 못한 제한까지 기록한다. 마지막에 source, Fixes, sign-off, review tag를 제공한다.
공개 제출 전 내부 검토
156-170첫 기여자라면 public mailing list에 게시하기 전에 다른 사람에게 patch를 비공개로 검토받기를 권한다. Patch에 더 세심한 내부 검토가 필요하다는 명시적 통지를 받은 경우에는 필수다. 검토자는 결과 patch에 Reviewed-by tag를 남겨야 한다.
특히 같은 조직 안에서 Linux contribution 경험이 있는 developer를 찾아 공개 제출 전에 review 도움을 받으면 patch 품질이 크게 좋아지고 다른 developer의 부담도 줄어든다.
내부에서 patch를 검토할 사람을 찾을 수 없거나 이 문서와 community 기대 사항에 관한 다른 질문이 있다면 private Technical Advisory Board mailing list인 [email protected]에 연락한다.
연구를 환영하는 범위와 기본 원칙
researcher-guidelines.rst:5-35Linux kernel community는 kernel 자체뿐 아니라 kernel을 만드는 활동과 그 과정에서 생기는 자료를 대상으로 한 투명한 연구를 환영한다. Linux의 설계와 개발 방식 상당 부분이 연구 결과의 영향을 받아 왔기 때문이다.
특히 security와 관계된 연구라면 결과를 공개하기 전에 예비 결과를 community와 공유하는 편이 좋다. 이른 단계에서 협력하면 연구자는 기술적 오해와 재현 조건을 교정할 수 있고, kernel 측은 실제 개선으로 연결할 시간을 확보할 수 있다. 출판 뒤에는 누구나 읽을 수 있는 open-access 사본을 제공하는 것이 권장된다.
최소 기준은 일반적인 연구 윤리다. 공개 source code, 공개 mailing list 게시물, 공개 repository commit처럼 누구나 접근할 수 있는 산출물을 분석하는 수동 연구는 허용된다. 반면 개발자 개인의 행동을 관찰하거나 반응을 유도하는 연구는 명백한 opt-in 방식이어야 한다.
공개된 code를 분석할 권한과 사람을 실험 대상으로 삼을 권한은 별개다. 개발자와 직접 상호 작용하면서 행동을 측정하는 연구는 대상자에게 연구 목적과 방법을 충분히 알리고 명시적 동의를 받아야 한다.