Dette indlæg er alene udtryk for skribentens egen holdning.

Revolutionen vi har ventet på

25 kommentarer.  Hop til debatten
Blogindlæg24. januar kl. 11:42
errorÆldre end 30 dage

Så er Robert Watson's CHERI ankommet, dvs. bygget ind i ARM Neoverse N1 processor!
Det er den første rigtige revolution i CPU arkitektur i min levetid og det bliver forhåbentlig standard i alle CPU-arkitekturer fremover.

Kogt helt ind til benet, går CHERI ud på at pointere ikke kan skabes, men kun nedarves.

Når CPU'en booter, har den én eneste pointer, der peger på addresse nul og den har tilladelse at tilgå al hukommelse med R, W & E.

Alle andre pointere skal specialiseres ud fra denne "ur-pointer", de kan ikke mere laves ved at tage mere eller mindre tilfældige heltal og påstå at de er pointere.

Artiklen fortsætter efter annoncen

For at sikre dette, er der et ekstra bit i hukommelsen, der markerer hvor der ligger "rigtige" pointere og hvis man overskriver, f.eks med memcpy() bliver det bit slettet.

Her er et godt blogindlæg fra Microsoft om hvor vildt banebrydende CHERI er.

CHERI ville altid have fanget 43% af de sikkerhedsfejl der blev sendt til MSRC i 2019.

Kæmpe hat-tip til min ven Professor(!) Robert Watson!

Artiklen fortsætter efter annoncen

phk

25 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
23
26. januar kl. 10:54

Ville det ikke være relativt nemt at lave to pointere ud fra en ved at dele størrelsen over i to dele? Eller mangler der support for den operation?

Det er en helt normal operation og selvfølgelig kan du det.

Det du ikke kan på "normal" hardware, er at begrænse længden af den forreste afledte pointer.

Man kan idag godt lave en malloc der mmap'er alle allokationer så de ligger i slutningen af en VM page, på den måde giver man de returnerede elementer en "HW-længde". Specielt med 64 bit addresserum burde folk gøre dette mere under test/coverage kørsler. Men der er ingen måde at begrænse længden hvis man "deler" det man får tilbage fra malloc.

Med compiler support vil meget af dette ske automatisk:

struct foo {
     char buf[1024];
     struct bar bask;
};

struct foo *foop = get_me_a_foo();  // længde = sizeof(struct foo);
strcpy(foo->buf, "Blablabla"); // strcpy får pointer med længde 1024
baskit(&foo->bask, foo->buf); // arg1 længde = sizeof(struct bar) osv.
22
26. januar kl. 10:47

Modsiger du ikke dig selv med de to udsagn?

Nej, egentlig ikke. Med "nutidig performance" mener jeg implict "Glem alt om MACH og andet message-passing." der kører ca. 1/100 af nutidig performance.

(Retfærdigvis skal så siges: Hvis nu vi fik HW-support for messagepassing over intra-CPU backbone, der jo allerede er message-passing i hardware, så ville MACH pludselig blive rigtig interessant, særligt hvis det også havde CHERI :-)

18
26. januar kl. 09:44

Vi (en god kollega) implementerede noget tilsvarende i SW i hedengangne Ambrasoft, hvor alle der lavede bank-SW i C var forpligtiget til at bruge den specielle version af malloc og free. Følgende er efter hukommelse, da det trods alt er ca. 30 år siden:

'new_malloc' allokerede og skrev nogle ekstra bytes i hver ende af det allokerede mener det var "xx>>" og "<<xx" og returnerede en pointer til alloc_mem+4 :)

'xx' var en identifier og 'new_free' undersøgte at der ikke var overskrevet ved frigivelse. Hvis det var tilfældet kunne man skrive til log eller longjmp til en fejlrutine etc. på den måde fandt vi faktisk en del af den slags fejl.

17
26. januar kl. 08:30

Vil den kunne fange en sådan fejl?

Ja, hvis din "overloadet new" laver ny afledte pointere.

Når du får en "klump memory" består din pointer af:

{magisk_bit, addresse, længde}

Du kan kun modificere en pointer på to måder:

Du kan flytte addressen længere frem, men hardwaren vil reducere længdefeltet tilsvarende, i existerende kode vil dette ske uden du overhovedet behøver gøre noget.

Men du får også en ny pointer-operation til udtrykkeligt at reducere længden.

Ideelt set vil compilere selv kunne indsætte denne, hvor de kan se at det er det der foregår, men det afhænger af sprogets semantik.

Et sted hvor compileren ikke kan gøre det, er netop memory-allocation, her skal der et par ekstra operationer ind for at "skære pointeren til" inden den returneres.

Det er heller ikke alle modeller af memory-allocation, eller rettere memory-free der er mulige. Man kan f.eks ikke lave K&R tricket med at "der liggere en next/prev pointer lige foran" osv.

16
26. januar kl. 00:36

Efter at have læst Microsoft artikel er jeg ikke sikker på jeg forstår helt hvordan denne hardware pointer vil kunne fungere hvis man allokere en større klump memory hvor efter en overloadet new deler ud af denne klump til den samme type objekter, hvor der er en tekststreng i. Nu adresseres der ved en fejl uden for tekststrengen område og kommer herved til at overskirve et andet object. Vil den kunne fange en sådan fejl?

14
25. januar kl. 23:19

Sproget og programmeringen er stadigt vigtigt.

