Yocto, Kernel and OpenBMC security maintenance

Yocto, Kernel and OpenBMC security maintenance

[Joel Stanley]

On todays community call we chatted about security updates for the
project. Nancy pointed out that there tools in the tree that are many
versions out of date and have security fixes available, but not
applied to our tree.

To date there has been no focused effort on ensuring known
vulnerabilities are patched, weather this be backporting patches or
updating to newer releases. I suggested we focus on ensuring the
OpenBMC tree, as the upstream for our products, is where security
fixes are applied.

Taking that a further step would be to maintain security fixes against
the Yocto release that OpenBMC has based itself on. It appears that
Yocto does this:

From https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance

> The Yocto Project maintains stable branches of Poky (OE-Core and
> BitBake). Typically, alongside the latest release the previous two
> releases are also maintained.

It looks like we should assign someone to ensure the OpenBMC Yocto
tree is kept up to date against the upstream branch.

Regarding the kernel, the intention has been to regularly update to
ensure we are on a maintained kernel. That hasn't gone smoothly to
date, but we will keep trying. We may end up maintaining a long-lived
tree on top of the long term Linux kernel community maintained 4.14,
in addition to moving master forward to the most recent releases.

Please reply to this mail with improvements, thoughts, suggestions,
objections. If you want to volunteer to help maintain an aspect of the
project, or know someone who does, please put your hand up.

Cheers,

Joel

Re: Yocto, Kernel and OpenBMC security maintenance

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Tue, 2017-11-07 at 15:56 +1030, Joel Stanley wrote:
> On todays community call we chatted about security updates for the
> project. Nancy pointed out that there tools in the tree that are many
> versions out of date and have security fixes available, but not
> applied to our tree.
> 
> To date there has been no focused effort on ensuring known
> vulnerabilities are patched, weather this be backporting patches or
> updating to newer releases. I suggested we focus on ensuring the
> OpenBMC tree, as the upstream for our products, is where security
> fixes are applied.

For what it's worth there's some discussion of upgrading to Yocto 2.3
and what we might do to better track master on the issue tracker:

https://github.com/openbmc/openbmc/issues/2461

I agree we need to improve how we track things such as security patches
that go into upstream.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Yocto, Kernel and OpenBMC security maintenance

[Xo Wang]

On Sun, Nov 12, 2017 at 9:37 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> On Tue, 2017-11-07 at 15:56 +1030, Joel Stanley wrote:
> > On todays community call we chatted about security updates for the
> > project. Nancy pointed out that there tools in the tree that are many
> > versions out of date and have security fixes available, but not
> > applied to our tree.
> >
> > To date there has been no focused effort on ensuring known
> > vulnerabilities are patched, weather this be backporting patches or
> > updating to newer releases. I suggested we focus on ensuring the
> > OpenBMC tree, as the upstream for our products, is where security
> > fixes are applied.
>
> For what it's worth there's some discussion of upgrading to Yocto 2.3
> and what we might do to better track master on the issue tracker:
>
> https://github.com/openbmc/openbmc/issues/2461
>
> I agree we need to improve how we track things such as security patches
> that go into upstream.
>
> Andrew

Any opinions on whether to merge point releases (e.g. currently 2.2.x
releases) or to continuously pull in from the stable branch (e.g.
currently yocto's morty branch)?

Also does anyone have objections to pulling in 2.2.2 at this time? It
could potentially be painless. The fixes we'd get are noted in release
notes.
https://www.yoctoproject.org/downloads/core/morty221
https://www.yoctoproject.org/downloads/core/morty222

cheers
xo

Re: Yocto, Kernel and OpenBMC security maintenance

[Joel Stanley]

On Tue, Nov 14, 2017 at 10:44 AM, Xo Wang <xow@google.com> wrote:
> On Sun, Nov 12, 2017 at 9:37 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>>
>> On Tue, 2017-11-07 at 15:56 +1030, Joel Stanley wrote:
>> > On todays community call we chatted about security updates for the
>> > project. Nancy pointed out that there tools in the tree that are many
>> > versions out of date and have security fixes available, but not
>> > applied to our tree.
>> >
>> > To date there has been no focused effort on ensuring known
>> > vulnerabilities are patched, weather this be backporting patches or
>> > updating to newer releases. I suggested we focus on ensuring the
>> > OpenBMC tree, as the upstream for our products, is where security
>> > fixes are applied.
>>
>> For what it's worth there's some discussion of upgrading to Yocto 2.3
>> and what we might do to better track master on the issue tracker:
>>
>> https://github.com/openbmc/openbmc/issues/2461
>>
>> I agree we need to improve how we track things such as security patches
>> that go into upstream.
>>
>> Andrew
>
> Any opinions on whether to merge point releases (e.g. currently 2.2.x
> releases) or to continuously pull in from the stable branch (e.g.
> currently yocto's morty branch)?

I maintain the openpower host firmware build system, where we use
buildroot. There I merge in point releases as a rule, but if there's a
fix in the stable tree that we need I have merged it immediately.

I propose these become our rules, in order of preference:

1. Point releases are merged in as they appear
2. If you have a fix you want merged in that is not in a point
release, we can merge the stable branch
3. If you have a fix merged upstream but not in a stable tree, we can
cherry pick that commit

> Also does anyone have objections to pulling in 2.2.2 at this time? It
> could potentially be painless. The fixes we'd get are noted in release
> notes.
> https://www.yoctoproject.org/downloads/core/morty221
> https://www.yoctoproject.org/downloads/core/morty222

Looks fine to me. Can you coordinate with Brad on how we want this done?

We should also create a plan for moving to 2.3 or 2.4.

Cheers,

Joel