All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH v6] boot-time control
Date: Fri, 6 Jul 2018 15:31:48 -0500	[thread overview]
Message-ID: <20180706203148.7avvltoccresozoq@treble> (raw)
In-Reply-To: <nycvar.YFH.7.76.1807062210050.997@cbobk.fhfr.pm>

On Fri, Jul 06, 2018 at 10:19:39PM +0200, speck for Jiri Kosina wrote:
> On Fri, 6 Jul 2018, speck for Josh Poimboeuf wrote:
> 
> > Will you be doing the sysfs control next?
> 
> Once this is in, I am planning to do so, but this alone has bigger 
> priority on my list, so I want to have that in first.
> 
> [ ... snip the stylistic fixes / typos ... ]
> > > +			case L1TF_MITIGATION_FULL:
> > > +				/*
> > > +				 * Warn if SMT has been runtime-enabled. We can't
> > > +				 * really warn only once here, as SMT state is
> > > +				 * not constant.
> > > +				 */
> > > +				if (cpu_smt_control == CPU_SMT_ENABLED)
> > > +					pr_warn(L1TF_MSG_SMT);
> > 
> > I think I said this sounded ok on IRC, but...
> > 
> > This repeated warning will be very annoying for those people enabling 
> > SMT on purpose.  I think a one-time warning would be better.
> 
> No problem with that.
> 
> On Fri, 6 Jul 2018, speck for Luck, Tony wrote:
> 
> > If you feel that you must have the CVE here, 
> 
> I don't; if Intel has any better suggestions that would be equally 
> alerting the sysadmin, let's change it to whatever works the best.
> 
> > then shouldn't you have CVE-2018-3646 which covers the virtualization 
> > aspects of L1TF rather than CVE-2018-3620 which just covers OS and SMM 
> > implications?
> 
> Good catch, I copied the CVE number from what we already have in speck.git 
> (via 26acfb666a473) and didn't cross-check it. So either it has to be 
> changed via this (modified(*)) patch, or it should be fixed independetly 
> in speck.git.
> 
> (*) Thomas, all the comments so far are rather cosmetic ... if nothing 
>     else pops up, do you prefer to fix that up on your side when applying, 
>     or should I send v8?

With the above changed to a one-time warning (with comment adjusted
accordingly) and typos fixed:

Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>

-- 
Josh

  reply	other threads:[~2018-07-06 20:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06 18:47 [MODERATED] [PATCH v6] boot-time control Jiri Kosina
2018-07-06 19:10 ` [MODERATED] " Andi Kleen
2018-07-06 19:23   ` Jiri Kosina
2018-07-06 19:39     ` Thomas Gleixner
2018-07-06 20:06     ` [MODERATED] " Luck, Tony
2018-07-06 20:19       ` Jiri Kosina
2018-07-06 20:31         ` Josh Poimboeuf [this message]
2018-07-06 20:01 ` Josh Poimboeuf
2018-07-08 12:42 ` Thomas Gleixner
2018-07-08 13:13   ` [MODERATED] " Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180706203148.7avvltoccresozoq@treble \
    --to=jpoimboe@redhat.com \
    --cc=speck@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.