NACK/Cmnt: [PATCH 8/8] x86/bhi: Add support for clearing branch history at syscall entry

[Cengiz Can]

On 19-08-24 11:07:58, Manuel Diewald wrote:
> On Mon, Aug 19, 2024 at 10:48:12AM +0200, Stefan Bader wrote:
> > On 16.08.24 16:11, Manuel Diewald wrote:
> > > On Fri, Aug 16, 2024 at 03:28:08PM +0200, Stefan Bader wrote:
> > > > On 15.08.24 19:43, Manuel Diewald wrote:
> > > > > On Tue, Aug 06, 2024 at 06:50:33PM -0400, Yuxuan Luo wrote:
> > > > > > (cherry picked from commit 7390db8aea0d64e9deb28b8e1ce716f5020c7ee5)
> > > > > 
> > > > > This is technically a backport, not a cherry pick.
> > > > 
> > > > As this was already applied I amended the cherry pick line into a
> > > > backported.
> > > 
> > > Thanks. Did you also have a look at the other changes that I think are
> > > needed?
> > > 
> > 
> > Shoot, no, I had the delusion that was the only issue. So should we revert
> > that last patch for now? Sounds like it would be bad if kept as is...
> 
> The last patch is definitely required for the CVE to be fixed
> effectively but needs to be backported differently. I would suggest to
> revert the entire patchset, to be honest. Reverting the patch leaves the
> branch in a somewhat defunct state with the CVE not fixed but the fix
> commit applied. We would need to track whether a follow-up patch is
> prepared, reviewed and applied in time, and in case it's not, revert the
> other patches before preparing the kernels for the next cycle. I also
> think it makes it a lot easier to review the patch with the context of
> the other patches. Just looking at the individual patch might be tricky,
> especially for someone who might have not reviewed the previous
> submissions. Lastly, I think we will have to prepare another submission
> for the mailing list anyway, review it and apply the patch(es). I think
> the effort to revert and re-submit the entire patchset is hence not
> significantly higher, however, less things can go wrong I feel like.

We will prepare another patchset.

Thanks

> 
> -- 
>  Manuel



> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team