CISC & RIS[CK]

For første gang har Intel direkte sagt at der er et sikkerhedsproblem i deres micrcode.

Intel er generelt ikke særlig informativ om deres microcode updates, eller hvad de gør godt for, men det seneste update indeholder tilsyneladende dette fix:

  1. It fixes a critical erratum, classified by Intel as a security issue, that affects any server running 32-bit VMs in PAE mode.
    Erratum AAK167/BT248: "If a logical processor has EPT (Extended Page Tables) enabled, is using 32-bit PAE paging, and accesses the virtual-APIC page then a complex sequence of internal processor micro-architectural events may cause an incorrect address translation or machine check on either logical processor. This erratum may result in unexpected faults, an uncorrectable TLB error logged in IA32_MCI_STATUS.MCACOD bits [15:0], a guest or hypervisor crash, or other unpredictable system behavior"

("Unpredictable system behaviour" er et gammelt IBM-opfundet kodeord for "Vi bliver sagsøgt hvis vi siger mere")

Rygterne er allerede begyndt at vælte rundt om det er en NSA backdoor osv.

I de første computere var mikrokoden ikke modificerbar, f.eks er den på GIER lavet ved at kobbertråde render igennem eller udenom ferritringe:

Illustration: Privatfoto

Senere fandt IBM ud af at det var nemmere rette fejl hvis man kunne hente den på et anstændigt datamedie og det har de gjort lige siden på deres mainframes.

Mikrokode er et fænomen der i stort omfang hører CISC arkitektur til.

Ikke at man ikke kan lave CISC i "random logic", Zilogs Z8000 var et eksempel på det modsatte, men også et glimrende financielt eksempel på hvorfor det ikke giver mening: Det er dyrt at debugge silicium.

RISC arkitekturer er derimod ofte, men ikke altid, mikrokodefri, af den simple årsag at mikrokode i bund og grund tager mere tid end "random logic".

(For de nørdede: Mikrokodemanualen til RC3803)

Intels "microcode updates" opstod efter den berømte FDIV pentium fejl og det har sparet Intel for mange CPU ombytninger siden.

Iflg det der er offentliggjort har Intel gjort sig umage for at undgå at andre kan hacke deres mikrokode, den er efter sigende både krypteret og signeret og der er noget der tyder på at det er rigtigt.

Der er mange ting vi ikke ved om Intels microcode updates, f.eks helt basalt om vi kan stole på Intels gode hensigter ?

I det nuværende miljø, "post-Snowden" er svaret et rungende "nej", indtil det modsatte bliver bevist.

Men kan vi selv bevise det ?

Det første vi kan kigge på, er størrelsen.

Med typisk 4Kbyte er det ret begrænset hvad et microcode update kan indeholde, specielt hvis der også skal være plads til en kryptografisk signatur.

Det udelukker naturligvis ikke at mikrokoden med et enkelt bit enabler en NSA_BACKDOOR_PROCESSOR, men denne skal i givet fald allerede have sit program på chippen fra fabrikken og dette program skal være i stand til at navigere alle mulige potientielle I/O devices for at få kontakt til omverdenen, eller alternativt, kunne genkende videnskabelige beregninger af atomvåben og sabotere dem.

Det første er mindre svært end man tror, fordi rigtig mange CPU'er kommer med højintegrerede chipsets, inklusive ethernet osv.

Men hvis man skulle lave en silicium-baseret bagdør, ville det faktisk være nemmere at gøre det i chipsettet eller ethernet chippen, hvor man langt nemmere kan få adgang til alt netværkstrafikken, end man kan på CPU'en, hvor man først skal gennemskue hvilket operativsystem det er og derefter rode og rage i netværksstakken.

Tag en småkage, hvis du kigger skeptisk på "Wake-On-LAN" eller de mere og mere obskure "remote management" settings i din BIOS.

Tag to hvis du indser at du kun giver en anbefaling desangående.

Moderne Ethernet chips er komplexe, Intels i82599 har et "datablad" på ca. 1000 sider og det er stadig utroligt sparsomt med oplysninger, man er oftest nødt til at læse Intels kodeexempler for at gennemskue hvad der foregår.

Derfor er min personlige konklusion at Intels Microcode updates ikke udgør en trussel: Det er formodentlig præcis hvad det siger på pakken: Mikrocode patches.

