Re: Bricked x86 CPU with software?

["Tim Mouraveiko" <tim.ml@ipcopper.com>]

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