Bricked x86 CPU with software?

Bricked x86 CPU with software?

[Tim Mouraveiko]

Hi,

In all my years of extensive experience writing drivers and kernels, I never came across a situation 
where you could brick an x86 CPU. Not until recently, when I was working on debugging a piece of 
code and I bricked an Intel CPU. I am not talking about an experimental motherboard or anything 
exotic or an electrical issue where the CPU got fried, but before the software code execution the CPU 
was fine and then it´s dead. There were signs that something was not right, that the code was causing 
unusual behavior, which is what I was debugging.

Has anyone else ever experienced a bricked CPU after executing software code? I just wanted to get 
input from the community to see if anyone had had any experience like that, since it seems rather 
unusual to me.

Tim

Re: Bricked x86 CPU with software?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Hi!

> In all my years of extensive experience writing drivers and kernels, I never came across a situation 
> where you could brick an x86 CPU. Not until recently, when I was working on debugging a piece of 
> code and I bricked an Intel CPU. I am not talking about an experimental motherboard or anything 
> exotic or an electrical issue where the CPU got fried, but before the software code execution the CPU 
> was fine and then it´s dead. There were signs that something was not right, that the code was causing 
> unusual behavior, which is what I was debugging.
> 
> Has anyone else ever experienced a bricked CPU after executing software code? I just wanted to get 
> input from the community to see if anyone had had any experience like that, since it seems rather 
> unusual to me.

Never seen that before. Can you try to brick another one? :-).

You may want to remove AC power and battery, wait for half an hour,
then attempt to boot it...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

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

> Hi!
> 
> > In all my years of extensive experience writing drivers and kernels, I never came across a situation 
> > where you could brick an x86 CPU. Not until recently, when I was working on debugging a piece of 
> > code and I bricked an Intel CPU. I am not talking about an experimental motherboard or anything 
> > exotic or an electrical issue where the CPU got fried, but before the software code execution the CPU 
> > was fine and then it´s dead. There were signs that something was not right, that the code was causing 
> > unusual behavior, which is what I was debugging.
> > 
> > Has anyone else ever experienced a bricked CPU after executing software code? I just wanted to get 
> > input from the community to see if anyone had had any experience like that, since it seems rather 
> > unusual to me.
> 
> Never seen that before. Can you try to brick another one? :-).
> 
> You may want to remove AC power and battery, wait for half an hour,
> then attempt to boot it...
> 
> 									Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 

Re: Bricked x86 CPU with software?

[Andy Shevchenko]

On Thu, Jan 4, 2018 at 11:00 PM, Tim Mouraveiko <tim.ml@ipcopper.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.

Please, do not top post.

Just to be sure, have you checked same CPU on different motherboard?
It might be that voltage regulators on it just died.


>> > In all my years of extensive experience writing drivers and kernels, I never came across a situation
>> > where you could brick an x86 CPU. Not until recently, when I was working on debugging a piece of
>> > code and I bricked an Intel CPU. I am not talking about an experimental motherboard or anything
>> > exotic or an electrical issue where the CPU got fried, but before the software code execution the CPU
>> > was fine and then it愀 dead. There were signs that something was not right, that the code was causing
>> > unusual behavior, which is what I was debugging.
>> >
>> > Has anyone else ever experienced a bricked CPU after executing software code? I just wanted to get
>> > input from the community to see if anyone had had any experience like that, since it seems rather
>> > unusual to me.
>>
>> Never seen that before. Can you try to brick another one? :-).
>>
>> You may want to remove AC power and battery, wait for half an hour,
>> then attempt to boot it...
>>
>>                                                                       Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>
>
>



-- 
With Best Regards,
Andy Shevchenko

Re: Bricked x86 CPU with software?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Hi!

> 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.
> 

So you have code that killed more than one processor? Save it! We want
a copy.

Do you have model numbers of affected CPUs?
									Pavel
									

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On Thu, Jan 4, 2018 at 11:00 PM, Tim Mouraveiko <tim.ml@ipcopper.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.
> 
> Please, do not top post.
> 
> Just to be sure, have you checked same CPU on different motherboard?
> It might be that voltage regulators on it just died.

I did not check the same CPU on a different motherboard, but I did test the code on both the 
same type of CPU and a different type of CPU.