Men det overordnede problem, om Intel eller for den sags skyld AMD platforme er til at stole på, eller om der ligger små spioner gemt i hardwaren, er overhovedet ikke afklaret og kan ikke realistisk afklares, med mindre man sætter sig og reverse-engineer hver enkelt chip optisk, med noget skrap kemi.

Tilbage i 1980erne rasede der en sand ordkrig imellem fortalere for RISC og CISC, hvad var bedst, hvad var hurtigst osv.

Idag er der reelt set ikke nogen RISC processorer på markedet, alle arkitekturer der har overlevet er blevet CISC: Siliciumlogik ikke bliver hurtigere og derfor er komplexitet den eneste måde at viderudvikle chippen til højere performance.

ARMs "thumb2" instruktionssæt er et godt eksempel, det er en prostituering af ARM's flotte RISC design.

Der burde være en "market opportunity" lige nu, for et RISC design (eller CISC uden skrivbar mikrokode) der er helt åbent, helt ned til maskeniveau og som derfor med relativt simple midler kan verificeres til at være NSA-frit.

Ideen er hermed givet videre.

phk

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Fischer

Endnu engang er vi vel tilbage ved Thompson: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf. I kombination med den grad af kompleksitet vores infrastruktur er nået op på, så er vi vel der hvor det reelt ikke er muligt at have en system man for alvor kan stole på, i Thompsons forstand.

Allerede for 30 år siden bemærkede Hoare at "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult". Hans observation om korrekthed er lige så relevant for sikkerhed. Hoare er givet rædselsslagen over hvad der siden er sket.

  • 0
  • 0
Poul-Henning Kamp Blogger

Hvad er leverandør-forskrifterne for robuste NASA computere?

NASA har mig bekendt frie hænder nu om dage, de er en ren videnskabelig organisation og alle "dual-use" restriktionerne fra rumfærgens dage er mig bekendt borte.

Hvis du med NASA mener USAs "Security-industrial-complex" så har de deres helt egen halvlederfabrik, så de kan være sikre på hvad der er i deres chips: http://www.sandia.gov/mstc/trusted/microsystems.html

  • 0
  • 0
Jacob Nordfalk

Har lige hentet den fra Intels hjemmeside (https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23082) og kigget i filen:

/ .No reverse engineering, decompilation, or disassembly of this software is
/ permitted.

Ved hver opstart skal CPU'en patches med filen.

Jeg ved godt det sikkert ikke kommer som en overraskelse for mange herinde, men jeg er altså virkelig ikke særlig tryg ved at vi intet som helst ved om hvad Intel siger vi skal proppe i vore CPU'er.

Intel og AMD er amerikanske og ARM er britisk.... det vil sige at der faktisk ikke findes én eneste CPU-producent som er udenfor amerikansk rækkevidde?

Det burde være lige så elller endnu mere foruroligende for f.eks. EU, som at der ikke er indsigt i Windows' kildekode.

  • 7
  • 0
Jacob Pind

Er jo stadigvæk Sparc og Mips
Fujutsu produceret deres egne sparcs, ellers fra samme del af verden finder du Loongson cpuere fra kina som er mips64 eller Shenwei SW1600 som er inspiret af Alpha.

  • 0
  • 0
Torben Mogensen Blogger

Der har aldrig været en klar og entydig definition af RISC og CISC begreberne, det har altid væren en kontinuert skala, hvor en instruktionssætsarkitekturer (ISA) ligger et eller andet sted på en skala mellem ekstrem RISC og ekstrem CISC. Generelt har man haft et antal indikatorer, der var RISCede og CISCede, og hvis en processor havde mange flere af den ene slags end den anden betragtede man den som RISC eller CISC. Men der har altid været nogen, der lå hen mod midten. De typisk brugte indikatorer er/var:

RISC: fast instruktionslængde, ingen komplekse addresseringsformer, ingen dobbelte indirections, aritmetik er register-til-register, højest et TLB lookup per instruktion, mange registre, få forskellige instruktionsformater, hver instruktion gør kun en ting.

CISC: Negationerne af de ovenstående.

Derudover skelnede nogle også mellem, om implementeringen brugte mikrokode eller ej eller om instruktioner kunne gennemføres på en clockcyklus, men da det er egenskaber ved implementeringen og ikke instruktionssættet som sådan, er det ikke gode indikator.

ARM (i sit oprindelige 32-bit instruktionssæt) er generelt betragtet som RISC, men fejler flere af indikatorerne: Der er komplekse adresseringsformer, der er "kun" 15 registre (idet R15 er program counter), nogle instruktioner gør flere ting (f.eks. betingelse, shift og addition) og der er forholdsvis mange forskellige instruktionsformater. Det er rigtigt, at Thumb2 fejler yderligere en indikator (fast instruktionslængde), men det bringer den kun lidt tættere på CISC, da der kun er to forskellige størrelser.

Den oprindelige 8086 var til gengæld i den RISCede ende af CISC spektret idet der ikke var dobbelte indirections eller mange instruktionsformater og kun en af parametrene til aritmetik kunne ligge i lageret. x86 er rykket langt mere over mod CISC i senere generationer, specielt er antallet af instruktionsformater (og længder) øget voldsomt. Men (hvis jeg husker rigtigt) er der stadig ingen dobbelte indirections eller aritmetik, hvor mere end en parameter ligger i lageret.

Så x86 er stadig langt mere CISC end ARM, men begge har rykket sig i samme retning. Itanium var et forsøg på at bruge nogle af principperne fra RISC, men resultatet blev alt for kompliceret, hvilket efter min mening er en væsentlig årsag til dens manglende succes. ARMs 64-bit instruktionssæt (http://nominolo.blogspot.dk/2012/07/arms-new-64-bit-instruction-set.html) er til gengæld rykket længere over i RISC enden af spektret og ligner mere MIPS og Alpha end den oprindelige ARM.

  • 4
  • 0
Poul-Henning Kamp Blogger

Ja, jeg erindrer en masse Kandestøbere der stod med digitus magistrans og holdt fort om hvad der var RISC og hvad der var CISC :-)

En af de mere interessante "rageknive" er interrupt latency: Hvis du ikke har ordentlig lav interrupt-latency, er du tydeligvic CISC, uanset hvordan dine instruktioner er strikket sammen eller om du bruger mikrokode eller ej.

Min personlige delelinie er om instruktionssætte kan opsummeres på et enkelt stykke A4 eller ej.

Det er interessant og bekymrende at alle CPU typer med nogen grad af kommerciel success, bliver mere og mere CISC som tiden går.

  • 1
  • 0
Mikkel Lauritsen

Det er herligt med lidt nørderi her :-)

Det er interessant og bekymrende at alle CPU typer med nogen grad af kommerciel success, bliver mere og mere CISC som tiden går.

Det er nok en naturlig konsekvens af CPU'en bliver så meget hurtigere end maskinens hukommelse.

I "gamle" dage, hvor CPU'erne var relativt simple (ingen out-of-order og den slags) og en CPU-clockcycle var ca. lige så lang som rammens accesstid, var det hensigtsmæssigt at have instruktioner, som var meget ortogonale (og derfor lette at dekode) men som også fylder lidt mere. I dag er situationen lige omvendt - det gælder om at få instruktionerne til at fylde så lidt som muligt, fordi CPU'en ellers bare skal vente på hukommelsen, og så kaster man flere transistorer efter dekodningen. En relateret fordel er selvfølgelig også, at små instruktioner giver mindre pres på cachen.

Faktisk er det vel lidt a la Huffman-kodning; man vil gerne have, at de hyppigst brugte instruktioner er meget små.

Det er også en medvirkende årsag til den ovenfor nævnte Itaniums mangel på succes. Dens instruktionsformat pakker SVJH tre instruktioner sammen på 128 bits, eller en størrelse på små 43 bits pr. instruktion. Det er mere end for fx x86, så Itanium-kode skal indeholde væsentligt færre instruktioner for at kunne eksekveres lige så hurtigt.

  • 4
  • 0
Jacob Nordfalk

Well, ved du hvilken mikrokode de proppede i din CPU inden du købte den ?

Nej, og det er selvfølgelig lige så stort et problem.

Det jeg prøver at sige er, at offentligheden er stort set uvidende om at CPU'er kan (om)programmeres og at der kan ligge skjulte programmer på CPU'en der bare venter på den rigtige aktiveringskode.

At der også sendes 'patches' ud som omprogrammerer CPU'erne uden at nogen har indsigt i hvad omprogrammeringen gør, gør det bare ekstra slemt, især når firmaet er under NSAs domæne.

  • 4
  • 0
Thomas Dynesen

