[Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Eduardo Valentin]

Hello,

I would like to open a discussion on improving the annotation
around CVE patches on the Linux kernel. Today, the kernel Documentation
mentions about CVE assignment and asks as a good practice to at least
mention the CVE  number in the patch [1]. But, is that enough?
Should the kernel have more info about what patches fixes a specific
CVE?

Some of the challenges with current process:
- The info about of about what CVEs have been patched in a kernel is
  outside the kernel tree / git history.
- Today, some patches have the CVE info, and many others do not mention
  anything about CVE number.
- As mentioned in the kernel documentation [1], not always the CVE
  number is assigned when the patch(es) go into the kernel tree, so
  maybe this may require some post merge annotation?
- It is not always straight forward to know what patches are needed to
  fix the CVE, specially on cases the fix require a series of
  preparation work before the actual fix.

  Specially on the later case, annotation can help, specially while
  backporting.

BR,


[1] - https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Justin Forbes]

On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> Hello,
>
> I would like to open a discussion on improving the annotation
> around CVE patches on the Linux kernel. Today, the kernel Documentation
> mentions about CVE assignment and asks as a good practice to at least
> mention the CVE  number in the patch [1]. But, is that enough?
> Should the kernel have more info about what patches fixes a specific
> CVE?
>
> Some of the challenges with current process:
> - The info about of about what CVEs have been patched in a kernel is
>   outside the kernel tree / git history.
> - Today, some patches have the CVE info, and many others do not mention
>   anything about CVE number.
> - As mentioned in the kernel documentation [1], not always the CVE
>   number is assigned when the patch(es) go into the kernel tree, so
>   maybe this may require some post merge annotation?

This is also sometimes relevant when you can fix and embargoed CVE
before embargo lifts because the actual fix doesn't make it obvious
that there is a security issue. Obfuscation is a somewhat useful tool
when fixing security bugs sometimes.  I would rather get the patches
in sooner than have them be properly annotated for the security fixes
they really are.

> - It is not always straight forward to know what patches are needed to
>   fix the CVE, specially on cases the fix require a series of
>   preparation work before the actual fix.
>
>   Specially on the later case, annotation can help, specially while
>   backporting.
>
It might be helpful in the cases where the fixes go in before the CVE
is announced/disclosed, to have the author send a summary once things
are public?

> BR,
>
>
> [1] - https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Takashi Iwai]

On Tue, 11 Sep 2018 13:57:09 +0200,
Justin Forbes wrote:
> 
> On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > Hello,
> >
> > I would like to open a discussion on improving the annotation
> > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > mentions about CVE assignment and asks as a good practice to at least
> > mention the CVE  number in the patch [1]. But, is that enough?
> > Should the kernel have more info about what patches fixes a specific
> > CVE?
> >
> > Some of the challenges with current process:
> > - The info about of about what CVEs have been patched in a kernel is
> >   outside the kernel tree / git history.
> > - Today, some patches have the CVE info, and many others do not mention
> >   anything about CVE number.
> > - As mentioned in the kernel documentation [1], not always the CVE
> >   number is assigned when the patch(es) go into the kernel tree, so
> >   maybe this may require some post merge annotation?
> 
> This is also sometimes relevant when you can fix and embargoed CVE
> before embargo lifts because the actual fix doesn't make it obvious
> that there is a security issue. Obfuscation is a somewhat useful tool
> when fixing security bugs sometimes.  I would rather get the patches
> in sooner than have them be properly annotated for the security fixes
> they really are.

I hoped that git-notes could be used for such additional post-release
notes.  But it seems that it never flies well due to various
reasons...


Takashi

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Greg KH]