> 
> 
> >> > In all my years of extensive experience writing drivers and kernels, I never came across a situation
> >> > where you could brick an x86 CPU. Not until recently, when I was working on debugging a piece of
> >> > code and I bricked an Intel CPU. I am not talking about an experimental motherboard or anything
> >> > exotic or an electrical issue where the CPU got fried, but before the software code execution the CPU
> >> > was fine and then it dead. There were signs that something was not right, that the code was causing
> >> > unusual behavior, which is what I was debugging.
> >> >
> >> > Has anyone else ever experienced a bricked CPU after executing software code? I just wanted to get
> >> > input from the community to see if anyone had had any experience like that, since it seems rather
> >> > unusual to me.
> >>
> >> Never seen that before. Can you try to brick another one? :-).
> >>
> >> You may want to remove AC power and battery, wait for half an hour,
> >> then attempt to boot it...
> >>
> >>                                                                       Pavel
> >> --
> >> (english) http://www.livejournal.com/~pavelmachek
> >> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> >>
> >
> >
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> > 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.
> > 
> 
> So you have code that killed more than one processor? Save it! We want
> a copy.
> 
> Do you have model numbers of affected CPUs?


Why would you want a copy? Last time I checked bricked CPUs do not work well, even as 
decorations.

I believe the processors were Intel Xeon series. The code would likely run on others too.

Re: Bricked x86 CPU with software?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
> > > 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.
> > > 
> > 
> > So you have code that killed more than one processor? Save it! We want
> > a copy.
> > 
> > Do you have model numbers of affected CPUs?
> 
> 
> Why would you want a copy? Last time I checked bricked CPUs do not work well, even as 
> decorations.
> 
> I believe the processors were Intel Xeon series. The code would likely run on others too.

Well... Intel's shares are overpriced, and you have code to fix that
:-).

Actually... I don't think your code works. That's why I'm curious. But
if it works, its rather a big news... and I'm sure Intel and cloud
providers are going to be interested.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
> > > > 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.
> > > > 
> > > 
> > > So you have code that killed more than one processor? Save it! We want
> > > a copy.
> > > 
> > > Do you have model numbers of affected CPUs?
> > 
> > 
> > Why would you want a copy? Last time I checked bricked CPUs do not work well, even as 
> > decorations.
> > 
> > I believe the processors were Intel Xeon series. The code would likely run on others too.
> 
> Well... Intel's shares are overpriced, and you have code to fix that
> :-).
> 
> Actually... I don't think your code works. That's why I'm curious. But
> if it works, its rather a big news... and I'm sure Intel and cloud
> providers are going to be interested.
> 

I first discovered this issue over a year ago, quite by accident. I changed the code I was 
working on so as not to kill the CPU (as that is not what I was trying to). We made Intel aware 
of it. They didn´t care much, one of their personnel suggesting that they already knew about it 
(whether this is true or not I couldn´t say). It popped up again later, so I had to fix the code 
again. It could be a buggy implementation of a certain x86 functionality, but I left it at that 
because I had better things to do with my time.

Now this news came up about meltdown and spectre and I was curious if anyone else had 
experienced a dead CPU by software, too. Meltdown and spectre are undeniably a problem, 
but the magnitude and practicality of it is questionable.

I suspect that what I discovered is either a kill switch, an unintentional flaw that was 
implemented at the time the original feature was built into x86 functionality and kept 
propagating through successive generations of processors, or could well be that I have a 
very destructive and targeted solar flare that is after my CPUs. So, I figured I would put the 
question out there, to see if anyone else had a similar experience. Putting the solar flare idea 
aside, I can´t conclusively say whether it is a flaw or a feature. Both options are supported at 
this time by my observations of the CPU behavior.

Re: Bricked x86 CPU with software?

[Hector Martin 'marcan']

