Elementy konstrukcyjne układów półprzewodnikowych, które składają się z setek tysięcy lub milionów tranzystorów, nigdy nie działają tak, jak przewidzieli ich twórcy. Od słynnego błędu FDIV w procesorze Pentium w 1995 roku Intel publikuje dość obszerne aktualizacje specyfikacji (Specification Updates) zawierające wykazy błędów w układach. Również AMD zdradza informacje na temat usterek w CPU nie tylko wybranym inżynierom, ale także publicznie w formie tzw. Revision Guides.
Wiele błędów w produkowanych ostatnio wersjach procesorów pojawia się tylko w określonych warunkach lub też można ich uniknąć dzięki tzw. aktualizacjom mikrokodu albo obejściom w BIOS-ie, firmwarze, systemie operacyjnym lub oprogramowaniu. Listy błędów są zatem interesujące przede wszystkim dla twórców systemów operacyjnych, kompilatorów, firmware'u czy też BIOS-u, a także dla programistów aplikacji niskiego poziomu. Większość laików z uwagi na brak wiedzy na temat (skompilowanego) kodu oprogramowania, które działa na ich systemach, nie jest w stanie ocenić wagi błędów w CPU.
Mimo publikowania dokumentów z wykazami licznych błędów w procesorach, AMD i Intel nie przestają prowadzić dość ostrych dyskusji na temat niezawodności, bezpieczeństwa i zaufania do ich produktów. Wielu innych producentów procesorów unika tego rodzaju krytyki, udostępniając wykazy błędów jedynie niewielkiemu kręgowi klientów i programistów, a także zawierając umowy o dotrzymaniu tajemnicy, które skutecznie blokują przedostawanie się takich informacji do wiadomości publicznej.
Wprawdzie nie wiadomo, jak szybko dokumentowane są ewentualne błędy w procesorach x86 AMD i Intela, a także czy publikowane wykazy są pełne, to jednak w przypadku wielu szeroko rozpowszechnionych procesorów brakuje jakiejkolwiek publicznej dokumentacji błędów. Często nie ma też nawet danych technicznych z podstawowymi informacjami na temat napięcia roboczego, poboru mocy, częstotliwości taktowania, limitów temperatur czy wersji produktu. Tym samym producenci unikają nie tylko dyskusji na temat układów, ale także prawnych zobowiązań do dostarczania towaru o określonych właściwościach. Z drugiej strony trzeba zauważyć, że np. procesory przeznaczone dla urządzeń osadzonych (typu embedded) często są wytwarzane w wersjach dostosowanych do potrzeb konkretnych klientów, w związku z czym jedynie producent gotowego urządzenia jest w stanie dostarczyć pełną dokumentację. Jako przykłady publikowania "dziurawych”.
dokumentacji technicznych mogą posłużyć specyfikacje układów graficznych (GPU) AMD i Nvidii, a także procesorów x86 firmy VIA Technologies i układów Vortex86. To samo dotyczy niektórych (ale nie wszystkich) procesorów serwerowych IBM i Suna, a także wielu procesorów embedded, w tym licznych układów typu SoC (System-on-Chip) z rdzeniami ARM lub MIPS. Nawet jeśli wydawana jest obszerna dokumentacja – jak to jest w przypadku wspomnianych rdzeni ARM lub MIPS oraz Freescale, NXP czy Texas Instruments (TI), to klienci końcowi nie są w stanie stwierdzić, czy dotyczy ona rdzeni wbudowanych w ich urządzenia końcowe. Wiele błędów występuje tylko w określonych wersjach chipów (steppingach), które w procesorach x86 są dość łatwe do rozszyfrowania, ale np. w przypadku układów osadzonych już nie. Szósty na świecie producent półprzewodników – Qualcomm, którego układy typu SoC z rdzeniami ARM są stosowane w licznych modelach smartfonów, nie dzieli się prawie w ogóle szczegółowymi informacjami. Dla układów Snapdragon z
kompatybilnymi z ARMv7 (Cortex A8/9), ale opracowanymi samodzielnie rdzeniami Scorpion nie ma nawet podstawowych specyfikacji technicznych. Z kolei Marvell umożliwia zarejestrowanym programistom dostęp do tzw. ekstranetu, ale wymaga przy tym podpisania umowy o zachowaniu poufności (non-disclosure agreement). Wykazów błędów dotyczących układów SoC z rdzeniami ARM nie publikuje też Samsung.
Ponieważ wiele rdzeni procesorów osadzonych wykazuje znacznie prostszą budowę od współczesnych rdzeni x86, a przy identycznej wielkości struktury produkcyjnej zajmują jedynie ułamek powierzchni tych ostatnich, błędy w ich jednostkach obliczeniowych powinny występować znacznie rzadziej. Z drugiej strony, dokupowane jako bloki funkcjonalne rdzenie są modyfikowane przez różnych producentów i wytwarzane w różnych procesach produkcyjnych. Wygląda na to, że producenci kompletnych układów typu SoC nie mogą ze swojej strony publikować poufnych informacji na temat wykorzystywanych rdzeni IP. Przykładowo, w wykazie błędów w chipach OMAP3 (.pdf) ich producent TI informuje, że usterki rdzenia graficznego PowerVR SGX mogą być dokumentowane wyłącznie przez jego producenta –. Imagination Technologies: "SGX is considered as a black box for most users; therefore, no detailed information about SGX bugs is provided in this document". W tym samym dokumencie TI
(podobnie jak Freescale) wskazuje też na komunikat "Cortex-A8 (AT400/AT401) Errata Notice”, który najwyraźniej nie został jeszcze upubliczniony przez ARM. Poza tym TI samodzielnie ujawnia informacje o kilku błędach w rdzeniu Cortex A8.
Choć wiele spośród błędów w procesorach wywołują "jedynie” awarie programów lub usterki w działaniu funkcji, niektóre z nich są określane jako krytyczne pod względem bezpieczeństwa, ponieważ umożliwiają szkodliwemu kodowi dostęp do danych innych działających aplikacji, które rezydują np. w pamięci RAM lub podręcznej (cache). Nie wiadomo jednak, na ile tego rodzaju teoretycznie możliwe ataki mogą być istotne w porównaniu ze znacznie łatwiejszymi atakami przeprowadzanymi za pomocą trojanów, stron wykorzystujących phishing czy też szkodliwych programów. Tak więc różnorodność wielu implementacji rdzeni ARM, które w dodatku pracują pod kontrolą różnych systemów operacyjnych, zmniejsza ich atrakcyjność z punktu widzenia programistów malware'u. Może się to jednak zmienić, jeśli sporą popularność zdobędą poszczególne i w dalekim stopniu identyczne platformy. W tym kontekście należy pamiętać, że rocznie sprzedawanych jest około czterokrotnie więcej telefonów komórkowych i smartfonów, niż pecetów.