- Oct 30, 2023
-
-
commit 3c1897ae upstream. The kernel security team does NOT assign CVEs, so document that properly and provide the "if you want one, ask MITRE for it" response that we give on a weekly basis in the document, so we don't have to constantly say it to everyone who asks. Link: https://lore.kernel.org/r/2023063022-retouch-kerosene-7e4a@gregkh Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
commit 4fee0915 upstream. Because the linux-distros group forces reporters to release information about reported bugs, and they impose arbitrary deadlines in having those bugs fixed despite not actually being kernel developers, the kernel security team recommends not interacting with them at all as this just causes confusion and the early-release of reported security problems. Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/2023063020-throat-pantyhose-f110@gregkh Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Nov 20, 2018
-
-
Will Deacon authored
At the request of the reporter, the Linux kernel security team offers to postpone the publishing of a fix for up to 5 business days from the date of a report. While it is generally undesirable to keep a fix private after it has been developed, this short window is intended to allow distributions to package the fix into their kernel builds and permits early inclusion of the security team in the case of a co-ordinated disclosure with other parties. Unfortunately, discussions with major Linux distributions and cloud providers has revealed that 5 business days is not sufficient to achieve either of these two goals. As an example, cloud providers need to roll out KVM security fixes to a global fleet of hosts with sufficient early ramp-up and monitoring. An end-to-end timeline of less than two weeks dramatically cuts into the amount of early validation and increases the chance of guest-visible regressions. The consequence of this timeline mismatch is that security issues are commonly fixed without the involvement of the Linux kernel security team and are instead analysed and addressed by an ad-hoc group of developers across companies contributing to Linux. In some cases, mainline (and therefore the official stable kernels) can be left to languish for extended periods of time. This undermines the Linux kernel security process and puts upstream developers in a difficult position should they find themselves involved with an undisclosed security problem that they are unable to report due to restrictions from their employer. To accommodate the needs of these users of the Linux kernel and encourage them to engage with the Linux security team when security issues are first uncovered, extend the maximum period for which fixes may be delayed to 7 calendar days, or 14 calendar days in exceptional cases, where the logistics of QA and large scale rollouts specifically need to be accommodated. This brings parity with the linux-distros@ maximum embargo period of 14 calendar days. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Amit Shah <aams@amazon.com> Cc: Laura Abbott <labbott@redhat.com> Acked-by:
Kees Cook <keescook@chromium.org> Co-developed-by:
Thomas Gleixner <tglx@linutronix.de> Co-developed-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Will Deacon <will.deacon@arm.com> Reviewed-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
Whilst making an unrelated change to some Documentation, Linus sayeth: | Afaik, even in Britain, "whilst" is unusual and considered more | formal, and "while" is the common word. | | [...] | | Can we just admit that we work with computers, and we don't need to | use þe eald Englisc spelling of words that most of the world never | uses? dictionary.com refers to the word as "Chiefly British", which is probably an undesirable attribute for technical documentation. Replace all occurrences under Documentation/ with "while". Cc: David Howells <dhowells@redhat.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michael Halcrow <mhalcrow@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Oct 23, 2018
-
-
Will Deacon authored
The Linux kernel security team has been accused of rejecting the idea of security embargoes. This is incorrect, and could dissuade people from reporting security issues to us under the false assumption that the issue would leak prematurely. Clarify the handling of embargoed information in our process documentation. Co-developed-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Mar 09, 2018
-
-
Dave Hansen authored
I think we need to soften the language a bit. It might scare folks off, especially the: We prefer to fully disclose the bug as soon as possible. which is not really the case. Linus says: It's not full disclosure, it's not coordinated disclosure, and it's not "no disclosure". It's more like just "timely open fixes". I changed a bit of the wording in here, but mostly to remove the word "disclosure" since it seems to mean very specific things to people that we do not mean here. Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Mar 07, 2017
-
-
Kees Cook authored
The kernel security team is regularly asked to provide CVE identifiers, which we don't normally do. This updates the documentation to mention this and adds some more details about coordination and patch handling that come up regularly. Based on an earlier draft by Willy Tarreau. Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Oct 24, 2016
-
-
Mauro Carvalho Chehab authored
The previous patch renamed several files that are cross-referenced along the Kernel documentation. Adjust the links to point to the right places. Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Place README, REPORTING-BUGS, SecurityBugs and kernel-parameters on an user's manual book. As we'll be numbering the user's manual, remove the manual numbering from SecurityBugs. Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
- Sep 21, 2016
-
-
Mauro Carvalho Chehab authored
Add cross references for the documents mentioned at HOWTO and are under the Documentation/ directory, using the ReST notation. It should be noticed that HOWTO also mentions the /README file. We opted to not touch it, for now, as making it build on Sphinx would require it to be moved to a Documentation/foo directory. Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
Mauro Carvalho Chehab authored
Add a name for the document and convert the sections to ReST markups. Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Mar 31, 2011
-
-
Lucas De Marchi authored
Fixes generated by 'codespell' and manually reviewed. Signed-off-by:
Lucas De Marchi <lucas.demarchi@profusion.mobi>
-
- Apr 16, 2005
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-