summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2018-11-19 11:07:18 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-11-20 18:02:45 +0100
commit544b03da39e2d7b4961d3163976ed4bfb1fac509 (patch)
treefb73648550f9605147355cd31fa103afb6d334fe /lib
parentcb5d21946d2a2f4687c482ab4604af1d29dac35a (diff)
downloadlinux-544b03da39e2d7b4961d3163976ed4bfb1fac509.tar.bz2
Documentation/security-bugs: Postpone fix publication in exceptional cases
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>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions