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