요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
암호화된 최초 보고
embargoed-hardware-issues.rst:22-58Hardware security team은 일반 kernel security team과 별개이며 embargo hardware issue의 fix 개발만 다룬다. 순수 Linux software vulnerability는 security-bugs 절차로 보낸다.
최초 연락은 hardware-security@kernel.org로 보낸다. Private officer list이며 mail은 list PGP key 또는 S/MIME certificate로 encrypt하고 reporter key·certificate로 sign해야 한다. Silicon vendor뿐 아니라 flaw를 찾은 researcher와 개인도 직접 보고할 수 있다.
NDA 대신 Memorandum of Understanding
embargoed-hardware-issues.rst:59-112Hardware security team은 formal legal body가 아니므로 NDA를 체결할 수 없다. 대신 여러 OS와 vendor 사이 embargo 필요를 인정하고, 참여 개발자가 confidentiality와 documented process를 지키겠다고 약속하는 Memorandum of Understanding을 제공한다.
Officer가 issue별 domain expert로 initial response team을 만들고 필요하면 추가 expert를 초대한다. Embargo 위반자는 즉시 해당 incident와 list에서 제외되고 future issue에도 참여할 수 없으며 관련 당사자에게 violation 사실을 알린다.
Disclosure 시작과 incident list
embargoed-hardware-issues.rst:114-177Initial mail에는 문제 설명과 알려진 affected silicon 목록을 넣는다. Reporter가 영향 hardware를 만들거나 배포한다면 유사한 다른 product도 검토하고 affected silicon vendor에 제때 알릴 책임이 있다.
Officer는 incident 전용 encrypted list와 처음 참여할 domain expert 명단을 제공한다. Reporter는 이미 알렸거나 알려야 할 조직 contact 목록을 전달해 OS·hardware vendor 사이 communication과 추가 expert 선정을 가능하게 한다.
Developer가 고용주 NDA의 적용을 받을 수는 있지만 Linux developer 역할로 별도 개인 NDA를 맺지는 않는다. 참여 기준은 이 문서의 process와 MOU다.
비공개 patch review와 expert 추가
embargoed-hardware-issues.rst:178-220Mitigation은 일반 kernel workflow와 비슷하게 encrypted mailing list에서 patch를 게시·review하고 합의된 변경을 secure non-public Git repository에 적용한다. Repository에는 mainline development branch와 필요한 stable backport branch를 둔다.
추가 expert는 어느 시점에도 제안할 수 있다. Disclosure list의 조직 소속이면 그 조직을 통해 참여를 요청하고, 그 밖의 expert는 reporter에게 알린다. Reporter가 compelling objection을 제기할 기간은 5 working day이며 응답이 없으면 silent acknowledgment로 본다.
참여자는 private list 밖에서 issue를 논의하거나 고용주 build farm, shared CI 같은 공동 resource를 mitigation 개발에 사용해서는 안 된다. Log, artifact와 job metadata가 embargo를 노출할 수 있기 때문이다.
Silicon vendor response team의 제한된 early access
embargoed-hardware-issues.rst:222-252원칙적으로 response team 밖의 개인과 조직에 patch를 배포할 수 없다. 예외적으로 affected silicon vendor의 designated representative는 vendor 내부 response team에 patch를 넘길 수 있고 kernel response team에 handover를 통지해야 한다.
Vendor는 이 policy와 일치하는 자체 documented security process를 유지하고 그 절차 아래 internal team과 industry partner에 배포할 수 있다. Partner feedback은 vendor를 거쳐 kernel team에 돌아온다. Vendor 영역에서 premature disclosure가 생기면 kernel response team은 그 책임을 지지 않는 조건이다.
동시 공개와 최소 embargo
embargoed-hardware-issues.rst:254-278참여 당사자가 embargo 종료 날짜와 시간을 협의하고 그 시점에 mitigation을 관련 public kernel tree에 동시에 게시한다. 특정 distribution이나 고객에게 먼저 알리는 pre-notification은 없다.
Embargo는 개발·test·배포 logistics에 필요한 최소 기간으로 제한한다. Conference 발표 같은 비기술적 일정을 맞추려고 늘리면 계속 변하는 upstream과 patch를 동기화하는 부담과 conflict 위험이 커진다.
Hardware security team과 response team은 CVE를 배정하지 않고 mitigation 개발에 CVE를 요구하지도 않는다. Reporter가 이미 제공한 CVE는 documentation에 사용할 수 있다.
Encrypted list의 동작과 구독
embargoed-hardware-issues.rst:280-357Organization ambassador는 reporting process를 안내하지만 특정 incident disclosure에는 response team 또는 disclosed party의 요청 없이는 참여하지 않는다.
List software는 list public key로 받은 mail을 decrypt한 뒤 subscriber마다 각자의 PGP key 또는 S/MIME certificate로 다시 encrypt한다. Incident list key는 해당 list가 signed mail로 전달한다.
각 subscriber는 자신의 PGP key 또는 S/MIME certificate로 sign한 request를 response team에 보낸다. PGP key는 public key server에서 확인 가능해야 하고 가능하면 kernel PGP web of trust와 연결한다. Team이 identity와 참여 승인을 검증한 뒤 list에 추가한다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _embargoed_hardware_issues:
Embargoed hardware issues
=========================
Scope
-----
Hardware issues which result in security problems are a different category
of security bugs than pure software bugs which only affect the Linux
kernel.
Hardware issues like Meltdown, Spectre, L1TF etc. must be treated
differently because they usually affect all Operating Systems ("OS") and
therefore need coordination across different OS vendors, distributions,
silicon vendors, hardware integrators, and other parties. For some of the
issues, software mitigations can depend on microcode or firmware updates,
which need further coordination.
.. _Contact:
Contact
-------
The Linux kernel hardware security team is separate from the regular Linux
kernel security team.
The team only handles developing fixes for embargoed hardware security
issues. Reports of pure software security bugs in the Linux kernel are not
handled by this team and the reporter will be guided to contact the regular
Linux kernel security team (:ref:`Documentation/admin-guide/
<securitybugs>`) instead.
The team can be contacted by email at <hardware-security@kernel.org>. This
is a private list of security officers who will help you coordinate a fix
according to our documented process.
The list is encrypted and email to the list can be sent by either PGP or
S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
certificate. The list's PGP key and S/MIME certificate are available from
the following URLs:
- PGP: https://www.kernel.org/static/files/hardware-security.asc
- S/MIME: https://www.kernel.org/static/files/hardware-security.crt
While hardware security issues are often handled by the affected silicon
vendor, we welcome contact from researchers or individuals who have
identified a potential hardware flaw.
Hardware security officers
^^^^^^^^^^^^^^^^^^^^^^^^^^
The current team of hardware security officers:
- Linus Torvalds (Linux Foundation Fellow)
- Greg Kroah-Hartman (Linux Foundation Fellow)
- Thomas Gleixner (Linux Foundation Fellow)
Operation of mailing-lists
^^^^^^^^^^^^^^^^^^^^^^^^^^
The encrypted mailing-lists which are used in our process are hosted on
Linux Foundation's IT infrastructure. By providing this service, members
of Linux Foundation's IT operations personnel technically have the
ability to access the embargoed information, but are obliged to
confidentiality by their employment contract. Linux Foundation IT
personnel are also responsible for operating and managing the rest of
kernel.org's infrastructure.
The Linux Foundation's current director of IT Project infrastructure is
Konstantin Ryabitsev.
Non-disclosure agreements
-------------------------
The Linux kernel hardware security team is not a formal body and therefore
unable to enter into any non-disclosure agreements. The kernel community
is aware of the sensitive nature of such issues and offers a Memorandum of
Understanding instead.
Memorandum of Understanding
---------------------------
The Linux kernel community has a deep understanding of the requirement to
keep hardware security issues under embargo for coordination between
different OS vendors, distributors, silicon vendors, and other parties.
The Linux kernel community has successfully handled hardware security
issues in the past and has the necessary mechanisms in place to allow
community compliant development under embargo restrictions.
The Linux kernel community has a dedicated hardware security team for
initial contact, which oversees the process of handling such issues under
embargo rules.
The hardware security team identifies the developers (domain experts) who
will form the initial response team for a particular issue. The initial
response team can bring in further developers (domain experts) to address
the issue in the best technical way.
All involved developers pledge to adhere to the embargo rules and to keep
the received information confidential. Violation of the pledge will lead to
immediate exclusion from the current issue and removal from all related
mailing lists. In addition, the hardware security team will also exclude
the offender from future issues. The impact of this consequence is a highly
effective deterrent in our community. In case a violation happens the
hardware security team will inform the involved parties immediately. If you
or anyone else becomes aware of a potential violation, please report it
immediately to the Hardware security officers.
Process
^^^^^^^
Due to the globally distributed nature of Linux kernel development,
face-to-face meetings are almost impossible to address hardware security
issues. Phone conferences are hard to coordinate due to time zones and
other factors and should be only used when absolutely necessary. Encrypted
email has been proven to be the most effective and secure communication
method for these types of issues.
Start of Disclosure
"""""""""""""""""""
Disclosure starts by emailing the Linux kernel hardware security team per
the Contact section above. This initial contact should contain a
description of the problem and a list of any known affected silicon. If
your organization builds or distributes the affected hardware, we encourage
you to also consider what other hardware could be affected. The disclosing
party is responsible for contacting the affected silicon vendors in a
timely manner.
The hardware security team will provide an incident-specific encrypted
mailing list which will be used for initial discussion with the reporter,
further disclosure, and coordination of fixes.
The hardware security team will provide the disclosing party a list of
developers (domain experts) who should be informed initially about the
issue after confirming with the developers that they will adhere to this
Memorandum of Understanding and the documented process. These developers
form the initial response team and will be responsible for handling the
issue after initial contact. The hardware security team is supporting the
response team, but is not necessarily involved in the mitigation
development process.
While individual developers might be covered by a non-disclosure agreement
via their employer, they cannot enter individual non-disclosure agreements
in their role as Linux kernel developers. They will, however, agree to
adhere to this documented process and the Memorandum of Understanding.
The disclosing party should provide a list of contacts for all other
entities who have already been, or should be, informed about the issue.
This serves several purposes:
- The list of disclosed entities allows communication across the
industry, e.g. other OS vendors, HW vendors, etc.
- The disclosed entities can be contacted to name experts who should
participate in the mitigation development.
- If an expert who is required to handle an issue is employed by a listed
entity or member of an listed entity, then the response teams can
request the disclosure of that expert from that entity. This ensures
that the expert is also part of the entity's response team.
Disclosure
""""""""""
The disclosing party provides detailed information to the initial response
team via the specific encrypted mailing-list.
From our experience, the technical documentation of these issues is usually
a sufficient starting point, and further technical clarification is best
done via email.
Mitigation development
""""""""""""""""""""""
The initial response team sets up an encrypted mailing-list or repurposes
an existing one if appropriate.
Using a mailing list is close to the normal Linux development process and
has been successfully used to develop mitigations for various hardware
security issues in the past.
The mailing list operates in the same way as normal Linux development.
Patches are posted, discussed, and reviewed and if agreed upon, applied to
a non-public git repository which is only accessible to the participating
developers via a secure connection. The repository contains the main
development branch against the mainline kernel and backport branches for
stable kernel versions as necessary.
The initial response team will identify further experts from the Linux
kernel developer community as needed. Any involved party can suggest
further experts to be included, each of which will be subject to the same
requirements outlined above.
Bringing in experts can happen at any time in the development process and
needs to be handled in a timely manner.
If an expert is employed by or a member of an entity on the disclosure list
provided by the disclosing party, then participation will be requested from
the relevant entity.
If not, then the disclosing party will be informed about the experts'
participation. The experts are covered by the Memorandum of Understanding
and the disclosing party is requested to acknowledge their participation.
In the case where the disclosing party has a compelling reason to object,
any objection must to be raised within five working days and resolved with
the incident team immediately. If the disclosing party does not react
within five working days this is taken as silent acknowledgment.
After the incident team acknowledges or resolves an objection, the expert
is disclosed and brought into the development process.
List participants may not communicate about the issue outside of the
private mailing list. List participants may not use any shared resources
(e.g. employer build farms, CI systems, etc) when working on patches.
Early access
""""""""""""
The patches discussed and developed on the list can neither be distributed
to any individual who is not a member of the response team nor to any other
organization.
To allow the affected silicon vendors to work with their internal teams and
industry partners on testing, validation, and logistics, the following
exception is provided:
Designated representatives of the affected silicon vendors are
allowed to hand over the patches at any time to the silicon
vendor’s response team. The representative must notify the kernel
response team about the handover. The affected silicon vendor must
have and maintain their own documented security process for any
patches shared with their response team that is consistent with
this policy.
The silicon vendor’s response team can distribute these patches to
their industry partners and to their internal teams under the
silicon vendor’s documented security process. Feedback from the
industry partners goes back to the silicon vendor and is
communicated by the silicon vendor to the kernel response team.
The handover to the silicon vendor’s response team removes any
responsibility or liability from the kernel response team regarding
premature disclosure, which happens due to the involvement of the
silicon vendor’s internal teams or industry partners. The silicon
vendor guarantees this release of liability by agreeing to this
process.
Coordinated release
"""""""""""""""""""
The involved parties will negotiate the date and time when the embargo
ends. At that point, the prepared mitigations are published into the
relevant kernel trees. There is no pre-notification process: the
mitigations are published in public and available to everyone at the same
time.
While we understand that hardware security issues need coordinated embargo
time, the embargo time should be constrained to the minimum time that is
required for all involved parties to develop, test, and prepare their
mitigations. Extending embargo time artificially to meet conference talk
dates or other non-technical reasons creates more work and burden for the
involved developers and response teams as the patches need to be kept up to
date in order to follow the ongoing upstream kernel development, which
might create conflicting changes.
CVE assignment
""""""""""""""
Neither the hardware security team nor the initial response team assign
CVEs, nor are CVEs required for the development process. If CVEs are
provided by the disclosing party they can be used for documentation
purposes.
Process ambassadors
-------------------
For assistance with this process we have established ambassadors in various
organizations, who can answer questions about or provide guidance on the
reporting process and further handling. Ambassadors are not involved in the
disclosure of a particular issue, unless requested by a response team or by
an involved disclosed party. The current ambassadors list:
============= ========================================================
AMD Tom Lendacky <thomas.lendacky@amd.com>
Ampere Darren Hart <darren@os.amperecomputing.com>
ARM Catalin Marinas <catalin.marinas@arm.com>
IBM Power Madhavan Srinivasan <maddy@linux.ibm.com>
IBM Z Christian Borntraeger <borntraeger@de.ibm.com>
Intel Tony Luck <tony.luck@intel.com>
Qualcomm Trilok Soni <quic_tsoni@quicinc.com>
RISC-V Palmer Dabbelt <palmer@dabbelt.com>
Samsung Javier González <javier.gonz@samsung.com>
Microsoft James Morris <jamorris@linux.microsoft.com>
Xen Andrew Cooper <andrew.cooper3@citrix.com>
Canonical John Johansen <john.johansen@canonical.com>
Debian Ben Hutchings <ben@decadent.org.uk>
Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
SUSE Jiri Kosina <jkosina@suse.cz>
Google Kees Cook <keescook@chromium.org>
LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
============= ========================================================
If you want your organization to be added to the ambassadors list, please
contact the hardware security team. The nominated ambassador has to
understand and support our process fully and is ideally well-connected in
the Linux kernel community.
Encrypted mailing-lists
-----------------------
We use encrypted mailing lists for communication. The operating principle
of these lists is that email sent to the list is encrypted either with the
list's PGP key or with the list's S/MIME certificate. The mailing list
software decrypts the email and re-encrypts it individually for each
subscriber with the subscriber's PGP key or S/MIME certificate. Details
about the mailing list software and the setup that is used to ensure the
security of the lists and protection of the data can be found here:
https://korg.wiki.kernel.org/userdoc/remail.
List keys
^^^^^^^^^
For initial contact see the :ref:`Contact` section above. For incident
specific mailing lists, the key and S/MIME certificate are conveyed to the
subscribers by email sent from the specific list.
Subscription to incident-specific lists
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Subscription to incident-specific lists is handled by the response teams.
Disclosed parties who want to participate in the communication send a list
of potential experts to the response team so the response team can validate
subscription requests.
Each subscriber needs to send a subscription request to the response team
by email. The email must be signed with the subscriber's PGP key or S/MIME
certificate. If a PGP key is used, it must be available from a public key
server and is ideally connected to the Linux kernel's PGP web of trust. See
also: https://www.kernel.org/signature.html.
The response team verifies that the subscriber request is valid and adds
the subscriber to the list. After subscription the subscriber will receive
email from the mailing-list which is signed either with the list's PGP key
or the list's S/MIME certificate. The subscriber's email client can extract
the PGP key or the S/MIME certificate from the signature so the subscriber
can send encrypted email to the list.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Embargo가 필요한 hardware security issue
1-18Security 문제를 일으키는 hardware issue는 Linux kernel에만 영향을 주는 순수 software bug와 다른 종류의 security bug다.
Meltdown, Spectre, L1TF 같은 hardware issue는 대개 모든 operating system에 영향을 준다. 따라서 OS vendor, distribution, silicon vendor, hardware integrator와 다른 관련자 사이의 coordination이 필요하므로 별도로 다뤄야 한다. 일부 issue의 software mitigation은 microcode 또는 firmware update에 의존하므로 추가 coordination도 필요하다.
Hardware security team 연락 방법
20-48Linux kernel hardware security team은 일반 Linux kernel security team과 별도 조직이다. 이 team은 embargo된 hardware security issue의 fix 개발만 처리한다. Linux kernel의 순수 software security bug는 처리하지 않으며 reporter에게 Documentation/admin-guide/security-bugs.rst의 일반 security team으로 연락하도록 안내한다.
연락 주소는 <hardware-security@kernel.org>이다. 문서화된 절차에 따라 fix coordination을 돕는 security officer의 비공개 list다.
List는 암호화되어 있다. PGP 또는 S/MIME으로 암호화한 email을 보낼 수 있으며 reporter의 PGP key 또는 S/MIME certificate로 반드시 서명해야 한다.
- Hardware security list PGP key
https://www.kernel.org/static/files/hardware-security.asc - Hardware security list S/MIME certificate
https://www.kernel.org/static/files/hardware-security.crt
Hardware security issue는 affected silicon vendor가 처리하는 경우가 많지만, 잠재적 hardware flaw를 발견한 researcher 또는 개인의 연락도 환영한다.
Hardware security officer와 mailing list 운영
50-71Linux v6.18.37 원문에 기록된 hardware security officer는 다음과 같다.
- Linus Torvalds, Linux Foundation Fellow
- Greg Kroah-Hartman, Linux Foundation Fellow
- Thomas Gleixner, Linux Foundation Fellow
이 절차에서 쓰는 encrypted mailing list는 Linux Foundation IT infrastructure에서 host한다. Service 제공의 특성상 Linux Foundation IT operation personnel은 기술적으로 embargo information에 접근할 수 있지만 고용 계약에 따라 confidentiality 의무를 진다. 이 personnel은 kernel.org의 나머지 infrastructure 운영과 관리도 담당한다.
원문 작성 시점의 Linux Foundation IT Project infrastructure director는 Konstantin Ryabitsev다.
NDA 대신 사용하는 Memorandum of Understanding
74-111Linux kernel hardware security team은 공식 법인이 아니므로 non-disclosure agreement에 서명할 수 없다. Kernel community는 이런 issue의 민감성을 이해하며 대신 Memorandum of Understanding(MoU)을 제공한다.
Community는 여러 OS vendor, distributor, silicon vendor와 다른 관련자 사이의 coordination을 위해 hardware security issue를 embargo 상태로 유지해야 한다는 요구를 깊이 이해한다. 과거에도 hardware security issue를 성공적으로 처리했으며 embargo 제한 아래에서도 community 방식에 맞게 개발할 mechanism을 갖추고 있다.
초기 연락은 전담 hardware security team이 받고 embargo rule에 따라 issue를 처리하는 절차를 감독한다. Team은 특정 issue의 initial response team을 구성할 developer, 즉 domain expert를 식별한다. Initial response team은 최선의 기술적 해결을 위해 다른 domain expert를 추가할 수 있다.
모든 참여 개발자는 embargo rule 준수와 수신 정보의 confidentiality 유지를 약속한다. 이를 위반하면 현재 issue에서 즉시 제외되고 관련 mailing list에서도 제거된다. Hardware security team은 이후 issue에서도 위반자를 배제한다. Community에서 이 결과는 강력한 억제 수단으로 작동한다.
위반이 발생하면 hardware security team은 관련자에게 즉시 알린다. 잠재적 위반을 알게 된 사람은 누구든 hardware security officer에게 즉시 신고해야 한다.
Disclosure 시작과 initial response team 구성
114-166Linux kernel 개발은 전 세계에 분산되어 있어 hardware security issue를 다루기 위한 대면 회의는 거의 불가능하다. Conference call도 시간대와 다른 요인 때문에 조정하기 어려우므로 꼭 필요할 때만 사용해야 한다. 이런 issue에는 encrypted email이 가장 효과적이고 안전한 communication 수단임이 입증되었다.
Disclosure는 위 contact 절에 따라 hardware security team에 email을 보내면서 시작한다. 초기 연락에는 문제 설명과 영향을 받는 것으로 알려진 silicon 목록이 있어야 한다. 조직이 해당 hardware를 제작하거나 배포한다면 영향을 받을 수 있는 다른 hardware도 검토하는 것이 좋다. Affected silicon vendor에 제때 연락할 책임은 disclosing party에 있다.
Hardware security team은 reporter와의 초기 논의, 추가 disclosure, fix coordination에 사용할 incident-specific encrypted mailing list를 제공한다.
Team은 developer가 MoU와 문서화된 절차를 따르겠다고 확인한 뒤, issue를 처음 알려야 할 domain expert 목록을 disclosing party에 제공한다. 이들이 initial response team을 이루어 초기 연락 뒤 issue 처리를 맡는다. Hardware security team은 response team을 지원하지만 mitigation 개발에 반드시 직접 참여하는 것은 아니다.
개별 developer가 고용주를 통해 NDA의 적용을 받을 수는 있지만 Linux kernel developer 역할로 개인 NDA를 체결할 수는 없다. 대신 문서화된 절차와 MoU를 준수하는 데 동의한다.
Disclosing party는 이미 issue를 통보받았거나 통보받아야 하는 모든 entity의 contact list를 제공해야 한다.
- 공개된 entity 목록을 통해 다른 OS vendor와 hardware vendor 등 industry 전반이 communication할 수 있다.
- 각 entity에 연락하여 mitigation 개발에 참여해야 할 expert를 지명받을 수 있다.
- Issue 처리에 필요한 expert가 목록의 entity에 고용되었거나 그 구성원이라면 response team은 해당 entity에 그 expert의 disclosure를 요청할 수 있다. Expert가 entity의 response team에도 속하도록 보장하기 위해서다.
상세 정보 disclosure
168-176Disclosing party는 issue 전용 encrypted mailing list를 통해 initial response team에 상세 정보를 제공한다. 경험상 issue의 technical documentation이면 시작점으로 충분한 경우가 많고 추가 technical clarification은 email로 하는 것이 가장 좋다.
Mitigation 개발과 expert 추가
178-220Initial response team은 encrypted mailing list를 새로 만들거나 적합한 기존 list를 전용한다. Mailing list 방식은 일반 Linux 개발 절차와 비슷하며 과거 여러 hardware security issue의 mitigation 개발에 성공적으로 사용되었다.
List는 일반 Linux 개발과 같은 방식으로 운영한다. Patch를 게시하고 토론하고 review한다. 합의된 patch는 참여 개발자만 secure connection으로 접근할 수 있는 non-public git repository에 적용한다. Repository에는 mainline kernel을 대상으로 하는 main development branch와 필요에 따라 stable kernel version용 backport branch를 둔다.
Initial response team은 필요할 때 Linux kernel developer community에서 expert를 더 찾는다. 관련자 누구나 추가할 expert를 제안할 수 있고 새 expert도 앞에서 정한 동일한 요구 사항을 따라야 한다. Expert는 개발 절차의 어느 시점에든 추가할 수 있으며 지체 없이 처리해야 한다.
Expert가 disclosing party가 제공한 disclosure list의 entity에 고용되었거나 그 구성원이라면 해당 entity에 참여를 요청한다. 그렇지 않으면 disclosing party에 expert 참여를 알린다. Expert는 MoU의 적용을 받고 disclosing party에는 참여 승인을 요청한다.
Disclosing party가 반대할 불가피한 이유가 있다면 5 working day 안에 이의를 제기하고 incident team과 즉시 해결해야 한다. 5 working day 안에 반응하지 않으면 묵시적 승인으로 본다. Incident team이 이의를 승인하거나 해결한 뒤 expert에게 정보를 공개하고 개발 절차에 참여시킨다.
List participant는 private mailing list 밖에서 issue에 관해 communication해서는 안 된다. Patch 작업에 employer build farm이나 CI system 같은 공유 resource도 사용해서는 안 된다.
Early access 예외와 silicon vendor의 책임
222-252List에서 논의하고 개발한 patch는 response team 구성원이 아닌 개인이나 다른 조직에 배포할 수 없다. 다만 affected silicon vendor가 내부 team 및 industry partner와 test, validation, logistics를 진행할 수 있도록 다음 예외를 둔다.
- Affected silicon vendor의 지정 representative는 언제든 patch를 vendor response team에 전달할 수 있다. Representative는 전달 사실을 kernel response team에 알려야 한다. Silicon vendor는 이 policy와 일치하는 자체 문서화된 security process를 갖추고 유지해야 한다.
- Silicon vendor response team은 자체 security process 아래에서 patch를 industry partner와 내부 team에 배포할 수 있다. Industry partner의 feedback은 silicon vendor로 돌아가고 vendor가 kernel response team에 전달한다.
- Vendor response team에 patch를 전달한 뒤 vendor 내부 team이나 industry partner 때문에 premature disclosure가 발생하면 kernel response team은 관련 책임과 liability를 지지 않는다. Silicon vendor는 이 절차에 동의함으로써 해당 면책을 보장한다.
Coordinated release와 CVE
254-278관련자들은 embargo 종료 날짜와 시간을 협의한다. 그 시점에 준비된 mitigation을 관련 kernel tree에 게시한다. 사전 통보 절차는 없으며 public에 게시되는 순간 모든 사람이 동시에 접근할 수 있다.
Hardware security issue에는 coordinated embargo 기간이 필요하지만 모든 관련자가 mitigation을 개발·시험·준비하는 데 필요한 최소 시간으로 제한해야 한다. Conference 발표 날짜나 다른 비기술적 이유에 맞추려고 embargo를 인위적으로 연장하면 개발자와 response team의 부담이 커진다. 계속되는 upstream kernel 개발을 따라 patch를 갱신해야 하고 conflicting change가 생길 수 있기 때문이다.
Hardware security team과 initial response team은 CVE를 배정하지 않으며 개발 절차에 CVE가 필수도 아니다. Disclosing party가 CVE를 제공하면 documentation 목적으로 사용할 수 있다.
Process ambassador
280-317여러 조직에 reporting과 후속 처리 절차를 설명하고 질문에 답하는 ambassador를 두고 있다. Response team 또는 disclosure된 관련자가 요청하지 않는 한 ambassador가 특정 issue의 disclosure에 참여하지는 않는다. Linux v6.18.37 원문에 기록된 목록은 다음과 같다.
| 조직 | Ambassador |
|---|---|
| AMD | Tom Lendacky <thomas.lendacky@amd.com> |
| Ampere | Darren Hart <darren@os.amperecomputing.com> |
| ARM | Catalin Marinas <catalin.marinas@arm.com> |
| IBM Power | Madhavan Srinivasan <maddy@linux.ibm.com> |
| IBM Z | Christian Borntraeger <borntraeger@de.ibm.com> |
| Intel | Tony Luck <tony.luck@intel.com> |
| Qualcomm | Trilok Soni <quic_tsoni@quicinc.com> |
| RISC-V | Palmer Dabbelt <palmer@dabbelt.com> |
| Samsung | Javier González <javier.gonz@samsung.com> |
| Microsoft | James Morris <jamorris@linux.microsoft.com> |
| Xen | Andrew Cooper <andrew.cooper3@citrix.com> |
| Canonical | John Johansen <john.johansen@canonical.com> |
| Debian | Ben Hutchings <ben@decadent.org.uk> |
| Oracle | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
| Red Hat | Josh Poimboeuf <jpoimboe@redhat.com> |
| SUSE | Jiri Kosina <jkosina@suse.cz> |
| Kees Cook <keescook@chromium.org> | |
| LLVM | Nick Desaulniers <nick.desaulniers+lkml@gmail.com> |
조직을 목록에 추가하려면 hardware security team에 연락한다. 지명된 ambassador는 이 절차를 완전히 이해하고 지지해야 하며 Linux kernel community와 폭넓게 연결되어 있는 사람이 이상적이다.
Encrypted mailing list의 동작과 subscription
319-357Communication에는 encrypted mailing list를 사용한다. List로 보내는 email은 list PGP key 또는 S/MIME certificate로 암호화한다. Mailing list software가 email을 decrypt한 뒤 각 subscriber의 PGP key 또는 S/MIME certificate로 개별 re-encrypt한다.
Initial contact용 key는 앞의 Contact 절에서 확인한다. Incident-specific list의 key와 S/MIME certificate는 해당 list가 subscriber에게 보내는 email로 전달한다.
Incident-specific list subscription은 response team이 처리한다. Communication에 참여하려는 disclosed party는 potential expert 목록을 response team에 보내 subscription request를 검증할 수 있게 한다.
각 subscriber는 response team에 email로 subscription을 요청해야 한다. Email은 subscriber의 PGP key 또는 S/MIME certificate로 서명해야 한다. PGP key를 쓴다면 public key server에서 검색할 수 있어야 하며 가능하면 Linux kernel PGP web of trust에 연결되어 있어야 한다.
Response team은 요청의 유효성을 확인하고 subscriber를 list에 추가한다. Subscription 뒤 subscriber는 list PGP key 또는 S/MIME certificate로 서명된 email을 받는다. Email client는 signature에서 key 또는 certificate를 추출하여 이후 list에 encrypted email을 보낼 수 있다.
Software bug와 다른 hardware 취약점
embargoed-hardware-issues.rst:3-18Meltdown, Spectre, L1TF 같은 hardware issue는 Linux code만의 bug가 아니다. 여러 OS vendor, distribution, silicon vendor와 hardware integrator가 동시에 영향을 받고 software mitigation이 microcode·firmware update에 의존할 수 있어 별도 coordination이 필요하다.