Intel ramt af stort læk af interne og fortrolige dokumenter

Illustration: Intel
Intel har fået lækket 20 GB data, der normalt bruges af samarbejdspartnere og kunder.

Intel efterforsker et læk af 20 GB kildekode og proprietær data, der med stor sandsynlighed kommer fra et databrud tidligere i år.

Dataene er ifølge Arstechnica stadig tilgængelige på BitTorrent-hjemmesider.

Læs også: Sikkerhedsfirma finder 4.000 åbne AWS-buckets med følsom data

Dataene kommer ifølge en talsperson tilsyneladende fra Intels designcenter og bliver typisk givet til samarbejdspartnere, kunder og andre, der bliver registreret for at få adgang. Det er informationer, der typisk bruges, når der skal designes eksempelvis motherboards og BIOS

Læs også: Stort Nintendo-læk giver gamere unikt indblik i 90'er klassikere

Delt på Twitter

Information om dataene blev delt på Twitter af brugeren Tillie 1312 Kottmann, der i et opslag skrev, at de fleste af informationerne ikke før har været delt og bliver klassificeret som fortrolige.

Samtidig kaldes lækket for ‘exconfidential Lake’, hvor ’Lake’ refererer til Intels eget interne navn for virksomhedens 10 nanometer chip-platform.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#4 Jens D Madsen

Tja der står jo ikke noget i manualen om præcist hvordan 'Intel management engine' virker og hvad den helt præcist gør

Det, som er nødvendigt, for at lave bios og operativsystem effektivt, bør altid stå i manualen. Der behøver ikke at stå eksakt hvordan det fungerer, andet end fra software synspunktet. Det, som ikke står nævnt, har man mulighed for at ændre i fremtidige udgaver.

  • 0
  • 4
#5 Jens D Madsen

@Jens: Det gør det sikkert også, men nok mere spredt. Jeg vil dog tro, at det væsentligste kan udtrykkes på mindre end 20 GB.

Det undrer mig under alle omstændigheder, at Intel betragter det som hemmelig/fortrolig information.

Alene denne omstændighed at Intel søger at hemmeligholde vigtige informationer, og kun gøre dem tilgængelige for en lukket gruppe - et softwarekartel - er en god årsag til at vælge ARM i stedet.

Det er OK at Intel hemmeligholder selve deres chips design - men at hemmeligholde vigtige informationer, der er nødvendige at kende, for at kunne lave effektivt software, og kun tillade adgang til disse informationer for få udvalgte virksomheder, er efter min opfattelse ikke acceptabelt.

  • 0
  • 3
#6 Michael Cederberg

Manual Jeg troede, at alt som var nødvendigt at vide, stod i CPU'ens manual. Er virkeligt nødvendigt, at have inside-viden, for at designe bios eller operativsystem?

Det var dengang. De sidste 10-15 år har der været meget som ikke er dokumenteret.

I "gamle dage" var der dokumentation der fortalte at en Intel 8086 CPU efter reset startede execution på adresse F000:FFF0 (som jeg husker det). Her lå BIOS som var lavet af et andet firma. BIOS ville efter en række indledede trin loade den første sektor på boot disken og eksekvere koden i bootsektoren som så loadede OS. Herefter var BIOS ude af verden, med mindre den specifikt blev kaldt (eller der var interrupts, men disse kunne redirigeres efter eget valg).

Fast forward til i dag. I dag fortsætter "BIOS" med at køre bagom ryggen på OS. BIOS fortsætter med at køre på i en protected verden som OS ikke kan manipulere og til en hvis grad ikke se. På mange måder er det som om OS kører på en virtuel maskine styret af BIOS.

Fx. har Intel brugt denne teknologi til at implementere TPM (Trusted Protection Module). Hvor oprindeligt TPM var en separat chip der fx. indeholdte crypto-keys, så er det nu i mange tilfælde blot en stump kode der kører udenfor OS og kan tilgå ressourcer som OS ikke har adgang til.

Alt dette er kun i ringe grad dokumenteret.

Note: Det hedder ikke længere BIOS. Der er mange moduler og det hedder noget forskelligt på Intel og AMT.

  • 6
  • 0
#8 Sune Marcher

Fast forward til i dag. I dag fortsætter "BIOS" med at køre bagom ryggen på OS. BIOS fortsætter med at køre på i en protected verden som OS ikke kan manipulere og til en hvis grad ikke se. På mange måder er det som om OS kører på en virtuel maskine styret af BIOS.

Det har været sådan længe – så vidt jeg husker blev SMM (Systems Management Mode) introduceret med 80486. Dengang kunne man betragte det som Ring -1, med introduktion af Hypervisors som Ring -1 er SMM at betragte som Ring -2.

Og så er der Management Engine, der startede som ARC eller SPARC, men på moderne bundkort er en separat x86 processor...

Ugh :)

  • 2
  • 0
#9 Michael Cederberg

Håber det er bedre med ARM.

Så lad ARM være fremtiden.