On 2018-01-05 10:21, Tim Mouraveiko wrote:
>> On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
>> Actually... I don't think your code works. That's why I'm curious. But
>> if it works, its rather a big news... and I'm sure Intel and cloud
>> providers are going to be interested.
>>
> 
> I first discovered this issue over a year ago, quite by accident. I changed the code I was 
> working on so as not to kill the CPU (as that is not what I was trying to). We made Intel aware 
> of it. They didn´t care much, one of their personnel suggesting that they already knew about it 
> (whether this is true or not I couldn´t say). It popped up again later, so I had to fix the code 
> again. It could be a buggy implementation of a certain x86 functionality, but I left it at that 
> because I had better things to do with my time.
> 
> Now this news came up about meltdown and spectre and I was curious if anyone else had 
> experienced a dead CPU by software, too. Meltdown and spectre are undeniably a problem, 
> but the magnitude and practicality of it is questionable.
> 
> I suspect that what I discovered is either a kill switch, an unintentional flaw that was 
> implemented at the time the original feature was built into x86 functionality and kept 
> propagating through successive generations of processors, or could well be that I have a 
> very destructive and targeted solar flare that is after my CPUs. So, I figured I would put the 
> question out there, to see if anyone else had a similar experience. Putting the solar flare idea 
> aside, I can´t conclusively say whether it is a flaw or a feature. Both options are supported at 
> this time by my observations of the CPU behavior.
> 

If you made Intel aware of the issue a year ago, and they weren't
interested, then the responsible thing to do is disclose the problem
publicly. This is a security issue (if trusted code can brick a CPU,
it's an issue for bare metal hosting providers; if untrusted code can
brick a CPU, it's a *huge* issue for every cloud provider and many, many
others who run code in various sandboxes). If the vendor is not
receptive to coordinated disclosure, the only option is public
disclosure to at least make people aware of the problem and allow for
mitigations to be developed, if possible.

Personally, I would be very interested in seeing such code. We've seen
several ways to brick nonvolatile firmware (writable BIOSes, bad CMOS
data, etc.), but bricking a CPU is a first. The only way that can happen
is either blowing a kill fuse, or causing actual hardware damage, since
CPUs have no nonvolatile memory other than fuses. Either way this would
be a very interesting result.

-- 
Hector Martin "marcan" (marcan@marcan.st)
Public Key: https://mrcn.st/pub

Re: Bricked x86 CPU with software?

[james harvey]

On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko <tim.ml@ipcopper.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.

Re: Bricked x86 CPU with software?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

Hi!

On Thu 2018-01-04 17:21:36, Tim Mouraveiko wrote:
> > On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
> > > > > 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.
> > > > >
> > > >
> > > > So you have code that killed more than one processor? Save it! We want
> > > > a copy.
> > > >
> > > > Do you have model numbers of affected CPUs?
> > >
> > >
> > > Why would you want a copy? Last time I checked bricked CPUs do not work well, even as
> > > decorations.
> > >
> > > I believe the processors were Intel Xeon series. The code would likely run on others too.
> >
> > Well... Intel's shares are overpriced, and you have code to fix that
> > :-).
> >
> > Actually... I don't think your code works. That's why I'm curious. But
> > if it works, its rather a big news... and I'm sure Intel and cloud
> > providers are going to be interested.
> >
> 
> I first discovered this issue over a year ago, quite by accident. I changed the code I was
> working on so as not to kill the CPU (as that is not what I was trying to). We made Intel aware
> of it. They didn´t care much, one of their personnel suggesting that they already knew about it
> (whether this is true or not I couldn´t say). It popped up again later, so I had to fix the code
> again. It could be a buggy implementation of a certain x86 functionality, but I left it at that
> because I had better things to do with my time.
>

Is the sequence available from ring 3, or does it need ring 0?

Can we get the code? Extraordinary claims and all that...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On 2018-01-05 10:21, Tim Mouraveiko wrote:
> >> On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
> >> Actually... I don't think your code works. That's why I'm curious. But
> >> if it works, its rather a big news... and I'm sure Intel and cloud
> >> providers are going to be interested.
> >>
> > 
> > I first discovered this issue over a year ago, quite by accident. I changed the code I was 
> > working on so as not to kill the CPU (as that is not what I was trying to). We made Intel aware 
> > of it. They didn´t care much, one of their personnel suggesting that they already knew about it 
> > (whether this is true or not I couldn´t say). It popped up again later, so I had to fix the code 
> > again. It could be a buggy implementation of a certain x86 functionality, but I left it at that 
> > because I had better things to do with my time.
> > 
> > Now this news came up about meltdown and spectre and I was curious if anyone else had 
> > experienced a dead CPU by software, too. Meltdown and spectre are undeniably a problem, 
> > but the magnitude and practicality of it is questionable.
> > 
> > I suspect that what I discovered is either a kill switch, an unintentional flaw that was 
> > implemented at the time the original feature was built into x86 functionality and kept 
> > propagating through successive generations of processors, or could well be that I have a 
> > very destructive and targeted solar flare that is after my CPUs. So, I figured I would put the 
> > question out there, to see if anyone else had a similar experience. Putting the solar flare idea 
> > aside, I can´t conclusively say whether it is a flaw or a feature. Both options are supported at 
> > this time by my observations of the CPU behavior.
> > 
> 
> If you made Intel aware of the issue a year ago, and they weren't
> interested, then the responsible thing to do is disclose the problem
> publicly. This is a security issue (if trusted code can brick a CPU,
> it's an issue for bare metal hosting providers; if untrusted code can
> brick a CPU, it's a *huge* issue for every cloud provider and many, many
> others who run code in various sandboxes). If the vendor is not
> receptive to coordinated disclosure, the only option is public
> disclosure to at least make people aware of the problem and allow for
> mitigations to be developed, if possible.
> 
> Personally, I would be very interested in seeing such code. We've seen
> several ways to brick nonvolatile firmware (writable BIOSes, bad CMOS
> data, etc.), but bricking a CPU is a first. The only way that can happen
> is either blowing a kill fuse, or causing actual hardware damage, since
> CPUs have no nonvolatile memory other than fuses. Either way this would
> be a very interesting result.

We discovered the issue but chose not to distill the code into a standalone CPU-killing app. 
Once we realized that the CPU had been killed by the software and that the code caused 
other CPUs to behave the same way and once Intel said what they said, I made my pitch to 
pursue it, but the decision was made not to. I wasn´t to test the existing code beyond 
removing the offending part of it. Granted, I snuck a few tests in while removing it and a few 
times, for a few seconds, I held my breath. A few months later I had to fix it again.

Among the considerations was the question of what the possible purpose of designing such 
an application would be. Is this a kill switch or unintentional flaw? Particularly in light of Intel´s 
position. The consequences of a successful execution on a compatible CPU is a loss of 
physical property. Intel must have had good reasons to take the position that they did.

This issue would be a non-starter prior to the Pentium FDIV story. Since then Atmel 
popularized storable fuses, and things have gone on from there.

I did consider and investigate the electrical issue as a possible cause. I ruled it out before I 
tested other CPUs and different motherboards. Our OS is not a derivative of linux/freebsd, 
neither in concept nor design. In relevant parts all mainstream operating systems are the 
same design carried over from a long time ago and I dare to say most if not all non-
mainstream copied over the relevant part as well (maybe not exactly), as there was/is no 
good reason not to. In our case we did not have certain features in the OS as there was no 
good reason to have them, until I needed a way to catch a bug. In the end I did find the bug, 
albeit without using the feature.

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko <tim.ml@ipcopper.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.

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> Hi!
> 
> On Thu 2018-01-04 17:21:36, Tim Mouraveiko wrote:
> > > On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
> > > > > > 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.
> > > > > >
> > > > >
> > > > > So you have code that killed more than one processor? Save it! We want
> > > > > a copy.
> > > > >
> > > > > Do you have model numbers of affected CPUs?
> > > >
> > > >
> > > > Why would you want a copy? Last time I checked bricked CPUs do not work well, even as
> > > > decorations.
> > > >
> > > > I believe the processors were Intel Xeon series. The code would likely run on others too.
> > >
> > > Well... Intel's shares are overpriced, and you have code to fix that
> > > :-).
> > >
> > > Actually... I don't think your code works. That's why I'm curious. But
> > > if it works, its rather a big news... and I'm sure Intel and cloud
> > > providers are going to be interested.
> > >
> > 
> > I first discovered this issue over a year ago, quite by accident. I changed the code I was
> > working on so as not to kill the CPU (as that is not what I was trying to). We made Intel aware
> > of it. They didn´t care much, one of their personnel suggesting that they already knew about it
> > (whether this is true or not I couldn´t say). It popped up again later, so I had to fix the code
> > again. It could be a buggy implementation of a certain x86 functionality, but I left it at that
> > because I had better things to do with my time.
> >
> 
> Is the sequence available from ring 3, or does it need ring 0?
> 
> Can we get the code? Extraordinary claims and all that...
> 