On Tue, Sep 11, 2018 at 02:00:58PM +0200, Takashi Iwai wrote:
> On Tue, 11 Sep 2018 13:57:09 +0200,
> Justin Forbes wrote:
> > 
> > On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > > Hello,
> > >
> > > I would like to open a discussion on improving the annotation
> > > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > > mentions about CVE assignment and asks as a good practice to at least
> > > mention the CVE  number in the patch [1]. But, is that enough?
> > > Should the kernel have more info about what patches fixes a specific
> > > CVE?
> > >
> > > Some of the challenges with current process:
> > > - The info about of about what CVEs have been patched in a kernel is
> > >   outside the kernel tree / git history.
> > > - Today, some patches have the CVE info, and many others do not mention
> > >   anything about CVE number.
> > > - As mentioned in the kernel documentation [1], not always the CVE
> > >   number is assigned when the patch(es) go into the kernel tree, so
> > >   maybe this may require some post merge annotation?
> > 
> > This is also sometimes relevant when you can fix and embargoed CVE
> > before embargo lifts because the actual fix doesn't make it obvious
> > that there is a security issue. Obfuscation is a somewhat useful tool
> > when fixing security bugs sometimes.  I would rather get the patches
> > in sooner than have them be properly annotated for the security fixes
> > they really are.
> 
> I hoped that git-notes could be used for such additional post-release
> notes.  But it seems that it never flies well due to various
> reasons...

I do remember a tree somewhere on github that had a tracking between
cves and kernel commits.  It was a pain to keep up to date, but the
author was doing a good job for a number of months.

Can't find it now...

Anyway, the main problem here is that almost all the time, CVEs are
assigned _after_ the patch is in the kernel tree.  And we can't go back
in time to change a changelog entry.

Also, what about huge series of patches all to fix one CVE?  What would
you put down for the single Meltdown commit?

So this is up to those that wish to track these types of things, good
luck!

And yes, this is my "CVEs are a joke" feelings coming through here,
sorry if you are someone who has to treat them as something important...

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Dan Carpenter]

On Tue, Sep 11, 2018 at 04:21:34PM +0200, Greg KH wrote:
> On Tue, Sep 11, 2018 at 02:00:58PM +0200, Takashi Iwai wrote:
> > On Tue, 11 Sep 2018 13:57:09 +0200,
> > Justin Forbes wrote:
> > > 
> > > On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > I would like to open a discussion on improving the annotation
> > > > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > > > mentions about CVE assignment and asks as a good practice to at least
> > > > mention the CVE  number in the patch [1]. But, is that enough?
> > > > Should the kernel have more info about what patches fixes a specific
> > > > CVE?
> > > >
> > > > Some of the challenges with current process:
> > > > - The info about of about what CVEs have been patched in a kernel is
> > > >   outside the kernel tree / git history.
> > > > - Today, some patches have the CVE info, and many others do not mention
> > > >   anything about CVE number.
> > > > - As mentioned in the kernel documentation [1], not always the CVE
> > > >   number is assigned when the patch(es) go into the kernel tree, so
> > > >   maybe this may require some post merge annotation?
> > > 
> > > This is also sometimes relevant when you can fix and embargoed CVE
> > > before embargo lifts because the actual fix doesn't make it obvious
> > > that there is a security issue. Obfuscation is a somewhat useful tool
> > > when fixing security bugs sometimes.  I would rather get the patches
> > > in sooner than have them be properly annotated for the security fixes
> > > they really are.
> > 
> > I hoped that git-notes could be used for such additional post-release
> > notes.  But it seems that it never flies well due to various
> > reasons...
> 
> I do remember a tree somewhere on github that had a tracking between
> cves and kernel commits.  It was a pain to keep up to date, but the
> author was doing a good job for a number of months.
> 
> Can't find it now...

Eugene Teo ran one.  But that was years ago.  It's probably easier to
just use the Ubuntu break/fix CVE list.

https://launchpad.net/ubuntu-cve-tracker

regards,
dan carpenter

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Takashi Iwai]

