linux-kernel - Re: Bricked x86 CPU with software?

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: <5A501FAB.5052.58CB6DD@tim.ml.ipcopper.com>
Date:   Fri, 05 Jan 2018 17:00:27 -0800
From:   "Tim Mouraveiko" <tim.ml@...opper.com>
To:     james harvey <jamespharvey20@...il.com>
CC:     Pavel Machek <pavel@....cz>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Bricked x86 CPU with software?

> On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko <tim.ml@...opper.com> wrote:
> > Pavel,
> >
> > As I mentioned before, I repeatedly and fully power-cycled the motherboard and reset BIOS
> > and etc. It made no difference. I can see that the processor was not drawing any power. The
> > software code behaved in a similar fashion on other processors, until I fixed it so that it would
> > not kill any more processors.
> >
> > In case you are curious there was no overheating, no 100% utilization, no tampering with
> > hardware (GPIO pins or anything of that sort), no overclocking and etc. No hardware issues
> > or changes at all.
> >
> > Tim
> 
> To clarify, by "in a similar fashion on other processors", do you
> actually mean you consistently bricked multiple CPUs using the same
> code?  Or, was it just this one CPU that bricked, and it was just
> acting buggy on other processors?
> 
> Unless you consistently bricked multiples, my bet is coincidence.  In
> your original post, "There were signs that something was not right,
> that the code was causing unusual behavior, which is what I was
> debugging." makes me think it was a defective CPU but still
> functional, and died as you were debugging/running the buggy code.

We live and we die by coincidence.

The processor was functioning fine without the code. It showed no signs of any problems. I 
had run a prior version of the code, then ran it without any of that code and it was fine. As I 
launched the nth version of the code, I thought of something and made another change. As I 
turned around to install it, the screen was showing that it had just executed that nth version of 
the code and then didn´t progress any further.

I was actually glad it froze because I was able to gather the results of the execution of the 
code, which I needed for fine-tuning. It was only after hitting the reset button several times 
that it occurred to me that there was something wrong because the screen remained static.

I had added the code in hopes of speeding up the catching of a bug (that I caught later 
without that code). The code made other processors behave the same way.

I did not mean that I consistently bricked processors - I removed the code entirely to avoid 
exactly that.