I did not test privilege level. Are you suggesting that I put the code out there for everyone to 
see or what?

Re: Bricked x86 CPU with software?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Hi!

> > Is the sequence available from ring 3, or does it need ring 0?
> >
> > Can we get the code? Extraordinary claims and all that...
> >
> 
> I did not test privilege level. Are you suggesting that I put the code out there for everyone to
> see or what?

Yes, that's what I'm suggesting.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Bricked x86 CPU with software?

[Nikolay Borisov]

On  4.01.2018 02:47, Tim Mouraveiko wrote:
> Hi,
> 
> In all my years of extensive experience writing drivers and kernels, I never came across a situation 
> where you could brick an x86 CPU. Not until recently, when I was working on debugging a piece of 
> code and I bricked an Intel CPU. I am not talking about an experimental motherboard or anything 
> exotic or an electrical issue where the CPU got fried, but before the software code execution the CPU 
> was fine and then it´s dead. There were signs that something was not right, that the code was causing 
> unusual behavior, which is what I was debugging.
> 
> Has anyone else ever experienced a bricked CPU after executing software code? I just wanted to get 
> input from the community to see if anyone had had any experience like that, since it seems rather 
> unusual to me.
> 
> Tim
> 

"Code talks, bullshit walks". Unless you share the code I don't think
anyone has any reason to believe anything you said.

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> Hi!
> 
> > > Is the sequence available from ring 3, or does it need ring 0?
> > >
> > > Can we get the code? Extraordinary claims and all that...
> > >
> > 
> > I did not test privilege level. Are you suggesting that I put the code out there for everyone to
> > see or what?
> 
> Yes, that's what I'm suggesting.
> 

That would be neither prudent nor practical.

Perhaps you did not consider the consequences. What if it is compatible with your 
processor? Would you send me a handwritten thank you card if that processor stops 
processing? Would you be a happy replacement-sale customer of Intel? I think you did not 
put much thought into why we are talking about it a year later or at all.

Unlike the now-oh-so-scary feature that was in existence for decades, that is only so scary 
because of a "clever" idea to "cloud" host different customers on bare metal, without any 
consideration to their security, this could affect real people not just oh-so-clever computer 
farmers.

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On Monday 08 of January 2018, Tim Mouraveiko wrote:
> > > Hi!
> > > 
> > > > > Is the sequence available from ring 3, or does it need ring 0?
> > > > > 
> > > > > Can we get the code? Extraordinary claims and all that...
> > > > 
> > > > I did not test privilege level. Are you suggesting that I put the code
> > > > out there for everyone to see or what?
> > > 
> > > Yes, that's what I'm suggesting.
> > 
> > That would be neither prudent nor practical.
> 
> Then send the code to proper people only
> 
> <security@kernel.org>
> 
> https://www.kernel.org/doc/html/v4.10/admin-guide/security-bugs.html

What would the purpose of that be?

I think you missed one of my posts from last week. The code has nothing to do with linux.

Re: Bricked x86 CPU with software?

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Mon 2018-01-08 07:58:33, Tim Mouraveiko wrote:
> > Hi!
> >
> > > > Is the sequence available from ring 3, or does it need ring 0?
> > > >
> > > > Can we get the code? Extraordinary claims and all that...
> > > >
> > >
> > > I did not test privilege level. Are you suggesting that I put the code out there for everyone to
> > > see or what?
> >
> > Yes, that's what I'm suggesting.
> >
> 
> That would be neither prudent nor practical.
> 
> Perhaps you did not consider the consequences. What if it is compatible with your
> processor? Would you send me a handwritten thank you card if that processor stops
> processing? Would you be a happy replacement-sale customer of Intel? I think you did not
> put much thought into why we are talking about it a year later or at
> all.

Actually, yes, thank you card. Not handwritten -- plenty of CPUs here :-).

> Unlike the now-oh-so-scary feature that was in existence for decades, that is only so scary
> because of a "clever" idea to "cloud" host different customers on bare metal, without any
> consideration to their security, this could affect real people not just oh-so-clever computer
> farmers.

I don't believe you actually have a way to brick CPUs.

