[Ksummit-discuss] [CORE TOPIC] stable workflow

[Olof Johansson]

On Sun, Jul 10, 2016 at 7:42 AM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Sat, Jul 09, 2016 at 11:19:39PM -0700, Olof Johansson wrote:
> >
> > The in-house developers on a certain subsystem didn't trust the
> > upstream maintainers to not regress their drivers -- in particular
> > they had seen some painful regressions on older chipsets when newer
> > hardware support was picked up. Esoteric bugs that had been fixed with
> > the help of the support team weren't folded in properly in the
> > upstream sources, or when they did they looked sufficiently different
> > that when -stable came around they didn't want to revert back to that
> > version, or they weren't yet picked up for upstream and now other
> > fixes were touching the same code and that seemed risky. They had a
> > code base that worked for the use cases they cared about (with the fix
> > applied that the support team had provided), and very little interest
> > in risking a regression from switching to the upstream version.
>
> Hrm.  That's interesting color commentary, thanks.


As mentioned downthread already: This wasn't actually for a BSP-based
embedded chipset/driver. This was for common hardware found in many laptops
(at the time).


> This won't help
> for those devices that are't using BSP kernels from SOC vendors, but
> for those platforms where kernels from vendors are available, do you
> know off-hand if they are tracking -stable?  Because if they are,
> presumably at least the SOC vendors would have the capability of doing
> the necessary testing.
>
> OTOH, the problem with that is once the SOC vendors have stopped
> selling a particular chip version, they probably don't have any
> interest in continuing to do QA for stable kernels for that particular
> SOC set.  So I'm guessing the answer is "no", it won't help, but I'd
> love to be pleasantly surprised to the contrary.
>

Optimizing our workflow for what some random SoC manufacturer does with
their BSP is probably not a useful exercise. As you say, once they're done
with the product they usually move on to the next generation.

As arm-soc maintainer, it's very rare that we see fixes targeted to
-stable, often because I don't think there are many downstream users of the
upstream tree for embedded platforms, so including fixes there doesn't mean
it shows up in product trees. As platforms do get more and more support, it
will get better over time but it's not there yet.


> > Instead, what the team started doing was using -stable as a source for
> > fixes -- when looking at a bug, first think you looked for was to see
> > if someone had touched that code/subsystem in -stable. It's not ideal
> > in the sense that you have to hit the bug and someone has to look at
> > it, but it was the state we ended up in on that project. It means
> > -stable still has substanial value even though it's not merged
> > directly.
>
> The concern with this approach is that it won't necessary get security
> fixes, since that implies that the product team is only looking at
> -stable once a bug has been reported.
>

That's true. For fixes that get CVE labels there's sometimes tracking that
happens and things get picked up, but for "silent" security fixes there's
not.


> I could tell interested product teams that there are patches that will
> prevent an maliciously crafted SD card from hanging a system or
> causing a memory bounds overrun possibly leading to a privilege
> escalation attack (for example), but that really doesn't scale, and
> unless the maintainer uses out-of-band notification methods, how would
> the product team know to look in -stable?
>

By tracking CVEs or having representation on the security lists. Only large
projects tend to have resources to do so, unfortunately.


-Olof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160710/4303b5ec/attachment.html>