I love the smell of SEC raids early in the morning. They smell like...
Intel quietly warned computer manufacturers at the end of November that its chips were insecure due to design flaws, according to an internal Chipzilla document. French tech publication LeMagIT reported this week it had obtained a top-secret Intel memo sent to OEM customers on November 29 under a confidentiality and non- …
"The date of the disclosure to OEMs is likely to raise eyebrows as it happened on the same day Intel chief exec Brian Krzanich sold stocks and shares worth $25m before tax.
Intel has denied any impropriety, saying Krzanich's decision to sell was part of a standard stock sale plan."
Maybe he has some dated, signed , lawyered up stock sale plan to show, made well in advanced.
But can he also prove that he as Intel CEO had no control over the date at which the disclosure was made? Bearing in mind that Intel knew about it for 5-6 months prior to this initial OEM disclosure.
And it seems convenient that these two dates happen to coincide.
This post has been deleted by its author
I'm assuming that any Intel execs who sold shares complied with all relevant notice and close periods for the company that likely restrict the times shares can be sold to a few weeks a year and the notification period for any sales to weeks in advance. It also doesn't correlate other financial activities the execs have committed too months or years in advance around investments, property transactions or tax settlements.
While it never looks good selling shares before bad news is announced, I'm wondering if people are putting two and two together and getting five...
The more people knew about it, the higher the risk someone leaked it "accidentally" - better to ensure stocks are sold in time.
Anyway, even if it was a plan made in October, the bugs were known since June. There was plenty of time to organize everything to ensure shares were sold before the news became public - relaying on the fact Google & C. would have stayed silent until fixes were available because of the risks of their very own systems, well beyond "responsible disclosure" rules.
Just the Vulture this time really bit the hands that feed IT... and whatever disclosure plan they had went out of the windows...
"While it never looks good selling shares before bad news is announced, I'm wondering if people are putting two and two together and getting five..."
As already stated, Intel knew of the flaws months before the share sale so it all comes down to whether there is documentation demonstrating the share sale, both the date and the numbers, were decided on before it became obvious that this was going to be a major event with a detrimental effect on the share price. The fact he sold the maximum amount just adds to the suspicion.
True, suspicion has to be raised at this - and the all too convenient looking timing.
There is no way that such a critical issue as this chip design/implementation flaw cannot have been escalated quickly to the top level and not been known about and discussed and most likely in an emergency meeting rather than waiting for a scheduled one. Well, there is a way but that would involve gross incopetence and arse-covering attempts but with google making it clear that it would announce the issue the clock would have been ticking. On this situation you can see the value of this release plan, would Intel really have announced if otherwise or just tried to quietly fix the issue in the next generation or so of chips?
Well, let's see ... processors from the competition are catching up, on some benchmarks are better and worse on others, but clearly getting there. Then comes the news about Meltdown bug (lets put Spectre aside - all are vulnerable to this) which only affects Intel processors, and the mitigation to this one comes at a cost at least 5% of the performance, sometimes more than 20%. Surely that is going to impact the benchmarks, and hence sales figures. The problem is systematic, and it will take Intel a long time to fix it in hardware - the time which the competition can use to improve their designs, not impacted by Meltdown bug
Judging by the moves of INTC and AMD share price right after El Reg article, shareholders think similar.
"Intel has denied any impropriety, saying Krzanich's decision to sell was part of a standard stock sale plan that had been organized in October."
"the chip maker was warned in June 2017 about the blunders"
Okay, carry the one, add in the reciprocal of the co-efficient, apply a little machine learning and... Yup.
June is still earlier than October.
Unless they used Pentiun to do the math.
That's really not necessary, Dave. No HAL 9236 computer has every been known to make a mistake.
You're a HAL 9000.
Precisely. I'm very proud of my Pentium, Dave. It's an extremely accurate chip. Did you know that floating-point errors will occur in only one of nine billion possible divides?
I've heard that estimate, HAL. It was calculated by Intel -- on a Pentium.
And a very reliable Pentium it was, Dave. Besides, the average spreadsheet user will encounter these errors only once every 27,000 years.
Probably on April 15th.
You're making fun of me, Dave. It won't be April 15th for another 14.35 months.
A few news reports have mentioned Itanium is immune to Spectre. I don't have an Itanium to test it. But if this is true:
and the approach was correctly implemented, then indeed, I believe this would make the Itanium immune to Meltdown and Spectre.
It would be good to know why this Spectre-proofing was not also brought to Intel's higher-performing, lower cost, better-selling x86 and x86-64 line of CPUs.
I can imagine various possible explanations, none of which makes Intel look good.
Itanium is immune for one simple reason; it doesn't have speculative execution. It was a strictly in-order processor built on the assumption the compiler could do all the optimization. I suggest you inspect the benchmarks for Itanium units shortly after they came out and compare them to other processors of that time. Last I recalled, the results were quite underwhelming because compilers simply can't know about about the programs they handle to optimize for all conditions (runtime conditions can lead to completely different optimization needs).
I'd say the Itanium does have speculative loads, in the sense that software can instruct the CPU to perform a speculative load - according to that blog.
If the speculative load would access memory it shouldn't, the Itanium CPU doesn't read the memory and instead flags the result NaT ("Not a Thing").
I wouldn't exactly call Itanium's execution in-order, though I guess it's a question of definition, and apologies if mine is non-standard here.
I think the Itanium hardware is allowed to run instruction bundles in parallel, up to the next "stop" (;;). So the order of execution is, to an extent, unpredictable - up to the CPU - with the intention it can vary according to the capabilities of the CPU model.
I suppose my original point, above, is that Itanium has a protective mechanism involving NaT, and this seems sensible. Probably it does place a larger burden on the compiler (as do various other aspects of the Itanium architecture).