Re: [PATCH] vfio/type1: Cleanup remaining vaddr removal/update fragments

[Alex Williamson <alex.williamson@redhat.com>]

On Fri, 9 Dec 2022 13:40:29 -0500
Steven Sistare <steven.sistare@oracle.com> wrote:

> On 12/8/2022 11:40 AM, Alex Williamson wrote:
> > On Thu, 8 Dec 2022 07:56:30 +0000
> > "Tian, Kevin" <kevin.tian@intel.com> wrote:
> >   
> >>> From: Alex Williamson <alex.williamson@redhat.com>
> >>> Sent: Thursday, December 8, 2022 5:45 AM
> >>>
> >>> Fix several loose ends relative to reverting support for vaddr removal
> >>> and update.  Mark feature and ioctl flags as deprecated, restore local
> >>> variable scope in pin pages, remove remaining support in the mapping
> >>> code.
> >>>
> >>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> >>> ---
> >>>
> >>> This applies on top of Steve's patch[1] to fully remove and deprecate
> >>> this feature in the short term, following the same methodology we used
> >>> for the v1 migration interface removal.  The intention would be to pick
> >>> Steve's patch and this follow-on for v6.2 given that existing support
> >>> exposes vulnerabilities and no known upstream userspaces make use of
> >>> this feature.
> >>>
> >>> [1]https://lore.kernel.org/all/1670363753-249738-2-git-send-email-
> >>> steven.sistare@oracle.com/
> >>>     
> >>
> >> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> >>
> >> btw given the exposure and no known upstream usage should this be
> >> also pushed to stable kernels?  
> > 
> > I'll add to both:
> > 
> > Cc: stable@vger.kernel.org # v5.12+  
> 
> We maintain and use a version of qemu that contains the live update patches,
> and requires these kernel interfaces. Other companies are also experimenting 
> with it.  Please do not remove it from stable.

The interface has been determined to have vulnerabilities and the
proposal to resolve those vulnerabilities is to implement a new API.
If we think it's worthwhile to remove the existing, vulnerable interface
in the current kernel, what makes it safe to keep it for stable kernels?

Existing users that could choose not to accept the revert in their
downstream kernel and allowing users evaluating the interface more time
before they know it's been removed upstream, are not terribly
compelling reasons to keep it in upstream stable kernels.  Thanks,

Alex