New flaw in Intel chips lets attackers slip their own data into secure enclave

Re:New flaw in Intel chips lets attackers slip their own dat... by alex_free on Tuesday March 10, 2020 @02:20PM (#22538002)

>Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the issue to Intel.

Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.

[ Parent | on HN ]

Re:New flaw in Intel chips lets attackers slip their own dat... by hermitdev on Tuesday March 10, 2020 @03:21PM (#22538640)

I spent an entire summer as an intern, constantly on the phone with IBM support trying to get DB2 Connect to work in a Windows cluster only to be told "this is not a supported configuration" despite it being clearly supported in the documentation. Gave up. Years later, ran into my former boss randomly (at a liquor store of all places) and he mentioned they were finally able to get it to work.

Another confounding one was where I was trying to bulk copy some data to Sybase using Python. Started getting some really strange DB errors. Couldn't figure it out for a while. Turns out, it was a bug in the DB module and it was using uninitialized memory in certain conditions. Was a 1-line fix, but took about 6 weeks to find.

Yet another one was when I was working on porting my C++ services from 32 to 64-bit. Sockets were timing out immediately sometimes. Couldn't reproduce in the debugger. Was a bug in a 3rd party framework. It was improperly using the rtdsc instruction in some inline ASM. Worked fine on 32-bit, but the register layout was different on 64-bit. So, it was effectively reading a garbage upper 32-bits for the high-res timer. Only found that one because I noticed in my logs that my timers were reporting that some operations had taken >200 years. I forget how long it took to track that one down, but it was months of off and on hunting.

I've also hit internal compiler errors. The one I remember was that an anonymous namespace at global scope would cause an ICE. I was about to file a bug report once I'd a minimal reproduction, but it'd already been reported and fixed.

[ Parent | on HN ]

Re:New flaw in Intel chips lets attackers slip their own dat... by sarah180 on Tuesday March 10, 2020 @02:31PM (#22538104)

I had a similar experience when doing my first serious work in a compiled language. I found and reported a compiler bug in double-precision division (in a commercial C compiler). It took me years to stop blaming the compiler for my bugs.

[ Parent | on HN ]

Re:New flaw in Intel chips lets attackers slip their own dat... by snovv_crash on Tuesday March 10, 2020 @06:02PM (#22540273)

I had the same, an embedded system with GCC 3.something. Managed to get a toolchain together with 4.something and suddenly our uptime and random corruption issues disappeared.

[ Parent | on HN ]

Re:New flaw in Intel chips lets attackers slip their own dat... by 2J0 on Tuesday March 10, 2020 @02:30PM (#22538091)

My memory is hazy but I'm sure I recall the problem during summer 94, but I stand corrected. Was there any normal way for the information to reach us? That was the year intel took down Vlsd Pentkovskis profile page.. I loved to tease everyone that Pentium was named tribute to him...

Edit:typo fixed for pentium

[ Parent | on HN ]