On Tue, 11 Sep 2018 16:21:34 +0200,
Greg KH wrote:
> 
> On Tue, Sep 11, 2018 at 02:00:58PM +0200, Takashi Iwai wrote:
> > On Tue, 11 Sep 2018 13:57:09 +0200,
> > Justin Forbes wrote:
> > > 
> > > On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > I would like to open a discussion on improving the annotation
> > > > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > > > mentions about CVE assignment and asks as a good practice to at least
> > > > mention the CVE  number in the patch [1]. But, is that enough?
> > > > Should the kernel have more info about what patches fixes a specific
> > > > CVE?
> > > >
> > > > Some of the challenges with current process:
> > > > - The info about of about what CVEs have been patched in a kernel is
> > > >   outside the kernel tree / git history.
> > > > - Today, some patches have the CVE info, and many others do not mention
> > > >   anything about CVE number.
> > > > - As mentioned in the kernel documentation [1], not always the CVE
> > > >   number is assigned when the patch(es) go into the kernel tree, so
> > > >   maybe this may require some post merge annotation?
> > > 
> > > This is also sometimes relevant when you can fix and embargoed CVE
> > > before embargo lifts because the actual fix doesn't make it obvious
> > > that there is a security issue. Obfuscation is a somewhat useful tool
> > > when fixing security bugs sometimes.  I would rather get the patches
> > > in sooner than have them be properly annotated for the security fixes
> > > they really are.
> > 
> > I hoped that git-notes could be used for such additional post-release
> > notes.  But it seems that it never flies well due to various
> > reasons...
> 
> I do remember a tree somewhere on github that had a tracking between
> cves and kernel commits.  It was a pain to keep up to date, but the
> author was doing a good job for a number of months.
> 
> Can't find it now...
> 
> Anyway, the main problem here is that almost all the time, CVEs are
> assigned _after_ the patch is in the kernel tree.  And we can't go back
> in time to change a changelog entry.

Actually, git-notes is exactly for that purpose: adding notes after
the commit.  Say, you have a shiny new CVE for the commit in 4.19-rc2,
and you can put the CVE number in each commit via git-notes.  Then
git-log will show that notes, and you can search over the notes in a
(sort of) namespace, too.

The same would work for the reverse-mapping of Fixes tag, too, BTW.

The pain point of git-notes is the way to share the notes.
Also it's not really scalable.  But for the amount of CVE numbering,
it should suffice, I guess.

> Also, what about huge series of patches all to fix one CVE?  What would
> you put down for the single Meltdown commit?
> 
> So this is up to those that wish to track these types of things, good
> luck!
> 
> And yes, this is my "CVEs are a joke" feelings coming through here,
> sorry if you are someone who has to treat them as something important...

Heh, I share your feeling :)


thanks,

Takashi

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Leon Romanovsky]

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

On Tue, Sep 11, 2018 at 04:21:34PM +0200, Greg KH wrote:
> On Tue, Sep 11, 2018 at 02:00:58PM +0200, Takashi Iwai wrote:
> > On Tue, 11 Sep 2018 13:57:09 +0200,
> > Justin Forbes wrote:
> > >
> > > On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > I would like to open a discussion on improving the annotation
> > > > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > > > mentions about CVE assignment and asks as a good practice to at least
> > > > mention the CVE  number in the patch [1]. But, is that enough?
> > > > Should the kernel have more info about what patches fixes a specific
> > > > CVE?
> > > >
> > > > Some of the challenges with current process:
> > > > - The info about of about what CVEs have been patched in a kernel is
> > > >   outside the kernel tree / git history.
> > > > - Today, some patches have the CVE info, and many others do not mention
> > > >   anything about CVE number.
> > > > - As mentioned in the kernel documentation [1], not always the CVE
> > > >   number is assigned when the patch(es) go into the kernel tree, so
> > > >   maybe this may require some post merge annotation?
> > >
> > > This is also sometimes relevant when you can fix and embargoed CVE
> > > before embargo lifts because the actual fix doesn't make it obvious
> > > that there is a security issue. Obfuscation is a somewhat useful tool
> > > when fixing security bugs sometimes.  I would rather get the patches
> > > in sooner than have them be properly annotated for the security fixes
> > > they really are.
> >
> > I hoped that git-notes could be used for such additional post-release
> > notes.  But it seems that it never flies well due to various
> > reasons...
>
> I do remember a tree somewhere on github that had a tracking between
> cves and kernel commits.  It was a pain to keep up to date, but the
> author was doing a good job for a number of months.
>
> Can't find it now...
>
> Anyway, the main problem here is that almost all the time, CVEs are
> assigned _after_ the patch is in the kernel tree.  And we can't go back
> in time to change a changelog entry.

