linux-kernel - Re: Issues with AMD microcode updates

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]

Message-ID: <20130919164409.GA9427@pd.tnic>
Date:	Thu, 19 Sep 2013 18:44:09 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Jacob Shin <jacob.shin@....com>,
	Andreas Herrmann <herrmann.der.user@...glemail.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Issues with AMD microcode updates

On Thu, Sep 19, 2013 at 11:58:34AM -0300, Henrique de Moraes Holschuh wrote:
> Jacob, Andreas,
> 
> I take care of the amd64 microcode update support for Debian, and I'm
> receiving user reports of lockup issues with the AMD microcode driver in
> several kernels.  This is about the runtime update interface,
> /sys/devices/system/cpu/*/microcode/reload and
> /sys/devices/system/cpu/microcode/reload.
> 
> Basically, the issue is that the process that tries to write "1" to the
> reload node gets stuck in "D" state on several kernel versions.
> 
> I started by blacklisting several older kernels (e.g. I got a report of
> 2.6.38 locking up), but recently I got a report of a lockup with kernel
> 3.5.1.  Blacklisting everything before 3.10 is not exactly kosher, not when
> I would have to blindly trust 3.0, 3.2 and 3.4 to not have whatever issue is
> causing the lockups.
> 
> IMHO that's the point where it becomes interesting to actually track down
> the bug even if it apparently doesn't exist anymore on the more recent
> kernels, and ensure that the stable/long-term kernels have the fix.  That
> would also help distros blacklist microcode update on the broken kernels.
> 
> Unfortunately, I don't own, or have access to, any boxes with an AMD
> processor (let alone one with an AMD processor in need of a microcode
> update) to bissect the problem.
> 
> I'd appreciate if AMD (or anyone with an AMD processor, really) could help
> me track this issue down.
> 
> Debian bug reports:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717185
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723081

Well, both Andreas and Jacob don't work for AMD anymore. I could try to
help with this but it'll be slow as I'm pretty busy with other stuff.

Anyway, I'd suggest we look only on the long term kernels since they're
the only ones which can get updates/fixes anyway.

Now, how do I reproduce this? Writing 1 to .../reload on latest kernel
works here. So I'd need a reproducer. Alternatively, I'd need a sysrq-l
and sysrq-w from those systems with hung processes.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/