Yes, it is possible to brick some computers -- overwriting BIOS will
do the trick, for example; doable from ring 0. There is more firmware
that can be overwritten... That's old news. Worth mentioning on
bugtraq, so manufacturer can fix it, but...

If you had something that worked directly on CPU, that would be news;
and yes, there are fuses there, but I really doubt they can be
manipulated by software. And I believe it would be news worth more
than price of a CPU... Still not exactly dangerous. Usually data are
worth more than hardware.

Ouch, and if it worked from ring 3... That would be newsworthy. That
would be actually quite dangerous. OTOH... people did try to fuzz CPU
instruction sets, so my bet is someone would have noticed.


Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On Mon 2018-01-08 07:58:33, Tim Mouraveiko wrote:
> > > Hi!
> > >
> > > > > Is the sequence available from ring 3, or does it need ring 0?
> > > > >
> > > > > Can we get the code? Extraordinary claims and all that...
> > > > >
> > > >
> > > > I did not test privilege level. Are you suggesting that I put the code out there for everyone to
> > > > see or what?
> > >
> > > Yes, that's what I'm suggesting.
> > >
> > 
> > That would be neither prudent nor practical.
> > 
> > Perhaps you did not consider the consequences. What if it is compatible with your
> > processor? Would you send me a handwritten thank you card if that processor stops
> > processing? Would you be a happy replacement-sale customer of Intel? I think you did not
> > put much thought into why we are talking about it a year later or at
> > all.
> 
> Actually, yes, thank you card. Not handwritten -- plenty of CPUs here :-).
> 
> > Unlike the now-oh-so-scary feature that was in existence for decades, that is only so scary
> > because of a "clever" idea to "cloud" host different customers on bare metal, without any
> > consideration to their security, this could affect real people not just oh-so-clever computer
> > farmers.
> 
> I don't believe you actually have a way to brick CPUs.
> 
> Yes, it is possible to brick some computers -- overwriting BIOS will
> do the trick, for example; doable from ring 0. There is more firmware
> that can be overwritten... That's old news. Worth mentioning on
> bugtraq, so manufacturer can fix it, but...
> 
> If you had something that worked directly on CPU, that would be news;
> and yes, there are fuses there, but I really doubt they can be
> manipulated by software. And I believe it would be news worth more
> than price of a CPU... Still not exactly dangerous. Usually data are
> worth more than hardware.
> 
> Ouch, and if it worked from ring 3... That would be newsworthy. That
> would be actually quite dangerous. OTOH... people did try to fuzz CPU
> instruction sets, so my bet is someone would have noticed.

You already mentioned the news part previously.

Early versions of the code would require disabling the OS by the delivery system to avoid 
interference.

Re: Bricked x86 CPU with software?

[Tim Mouraveiko]

> On Mon, 2018-01-08 at 11:08 -0800, Tim Mouraveiko wrote:
> > 
> > 
> > I think you missed one of my posts from last week. The code has
> > nothing to do with linux.
> 
> Like the 'f00f' bug in the Pentium days, there may well be a way that a
> kernel can *prevent* the code sequence from killing the machine.
> 

Obviously preventing execution of the code or interfering with it could be a possible solution.

F00F bug, good old days, consider it from a historical perspective.

A major fear of all manufacturers is warranty and recalls. Software technology companies 
successfully killed all warranty claims through disclaimers and patches. Chip manufacturers 
had a solution, too - the OEM computer manufacturers to whom they supply just parts and 
then the OEMs interface to the customers. But, that limits their profits. Now sell to mom-and-
pop shops and end-users directly - more sales and more profits. The complexity of the chips 
is surging. Sooner or later they will have a costly recall. Nothing to fear, the solution is simple 
- patch it in the field -engineers are saying it is dangerous. What if by accident other 
engineers discovers it? Wait a moment, this open source novelty offers an exciting 
opportunity - softly convince everyone to not waste time inventing - just copy it and follow 
our path. It works and marketing is happy too! Now marketing wants more products, but 
manufacturing says too expensive. Engineering to the rescue - all we need to do is enable 
and disable features to have a whole bunch of new part numbers. Problem solved! 

The memory on the processor is a low hanging fruit to increasing profitability.

They could make it harder to access it by having different protocols for different types of 
processors, but that costs more. 

Now this is an interesting question: is this a feature that opens access to just one type of 
processor or a bug that provides access to many?