linux-kernel - Re: [PATCH] x86, microcode: Make reload interface per system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Jun 2012 15:57:36 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Borislav Petkov <bp@...64.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Dimitri Sivanich <sivanich@....com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: [PATCH] x86, microcode: Make reload interface per system

On Tue, 19 Jun 2012, Borislav Petkov wrote:
> On Mon, Jun 18, 2012 at 11:46:39PM -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 15 Jun 2012, Borislav Petkov wrote:
> > > From: Borislav Petkov <borislav.petkov@....com>
> > > Date: Fri, 15 Jun 2012 18:46:05 +0200
> > > Subject: [PATCH] x86, microcode: Make reload interface per system
> > > 
> > > The reload interface should be per-system so that a full system ucode
> > > reload happens (on each core) when doing
> > > 
> > > echo 1 > /sys/devices/system/cpu/microcode/reload
> > > 
> > > Move it to the cpu subsys directory instead of it being per-cpu.
> > > 
> > > Signed-off-by: Borislav Petkov <borislav.petkov@....com>
> > 
> > It is a pity this one is much harder to backport to 3.2 and 3.0.
> 
> Yeah, not harder. It changes the sysfs interface and we can't do that
> for already released kernels.
> 
> But I think you meant that.

Yeah.

I was wondering whether it would be worthwhile to backport the new ABI for
the Debian 3.2 kernel or not.  Probably not.

Backporting to 3.2 and 3.0 is straigthforward, however it will look nasty as
one has to "inappropriately touch" the cpu sysdev class to get the attribute
group directly connected to /sys/devices/system/cpu.

I did notice there were no stable backports of the error unwind during
module init, but that one is a very rarely used codepath.  Maybe worth to
backport a fix to stable, though.

> > I'd really like to have the new interface there. But it looks good,
> > and we will support the new /sys/devices/system/cpu/microcode/reload
> > sysfs node in Debian for the benefit of anyone using a newer kernel
> > than the distro's (which will be based on 3.2).
> 
> Right, hopefully the next Debian release will have that nice shiny new
> interface :-)

I sure hope so :)  Actually, I hope Debian will release a
"stable-and-a-half" that will already have it.

> > So, fwiw, you have my:
> > Acked-by-unimportant-person: Henrique de Moraes Holschuh <hmh@....eng.br>
> 
> No, don't underestimate yourself. I think it helps a lot to have someone
> look at the patch and even better: give comments whether what we're
> doing is sane for userspace. So, I appreciate your comments a lot, keep
> 'em coming :-)

Well, my ack is unimportant in the "this is not an area of the kernel I have
any authority to ack things" sense.  But we don't have a "I-wanna-that-by:"
or even a "Thumbs-up-by:"...

> Thanks for review and testing, I'll send out the patches soon.

Thank you for addressing these issues and writing the patches!

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/