On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> > I'm filling a bug on Debian glibc, asking them to blacklist HLE until
> > further notice.
>
> FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
Also, glibc lock elisi
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 01:41:21PM -0300, Henrique de Moraes Holschuh wrote:
> > We still need to update x86_capability after a microcode update for the
> > above to really work in the "install microcode into initramfs" case.
>
> I think you mean for t
On Thu, Sep 25, 2014 at 01:41:21PM -0300, Henrique de Moraes Holschuh wrote:
> We still need to update x86_capability after a microcode update for the
> above to really work in the "install microcode into initramfs" case.
I think you mean for the kernels without early microcode loading...
Because
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 12:30:06PM -0300, Henrique de Moraes Holschuh wrote:
> > Userspace can install the microcode only inside the initramfs, if it wants
> > to avoid it being loaded later. It is not even too difficult to do so.
>
> Hmm, so in think
On Thu, Sep 25, 2014 at 12:30:06PM -0300, Henrique de Moraes Holschuh wrote:
> Userspace can install the microcode only inside the initramfs, if it wants
> to avoid it being loaded later. It is not even too difficult to do so.
Hmm, so in thinking about this more, what we need to do on all kernels
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
> > At this point, what alternatives are left?
>
> Here's what we could do:
>
> * Install microcode to /lib/firmware/...
>
> * Refuse to update the microcode and tell the us
On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
> At this point, what alternatives are left?
Here's what we could do:
* Install microcode to /lib/firmware/...
* Refuse to update the microcode and tell the user that she needs to reboot.
* Reboot and load the microcod
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 08:36:45AM -0300, Henrique de Moraes Holschuh wrote:
> > This isn't an useless fix, it will allow systems without early initramfs
> > support to operate correctly after a microcode update.
>
> So what do we do if we update the m
On Thu, Sep 25, 2014 at 08:36:45AM -0300, Henrique de Moraes Holschuh wrote:
> This isn't an useless fix, it will allow systems without early initramfs
> support to operate correctly after a microcode update.
So what do we do if we update the microcode late and some userspace task
is using HLE and
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> > But IMHO we still need to detect and do something smart when
> > x86_capability changes due to a microcode update.
> >
> > And I'd really prefer it to be "update x86_capability, warn the user and
> > carry on" for anything that is not going to crash
On Wed, Sep 24, 2014 at 02:45:57PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
> > On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
> > wrote:
> > > And I'd really prefer it to be "update x86_capability, warn the user and
> > > carry on" for
On Wed, Sep 24, 2014 at 11:56:58AM -0300, Henrique de Moraes Holschuh wrote:
> I don't know about AMD, but on Intel, the time it takes to update the
> microcode on a core is anything but negligible[1], so the microcode
> version skew window still exists, and it is not small. It is much smaller
> t
On Wed, Sep 24, 2014 at 11:59 AM, Henrique de Moraes Holschuh
wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
>> We can sort of fudge it if whatever control BIOS uses is available to
>> us, too, and we can reprogram it to "enabled" after a microcode update
>> disables TSX.
>
> Only for the ea
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
> We can sort of fudge it if whatever control BIOS uses is available to
> us, too, and we can reprogram it to "enabled" after a microcode update
> disables TSX.
Only for the early initramfs microcode update driver, and that's going to be
useful only as a
On Wed, Sep 24, 2014 at 10:45 AM, Henrique de Moraes Holschuh
wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
>> On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
>> wrote:
>> > And I'd really prefer it to be "update x86_capability, warn the user and
>> > carry on" for anything th
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
> On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
> wrote:
> > And I'd really prefer it to be "update x86_capability, warn the user and
> > carry on" for anything that is not going to crash the kernel. Several
> > distros will really want t
On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
wrote:
> On Tue, 23 Sep 2014, Borislav Petkov wrote:
>> On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
>> > 1. offline a "guinea pig" group of "cpus", i.e. an entire "microcode update
>> > unit" that doesn't
On Tue, 23 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
> > 1. offline a "guinea pig" group of "cpus", i.e. an entire "microcode update
> > unit" that doesn't include the BSP. This is going to be a pain, as what
> > composes a "mic
On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
> 1. offline a "guinea pig" group of "cpus", i.e. an entire "microcode update
> unit" that doesn't include the BSP. This is going to be a pain, as what
> composes a "microcode update unit" is not set in stone, and could c
On Sun, Sep 21, 2014 at 05:51:12PM -0700, H. Peter Anvin wrote:
> He said *outside* of the early update mechanism.
True. Sorry yes I misread it.
Yes, that's the way to go.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
He said *outside* of the early update mechanism.
On September 21, 2014 5:37:24 PM PDT, Andi Kleen wrote:
>Henrique de Moraes Holschuh writes:
>
>
>> And yes, this means we will kill support for microcode updates
>> outside of the initramfs/early-initramfs, at least in Debian,
>> and
Henrique de Moraes Holschuh writes:
> And yes, this means we will kill support for microcode updates
> outside of the initramfs/early-initramfs, at least in Debian,
> and likely in Ubuntu.
You got it totally backwards. initramfs updating should handle this
microcode update just fine
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> I'm filling a bug on Debian glibc, asking them to blacklist HLE until
> further notice.
FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
--
"One disk to rule them all, One disk to find them. One disk to bring
them all an
On Fri, 19 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 10:51:08AM -0300, Henrique de Moraes Holschuh wrote:
> > But I will not trigger a microcode update when the intel-microcode package
> > gets updated/installed anymore. The user will be warned of the need for
> > either a reboot
On Fri, 19 Sep 2014, Andy Lutomirski wrote:
> Can we change the ucode blob format for these firmwares so that old
> kernels won't apply them? I have no other good ideas. The trouble is
> that distros *should* push out the new ucode, but only if there's some
> guarantee that they'll only be applie
On Fri, 19 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
> > 2) Don't allow a late update if TSX is still enabled on those
> > processors.
>
> Yeah, so the use case I have in mind is when a long-running machine
> wants to apply microcode and this
On Fri, Sep 19, 2014 at 8:00 AM, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
>> Assuming we can identify all the affected models and steppings, maybe
>> something like this would work:
>>
>> 1) Refuse to finish booting if a microcode update that disables
On Thu, 18 Sep 2014, Andy Lutomirski wrote:
> > [2] instantly segfaulting every running process using libpthread-2.19,
> > as well as any other users of Intel TSX.
> > https://bugs.launchpad.net/intel/+bug/1370352
> >
> > And yes, this means we will kill support for microcode updates
>
On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
> Assuming we can identify all the affected models and steppings, maybe
> something like this would work:
>
> 1) Refuse to finish booting if a microcode update that disables TSX
> isn't applied before userspace starts running on those C
On Fri, Sep 19, 2014 at 10:51:08AM -0300, Henrique de Moraes Holschuh wrote:
> And I will also continue to pester you with patches to the microcode driver
> :-)
That's fine - I'm currently busy and not looking at them but I haven't
forgotten them.
> But I will not trigger a microcode update when
On Fri, 19 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
> > We're also killing microcode update support outside of the initramfs in
> > Debian. It has become obvious that anything other than the early initramfs
> > method of microc
On Fri, 19 Sep 2014 09:14:50 -0400
Josh Boyer wrote:
> On Fri, Sep 19, 2014 at 8:54 AM, Chuck Ebbert wrote:
> > On Fri, 19 Sep 2014 13:29:53 +0200
> > Borislav Petkov wrote:
> >
> >> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh
> >> wrote:
> >> > We're also killing mic
On Fri, Sep 19, 2014 at 8:54 AM, Chuck Ebbert wrote:
> On Fri, 19 Sep 2014 13:29:53 +0200
> Borislav Petkov wrote:
>
>> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
>> > We're also killing microcode update support outside of the initramfs in
>> > Debian. It has be
On Fri, 19 Sep 2014 13:29:53 +0200
Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
> > We're also killing microcode update support outside of the initramfs in
> > Debian. It has become obvious that anything other than the early initramfs
> >
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
> We're also killing microcode update support outside of the initramfs in
> Debian. It has become obvious that anything other than the early initramfs
> method of microcode updates should be considered a developer thing.
On Thu, 18 Sep 2014, Andy Lutomirski wrote:
> On Sep 18, 2014 5:13 PM, "Henrique de Moraes Holschuh"
> wrote:
> > Here's a plan that might work, pending actually checking the libpthread TSX
> > code to make sure it keys on /proc/cpuinfo flags:
>
> Surely it checks cpuid directly, though.
Unfort
On Thu, 18 Sep 2014, Chuck Ebbert wrote:
> > > [1] sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672
> > > sig 0x000306c3, pf mask 0x32, 2014-07-03, rev 0x001c, size 21504
> > > sig 0x00040651, pf mask 0x72, 2014-07-03, rev 0x001c, size 20480
> > > sig 0x00040661, pf mask
On Thu, Sep 18, 2014 at 06:00:12PM -0700, Andy Lutomirski wrote:
> Yes, but how? I assume that BIOS isn't switching between two
> different ucode blobs, and I don't know about any wrcpuid instruction.
> So there must be *some* way, at least on new ucode (and maybe on old
> ucode) to change that bi
On Sep 18, 2014 5:28 PM, "H. Peter Anvin" wrote:
>
> The cpuid bit gets twiddled...
Yes, but how? I assume that BIOS isn't switching between two
different ucode blobs, and I don't know about any wrcpuid instruction.
So there must be *some* way, at least on new ucode (and maybe on old
ucode) to c
The cpuid bit gets twiddled...
On September 18, 2014 5:23:40 PM PDT, Andy Lutomirski
wrote:
>On Sep 18, 2014 5:13 PM, "Henrique de Moraes Holschuh"
>wrote:
>>
>> On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
>> > On Thu, 18 Sep 2014, H. Peter Anvin wrote:
>> > > We should, but this is
On Sep 18, 2014 5:13 PM, "Henrique de Moraes Holschuh" wrote:
>
> On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
> > On Thu, 18 Sep 2014, H. Peter Anvin wrote:
> > > We should, but this is also part of why we want the early ucode
> > > capability.
> >
> > Well, yes. But that won't help
On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Thu, 18 Sep 2014, H. Peter Anvin wrote:
> > We should, but this is also part of why we want the early ucode capability.
>
> Well, yes. But that won't help the several stable and LTS distros with
> kernels without early ucode update supp
On Thu, 18 Sep 2014, H. Peter Anvin wrote:
> We should, but this is also part of why we want the early ucode capability.
Well, yes. But that won't help the several stable and LTS distros with
kernels without early ucode update support.
--
"One disk to rule them all, One disk to find them. One
On Thu, 18 Sep 2014 12:14:59 -0700
Andy Lutomirski wrote:
> On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
> > The new Haswell microcode update[1] removes the "hle" (hardware lock
> > elision) processor capability. And it is not cosmetic, either: Intel TSX
> > opcodes will cause an i
We should, but this is also part of why we want the early ucode capability.
On September 18, 2014 12:53:28 PM PDT, Chuck Ebbert
wrote:
>On Thu, 18 Sep 2014 12:14:59 -0700
>Andy Lutomirski wrote:
>
>> On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
>> > The new Haswell microcode updat
On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
> The new Haswell microcode update[1] removes the "hle" (hardware lock
> elision) processor capability. And it is not cosmetic, either: Intel TSX
> opcodes will cause an illegal opcode trap after the microcode update[2].
>
> This means cp
The new Haswell microcode update[1] removes the "hle" (hardware lock
elision) processor capability. And it is not cosmetic, either: Intel TSX
opcodes will cause an illegal opcode trap after the microcode update[2].
This means cpu_info()->x86_capability becomes stale after the microcode
update.
W
47 matches
Mail list logo
