• Will Deacon's avatar
    Documentation/security-bugs: Postpone fix publication in exceptional cases · 544b03da
    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: default avatarKees Cook <keescook@chromium.org>
    Co-developed-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Co-developed-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
    Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    544b03da
security-bugs.rst 3.93 KB