Hvis du med NASA mener USAs "Security-industrial-complex" så har de deres helt egen halvlederfabrik, så de kan være sikre på hvad der er i deres chips: http://www.sandia.gov/mstc/trusted/microsystems.html

Ja, der må jo desværre være en grund til at de er så paranoide. Hvad er lettest at lægge en usynlig "patch" ind i C-compileren der sørger for at alle compileringer af samme lægger NSA adgang ind i C, eller en "patch" af microkoden? Det sidste er vel nærmest umuligt at verificere, mens man jo nok godt kunne afsløre at nogle af de compilerede C-moduler fylder lidt rigeligt.

  • 0
  • 0
Torben Mogensen Blogger

I dag er situationen lige omvendt - det gælder om at få instruktionerne til at fylde så lidt som muligt, fordi CPU'en ellers bare skal vente på hukommelsen, og så kaster man flere transistorer efter dekodningen. En relateret fordel er selvfølgelig også, at små instruktioner giver mindre pres på cachen.

De mest udførte dele af koden vil ligge i cache det meste af tiden, så RAMens hastighed er ikke så afgørende for kodehentning (det betyder dog en del for datahentning -- data er typisk mange gange større end kode, undtagen når man bruger Microsoft Office). Mange processorer gemmer endvidere instruktioner i afkodet form i cachen, så størrelsen af instruktioner i RAM betyder mindre. Der, hvor det har størst betydning, er i indlejrede systemer, der typisk har meget lidt lager (nogle få KB ROM og RAM), og det var netop til det formål, at ARM lavede Thumb instruktionssættet, og det selv om det oprindelige 32-bit instruktionssæt var relativt kompakte for en RISC processor (sammenlignet med f.eks. MIPS). 64-bit udgaven af ARM er gået tilbage til rene 32-bit instruktioner, men mere ortogonale end det oprindelige instruktionssæt: Væk er betingelser på alle instruktioner, arbitrære shifts på alle aritmetiske operationer, osv, så instruktionssættet liger MIPS mere end 32-bit ARM eller Thumb/Thumb2 hvad kodetæthed angår.

  • 1
  • 0
Torben Mogensen Blogger

En af de mere interessante "rageknive" er interrupt latency: Hvis du ikke har ordentlig lav interrupt-latency, er du tydeligvic CISC, uanset hvordan dine instruktioner er strikket sammen eller om du bruger mikrokode eller ej.

Jeg foretrækker at skelne på ting, der udelukkende drejer sig om instruktionssæt og ikke implementering, og interrupt latency er for en stor dels vedkommende implementeringsafhængig. Dog sætter instruktionssættet (som for alle andre implementeringsdetaljer) grænser for implementeringen.

En af de processorer fra de tidlige 1980'ere, som havde lavest interrupt latency var i øvrigt Texas TMS9900 (http://en.wikipedia.org/wiki/Texas_Instruments_TMS9900), men den var bestemt ikke RISC -- dens instruktionssæt mindede mere om PDP11 end om MIPS. Dens hurtige kontekstskift skyldes, at den kun havde tre registre on-chip (hvoraf det ene pegede på 16 "registre" i RAM), så det var hurtigt at gemme dem og hente tre andre.

RISC kan sagtens have længere latency, hvis der er flere registre, der skal gemmes ved kontekstskift. Derfor havde selv de første udgaver af ARM skyggeregistre, der blev brugt ved interrupt, så man ikke skulle gemme brugerregistrene ved interrupt.

  • 0
  • 0
Morten Jensen

RISC kan sagtens have længere latency, hvis der er flere registre, der skal gemmes ved kontekstskift. Derfor havde selv de første udgaver af ARM skyggeregistre, der blev brugt ved interrupt, så man ikke skulle gemme brugerregistrene ved interrupt.

Det bliver man akut klar over når man skal implementere supervisor call på ARM-platformen, f.eks. ifbm. kontekst-switch eller hard-faults :D
Jeg syntes det var en lidt kludret løsning i starten, men det gør det let f.eks. at recover fra hard-faults eller gå en tur på stakken og give et fornuftigt trace.

Det er sjovt og let at kode ARM-assembly i skarp kontrast til f.eks. x86 :)

  • 0
  • 0
Mikkel Lauritsen

