lkml.org 
[lkml]   [2017]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fixing CVE-2017-15361
On Thu, Oct 26, 2017 at 07:02:37PM +0200, Jarkko Sakkinen wrote:
> On Thu, Oct 26, 2017 at 04:57:48PM +0200, Michal Suchánek wrote:
> > On Thu, 26 Oct 2017 16:06:02 +0200
> > Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > > On Thu, Oct 26, 2017 at 02:59:02PM +0200, Michal Suchánek wrote:
> > > > It does not really matter. People ignore the messages unless looking
> > > > for something specific as you already noticed. Warn seems adequate
> > > > because the cipher is weaker than expected but not known to
> > > > be compromised. People who care can look up the message. People who
> > > > don't care will ignore it even if it's crit.
> > >
> > > Is it worth of trouble to do any driver changes then (open question to
> > > everyone)? I'm not sure it is worth of trouble to add cruft to the
> > > driver code for a warning that will likely be ignored anyway.
> >
> > If the kernel can reliably detect the affected TPMs it saves the
> > user the work of figuring out where the firmware revision is accessible
> > on the running machine and what firmware revisions are affected.
> >
> > Thanks
> >
> > Michal
>
> Just giving the warning does not require any kernel functionality. If
> nothing proactive is required from the kernel I'd move the
> responsibility to the user space. Nothing in the kernel is broken an
> kernel cannot workaround the issue by ay means.
>
> /Jarkko

I.e. I'm not going to fix a bug if there is no bug to fix.

/Jarkko

\
 
 \ /
  Last update: 2017-10-26 19:04    [W:0.092 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site