CHERI kan vel ikke gøre andet end at lave en exception, og hvad så? I mange tilfælde går pointer sjusk godt, så nok vil en række sikkerhedshuller blive lukket, men vi risikerer at programmerne begynder at få nye fejl. Forhåbentligt fanger testen de fleste.

12
25. januar kl. 22:08

Ved du, om de har lavet benchmarks på deres CheriBSD?

Indtil nu har de kun haft software og FPGA emuleringer af CHERI, så jeg ved ikke rigtig hvor brugbart evt. benchmarking er.

Det primære impact er at pointere fylder mere i hukommelsen.

For min skyld er det OK hvis de kører halv hastighed: hellere sikkert end hurtigt.

11
25. januar kl. 20:46

Vis mig en operativsystemkerne med nutidig performance skrevet i et sådant sprog ?

Trods den skepsis overfor projektet, jeg ovenfor har givet udtryk for, så synes jeg absolut at det er et spændende projekt.

Jeg kan se, at de har lavet en version af FreeBSD, som de har kaldt CheriBSD.

Ved du, om de har lavet benchmarks på deres CheriBSD? Hvis Microsofts påstand om at "You can also run non-CHERI software on a CHERI system just as you can run 32-bit software on most 64-bit processors." står til troende, så burde det være muligt at afvikle en vanilla FreeBSD på samme system, som de har afviklet CheriBSD på. Men jeg kan ikke umiddelbart finde nogen indikationer på deres performance.

Jeg vil naivt antage at et program der bruger 128 bit i stedet for 64 bit må opleve en vis degradering af performance. Men jeg har ikke fundet noget, der bekræfter min antagelse eller blot giver en nogenlunde indikation af hvor stort et tab det vil give.

8
25. januar kl. 17:34

Det er lidt sent at fange pointerfejl på køretid, selv om det er bedre end aldrig.

Sprogene bør laves, så det er umuligt at lave pointerfejl, da alle sådanne ville blive fanget på oversættelsestidspunktet af typesystemet -- eller slet ikke forekomme fordi pointere på forhånd (dvs. at det ikke først checkes på køretid) er begrænset til at blive oprettet og fulgt (med offsets inden for det allokerede), og det de peger på først fjernes, når der ikke er flere pointere til dem. Sidstnævnte kan gøres med garbage collection eller ved at typesystemet holder øje med ejerskab og levetid (som i Rust eller med regionsinferens).

Jovist, det er rart at kunne oversætte C, men det kan man også gøres ved at lade compileren indsætte checks hver gang, man følger eller opdaterer en pointer, så man statisk kan garantere, at man holder sig inden for grænserne af allokeringen. CHERI er reelt bare hardwaresupport, der garanterer at sådanne checks laves inden pointeroperationer, så man statisk er sikker på, at snavns opdages -- dog med køretidschecks som omkostning). Men det ville være bedre helt at kunne undvære at skulle lave sådanne checks på køretid (uanset om hardwaresupport nedsætter tidsforbruget og sikrer, at de rent faktisk laves). Det vil kræve maskinsprog med typer, der kan sikre pointer-safety INDEN et program køres, uden at skulle lave checks på køretid). Inden brugerkode eksekveres, bliver det checket for typekorrekthed (af et program, der er typechecket inden det lægges i operativsystemet). Der kan være behov for, at koden annoteres med information, der gør verifikation nemmere (proof-carrying code).

7
25. januar kl. 16:40

Det var nok lidt moraliserende.

Og her er lidt mere: For 47 år siden, lærte jeg i gymnasiet (1.g) at matematik var "anvendt dovenskab". Vi havde kun Bjørn det første år, men de "sproglige" havde ham lidt mere.

Sjusk er mig bekendt forbeholdt de "produktive", der tror de kan det (IT).

Vi andre har meget glæde af "krøllede hjerner", som DPs.

6
25. januar kl. 15:31

Programmørene skal også leve, det gør de kun, hvis de skriver kode.

Programmører lever ikke af kode alene.

Men mere relevant, så er der mange andre muligheder for at skabe problemer/katastrofer ved at sjuske. Om dovenskab er en fejl eller en dyd, er jeg usikker på. Spørgsmålet er, hvad man bruger sin dovenskab til. Elegant og gennemskuelig (og fungerende) kode er dovenskab på langt sigt. Sjusk er masser af arbejde på langt sigt og dermed gruelig flid (eller til man søger andre steder hen).

Det var nok lidt moraliserende.

4
24. januar kl. 22:04

Det er vel egentligt meget præcis at den her udvidelse gør.

Jo, men den gør det jo ikke af sig selv.

Ifølge bloggen fra Microsoft skal softwaren omskrives til at drage fordel af den nye arkitektur

C/C++ software is at best source compatible (requiring a recompile) and typically requires at least some small source code modification, at least if you want any of the security benefits.

Og det er tilsyneladende ikke engang nødvendigt at gøre brug af forbedringerne.

You can also run non-CHERI software on a CHERI system just as you can run 32-bit software on most 64-bit processors.

Umiddelbart vil jeg hellere sætte mine penge på nyere sprog som Rust. Men under alle omstændigheder er det glædeligt at se at der er en trend væk fra den overdrevne brug af C med usikker pointeraritmetik.

3
24. januar kl. 21:23

Det er vel egentligt meget præcis at den her udvidelse gør.

2
24. januar kl. 15:18

så mangler vi bare at få stoppet sjusket software udvikling. Det kan nok ikke fixes i hardware.