[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230717110631.GH4253@hirez.programming.kicks-ass.net>
Date: Mon, 17 Jul 2023 13:06:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Daniel P. Berrangé <berrange@...hat.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Luca Boccassi <bluca@...ian.org>,
Borislav Petkov <bp@...en8.de>,
Emanuele Giuseppe Esposito <eesposit@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>, lennart@...ttering.net,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Alexander Potapenko <glider@...gle.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
On Mon, Jul 17, 2023 at 10:22:51AM +0100, Daniel P. Berrangé wrote:
> I'm not aware of any kernel CVEs since that point in time that
> would have implied SBAT changes, but admittedly I've not paid
> close enough attention to be entirely confident. Is going back
> through 2 years of kernel CVEs (to the point where SBAT was
> invented) a long enough timeframe to satisfy this request for
> info on the frequency of changes ?
Many *MANY* security bugs never get a CVE. CVE is meaningless when it
comes to kernel bugs. Why does it make sense to review CVEs ?
Powered by blists - more mailing lists