Der er mulighed for pille ved det her. På Intel findes noget der hedder "High Assurance Program" og en HAP-bit der kan sættes som disabler noget af skidtet. Desværre er det udokumenteret og Intel siger at de ikke kan dokumentere dette fordi det kun er testet til specifikke løsninger og ikke generelt.

Spændende kan amerikanske myndigheder som de eneste købe udstyr hvor skidtet er slået fra. Man kan så overveje om NSA har givet Intel/AMD et vink med nogle blå briller om det her. Læg oveni at DRM også udnytter disse ting.

Alt sammen noget som gør at jeg forestiller mig ARM i samme situation ... bare lavet lidt anderledes. Men jeg ved det ikke. Læg så oveni at du heller ikke kan få dokumentation af de nyeste Wifi-chipsets eller grafik chips, men i stedet må bruge en binær blob fra producenten. Der sker meget i din computer som du ikke kan få kontrol over.

Det værste ved det her er næsten at det betyder at man ikke selv kan styre levetiden for moderne computere. Når leverandøren holder op med at supportere skidtet, så er det "usikkert". Du kan ikke selv lave ny software der fikser problemer selvom du bruger et open source OS.

Og så er der Management Engine, der startede som ARC eller SPARC, men på moderne bundkort er en separat x86 processor...

Som jeg forstår det er det blot kode der loades ved startup. Der er ingen separat hardware til ME. Men nogle af funktionerne kan lægges ud i separat hardware men der sker ikke i consumer hardware.

  • 4
  • 1
#10 Sune Marcher

Som jeg forstår det er det blot kode der loades ved startup. Der er ingen separat hardware til ME. Men nogle af funktionerne kan lægges ud i separat hardware men der sker ikke i consumer hardware.