De mest udførte dele af koden vil ligge i cache det meste af tiden, så RAMens hastighed er ikke så afgørende for kodehentning (det betyder dog en del for datahentning -- data er typisk mange gange større end kode, undtagen når man bruger Microsoft Office). Mange processorer gemmer endvidere instruktioner i afkodet form i cachen, så størrelsen af instruktioner i RAM betyder mindre.

Jeg var lidt vag i min formulering ovenfor, for med "hukommelse" mente jeg hele hukommelseshierarkiet. På en moderne CPU har selv en lokal L1-cache en latenstid på 3-4 clockcykler ved et hit, så selv om der læses en hel cacheline ad gangen skal der ikke mange misses til før det virkelig kan mærkes.

Selv om ens kode har god lokalitet kan det være svært at få ting som mangetrådede serverapplikationer til at passe i en L1-instruktionscache på langt under 1 MB i størrelse.

Det ser i øvrigt ud som om, at et godt bud på en gennemsnitlig instruktionsstørrelse for x86 er i omegnen af 28 bits, så den kan altså bruge 50% flere instruktioner end Itanium og stadig have samme kodedensitet.

Og for så lige at vende tilbage til den med RISC vs. CISC (for evt. vedholdende læsere :-), så giver afsnittet om kodedensitet i
Wikipedias artikel om instruktionssæt i øvrigt en ret fornuftig sammenfatning af RISC vs. CISC og indflydelsen på kodestørrelsen.

  • 1
  • 0
Klaus Skelbæk Madsen

Det jeg prøver at sige er, at offentligheden er stort set uvidende om at CPU'er kan (om)programmeres og at der kan ligge skjulte programmer på CPU'en der bare venter på den rigtige aktiveringskode.

Men det har jo ikke noget med microkode at gøre? Så længe du ikke selv har lavet din CPU (og her mener jeg alt fra at designe maskerne til at stå i renrummet og fysisk lave den) ved du reelt ikke hvordan den fungerer. Og det gælder forøvrigt i alle lag af systemet.

Der var en som tidligere i tråden linkede til "Reflections on Trusting Trust". Læs den artikel, og tænk imens på at C-koden og compileren lige så godt kunne være maskinkode og CPU'en.

  • 0
  • 0
Henrik Kramshøj Blogger

... og vi snakker ikke RAID kortet, men selve controlleren på disken - det lille print du ved.

http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hacking-hard-drive...

https://program.ohm2013.org/event/67.html

Video fra eventet - har ikke selv set den - http://bofh.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks...

Så hvad siger I til en disk som skriver /etc/passwd og læser den korrekt, undtagen under specifikke omstændigheder ...

  • 2
  • 0
Frithiof Andreas Jensen

... så de kan være sikre på hvad der er i deres chips:


Muligvis. Muligvis findes der mere end een "Snowden". Som NSA selv har givet ubegränset og usporbar adgang til hele butikken fra en fjern ögruppe.

Chips generes fra og af software i dag. Kan man egentligt vide hvad der er i egen chip hvis f.ex. VHDL compileren, logik-blok-biblioteket eller "print to silicon"-processen hos leverandören er korrupt?

  • 0
  • 0
Jesper Louis Andersen

Jeg var lidt vag i min formulering ovenfor, for med "hukommelse" mente jeg hele hukommelseshierarkiet. På en moderne CPU har selv en lokal L1-cache en latenstid på 3-4 clockcykler ved et hit, så selv om der læses en hel cacheline ad gangen skal der ikke mange misses til før det virkelig kan mærkes.

Nemlig! En af de primære flaskehalse i dagens CPU'er er at de maksimalt kan dekode 4 insns per cycle. Det er ikke specielt godt og hvis du har en RISC-cpu med 32bit fixed width instructions, så sidder du og kigger på 128bit per cycle. Det gør rigtigt ondt på din cache. Hvis du derimod tænker "hah, jeg gør da bare min cache større", så bliver tiden fra cachens bagvæg for stor og så koster det hastighed på den bekostning at du ikke kan få signalet frem fra cache'n i tide.

Noget kunne tyde på at variable-width instruktioner har en fordel. Til gengæld kræver de mere dekoder-logik.

Man kan bare sidde og fornøje sig med Ivan Godard et.al's "Mill" CPU der godt nok er lidt vapourware, men hvis de har ret i 33 dekodede instruktioner per cycle, så lyder det positivt og ganske meget bedre end 4 :)

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