Greg,

There is another huge problem - legal complications vs. desire to
upstream fix as fast as possible.

Most probably all HW vendors are tied with legal contracts to provide to
their customers fix to security breach in advance, before making it
publicly available.

It means that putting CVE in changelogs will require from such HW
vendors to delay ALL CVE patches, while current legal situation allows
them to fix without too much noise and inform all relevant parties in
parallel.

>
> Also, what about huge series of patches all to fix one CVE?  What would
> you put down for the single Meltdown commit?
>
> So this is up to those that wish to track these types of things, good
> luck!
>
> And yes, this is my "CVEs are a joke" feelings coming through here,
> sorry if you are someone who has to treat them as something important...
>
> greg k-h
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] CVE patches annotation

[Greg KH]

On Tue, Sep 11, 2018 at 05:45:23PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 11, 2018 at 04:21:34PM +0200, Greg KH wrote:
> > On Tue, Sep 11, 2018 at 02:00:58PM +0200, Takashi Iwai wrote:
> > > On Tue, 11 Sep 2018 13:57:09 +0200,
> > > Justin Forbes wrote:
> > > >
> > > > On Mon, Sep 10, 2018 at 8:11 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > I would like to open a discussion on improving the annotation
> > > > > around CVE patches on the Linux kernel. Today, the kernel Documentation
> > > > > mentions about CVE assignment and asks as a good practice to at least
> > > > > mention the CVE  number in the patch [1]. But, is that enough?
> > > > > Should the kernel have more info about what patches fixes a specific
> > > > > CVE?
> > > > >
> > > > > Some of the challenges with current process:
> > > > > - The info about of about what CVEs have been patched in a kernel is
> > > > >   outside the kernel tree / git history.
> > > > > - Today, some patches have the CVE info, and many others do not mention
> > > > >   anything about CVE number.
> > > > > - As mentioned in the kernel documentation [1], not always the CVE
> > > > >   number is assigned when the patch(es) go into the kernel tree, so
> > > > >   maybe this may require some post merge annotation?
> > > >
> > > > This is also sometimes relevant when you can fix and embargoed CVE
> > > > before embargo lifts because the actual fix doesn't make it obvious
> > > > that there is a security issue. Obfuscation is a somewhat useful tool
> > > > when fixing security bugs sometimes.  I would rather get the patches
> > > > in sooner than have them be properly annotated for the security fixes
> > > > they really are.
> > >
> > > I hoped that git-notes could be used for such additional post-release
> > > notes.  But it seems that it never flies well due to various
> > > reasons...
> >
> > I do remember a tree somewhere on github that had a tracking between
> > cves and kernel commits.  It was a pain to keep up to date, but the
> > author was doing a good job for a number of months.
> >
> > Can't find it now...
> >
> > Anyway, the main problem here is that almost all the time, CVEs are
> > assigned _after_ the patch is in the kernel tree.  And we can't go back
> > in time to change a changelog entry.
> 
> Greg,
> 
> There is another huge problem - legal complications vs. desire to
> upstream fix as fast as possible.
> 
> Most probably all HW vendors are tied with legal contracts to provide to
> their customers fix to security breach in advance, before making it
> publicly available.
> 
> It means that putting CVE in changelogs will require from such HW
> vendors to delay ALL CVE patches, while current legal situation allows
> them to fix without too much noise and inform all relevant parties in
> parallel.

Yet another good reason why we will never require this :)

thanks for bringing it up,

greg k-h