Jeg ved ikke om det er ændret i de aller-allernyeste Intel specs, tidligere (som i sene 201x'ere) var det separat CPU, med komfortabel bus-adgang, og egen MAC-adresse. Reverse engineering af (den Minix-baserede) firmware begyndte at tage fart efter ME'en skiftede til x86.

SMM er "bare" kode der loades af BIOS (eller UEFI, I guess?), og som OS'et ikke har nogen mulighed for at påvirke – OS'et kan ikke slå det fra, og SMM køres i separat address-space som selv en hypervisor ikke kan pille ved.

  • 2
  • 0
#11 Morten Andersen

Enig - og SMM er stadigvæk veldokumenteret. Men kan i praksis kun bruges af BIOS vendor (eller BIOS hackere), idet BIOS'en er først til faddet, og sætter en bit der låser området.

Som Michael Cederberg efterlyser er CPU'ens starttilstand stadigvæk veldokumenteret i de nyeste manualer hvad der foregår når CPU'en vågner - herunder første adresse der eksekveres fra o.s.v. Også hvordan virtualisering m.m. virker.

Men er alt så dokumenteret? Nej - især initialisering af chipsæt og RAM-controller er mig bekendt ikke længere dokumenteret. Og det er ganske kompliceret, low-level og CPU/chipsæt specifikt (bemærk at north-bridgen jo i praksis er flyttet ind i CPU'en) hvad der foregår her, og det involverer ofte et mix af vejledninger, binære blobs, fejlfixes etc. En komplicerende faktor er f.eks. at RAM ikke er tilgængelig for CPU'en under processen - i praksis udnyttes CPU'ens cache som "RAM" under denne proces.

Nogle af informationerne kan helt eller delvist indhentes lovligt fra offentlige kilder (herunder f.eks. Coreboot projektet) men det der er lækket her er nok mere den officielle pakke henvist til BIOS-leverandører og som normalt ikke er offentligt tilgængelige.

Ting som Intel ME og den lang række af faciliteter der er introduceret i chipsættet (herunder sikkerhedsfunktioner - key stores etc.) er mig bekendt heller ikke offentligt dokumenteret og kan derfor også være "konfidentielle ting" der er med i den pakkke.

Ud fra de mange år jeg har fulgt Intels CPU'er vil jeg overordnet sige, at det der skal til for at skrive et operativsystem er offentligt tilgængeligt mens det at skrive en BIOS ikke er. Måske fair nok - og bedre end tidligere.

Hvem husker ikke "Appendix H" som blev taget ud af den officielle manuel og som beskrev en række nye features i CPU'en og som kun bl.a. IBM og Microsoft fik adgang til og brugte i OS/2, Windows o.s.v. De er i dag dokumenterede og det er mange år siden jeg har hørt om at operativsystemet har brugt "hemmelige" features.

  • 2
  • 0
#12 Michael Cederberg

Ud fra de mange år jeg har fulgt Intels CPU'er vil jeg overordnet sige, at det der skal til for at skrive et operativsystem er offentligt tilgængeligt mens det at skrive en BIOS ikke er. Måske fair nok - og bedre end tidligere.

Et sted i en kasse har jeg IBM PC Technical Reference manual i 1981. I den er der en komplet listning af BIOS. Der er også en beskrivelse af samtlige komponenter i computeren. Der er faktisk nok information til at man kunne bygge sig en "klon" som rent software mæssigt ikke ville adskille sig fra IBM's original med BIOS etc. BIOS var dog copyrighted og af samme grund var der en langvarig process omkring de første klon-BIOS'er.

Jeg mener det er galt at vi er endt der hvor vi er. Ikke fordi jeg ikke under Intel deres hemmeligheder. Men fordi begrænsningerne i hvad vi får at vide reelt dømmer hardware til genbrugspladsen længe inden hardware er holdt op med at virke. Uanset hvilken open source platform vi måtte vælge.

Det kan sikkert forsvares når det handler om IoT devices, men en computer som er købt som en "general purpose computer" hvor jeg selv kan bestemme hvilken software der skal køre på den ... der er det galt.

  • 1
  • 0
#13 Michael Cederberg

Her er de sidste linjer fra IBM's originale BIOS:

                     5928  
                     5929 ; ----------­----------------------­  
                     5930 ; POWER ON RESET VECTOR  
                     5931 ;---------------------------------­  
FFFF                 5932 VECTOR SEGMENT AT 0FFFFH  
                     5933  
                     5934 ; -----­ POWER ON RESET  
                     5935  
0000 EA580000FO    R 5936 JMP RESET  
                     5937  
0005 30342F32342F38  5938 DB  '04/24/81'  ; RELEASE MARKER  
     31  
                     5939 VECTOR ENDS  
                     5940 END 
  • 0
  • 0
#14 Morten Andersen

Den information er som sagt stadigvæk offentlig:

https://software.intel.com/content/dam/develop/public/us/en/documents/32...

Afsnit: 9.1.1 Processor State After Reset

Ved powerup er CS registret loaded med:

Selector = F000H Base = FFFF0000H Limit = FFFFH AR = Present, R/W, Accessed

Og IP: 0000FFF0H

Dermed vil CPU'en tilgå adressen (FFFF0000h + 0000FFF0h =FFFFFFF0h ) for den første instruktion. Det er så bundkort komponenter (typisk chipsættet - som her særskilt manualer/sheets) der er ansvarlig for at BIOS'en udstilles her (typisk er den også udstillet på lavere adresser, E0000h-FFFFFh så vidt jeg husker (for legacy BIOS vedkommende, UEFI er en anden sag), men typisk er det shadowet i den øverste del af lageret, således at de sidste 16 bytes af BIOS-imaget ender med at ligger på FFFFFFF0h, og her ligger så en JMP instruktion der hopper det rigtige sted hen.

I dag er BIOS'en ikke open source men det mener jeg heller ikke er nødvendigt. Det er sådan set vigtigere dokumentationen for grænsefladen operativsystemet skal benytte tilgængelig. I praksis er detikke muligt at lave en BIOS til et givent bundkort man har købt, da det afhænger af præcis hvordan det pågældende bundkort er wired up (og ikke kun af hvordan f.eks. CPU'en fungerer) og det er vel heller ikke ønskeligt - BIOS rolle er jo netop at abstrahere det bundkort-specifikke over til et generelt software interface som forskellige operativsystemer kan bruge. Ovestående information omkring boot-processen er således primært brugbart hvis man ønsker at lave eget bundkort og proppe en Intel CPU ind og således står og skal skrive en BIOS til systemet.

For en forfatter af et operativsystem er det vigtige hverken sourcen til BIOS eller information om hvordan BIOS initialiserer systemet, men derimod grænsefladen mellem operativsystem og BIOS. I gamle dage var den "vigtige" del således ting som API'er til BIOS-funktioner (int 13h, int 10h o.s.v.) som abstraherede ting som disk-adgang og skærmadgang. DOS bruger faktisk primært disse offentlige interfaces og interagerer sjældent (aldrig?) direkte med hardware. I dag er BIOS-grænsefladen mere udgjort af UEFI og ACPI. Det er stadigvæk primært initialisering hvor der er heftig interaktion, idet operativsystemet typisk overtager kontrollen med det meste hardware via drivere. Power management er dog en vigtig undtagelse, idet operativsystemet stadigvæk baserer sig på ACPI-tabller og kode til at "skrue op og ned" for ydelse m.m.. Men det giver jo god mening for det er jo netop en ting der er meget specifik for det enkelte bundkort, laptop etc. hvordan dette skal foregå så frem for at specificere low-level detaljer om hvordan man tænder og slukker for blæsere på en standardiseret måde (sker typisk via proprietære controllere på boarded), så specificerer ACPI en grænseflade hvorved operativsystemet kan aktivere rutiner i BIOS'en som så udfører de ønskede funktioner (d.v.s. sender de proprietære kommandoer til controlleren). Derudover benytter BIOS'en SMM-rutiner til at modtage interrupts og information fra de pågældende conrollere. SMM bruges dog også til andre formål, afhængigt af producent.

For mig er det afgørende at dokumentationen der er tilgængelige for OSS operativsystemer er ligeså godt som det f.eks. Microsoft har til rådighed for at skrive Windows, og der mener jeg status quo er god.

  • 1
  • 0
Log ind eller Opret konto for at kommentere