Revolutionen vi har ventet på

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

Altså at det ikke er OS, men CPU som skaber en del af sikkerheden. Altså en forbedret sikkerhed i Hardware, som ikke kan omgåes af (beviste)fejl i software.

Som jeg forstod det på PHK indlæg ?

Det er ikke helt det samme, for det vil ikke fange, hvis du adresserer langt forbi stopmærkerne. Men nogen dårlig ide er det ikke.

Den phkmalloc jeg skrev kunne lave en masse check og da jeg i sin tid præsenterede den på USENIX startede jeg med en slide med programmer jeg havde fundet malloc fejl i. Det var, som en af tilhørerne bemærkede, en ret komplet liste af setuid(2) programmer.

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.

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 :-)

'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.

Det er ikke helt det samme, for det vil ikke fange, hvis du adresserer langt forbi stopmærkerne. Men nogen dårlig ide er det ikke.

Du kan kun modificere en pointer på to måder:</p>
<p>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.</p>
<p>Men du får også en ny pointer-operation til udtrykkeligt at reducere længden.</p>
<p>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.</p>
<p>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.

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?

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

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

Modsiger du ikke dig selv med de to udsagn?

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.

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.

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?

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

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.

hellere sikkert end hurtigt

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.

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

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.

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

Jeremy Soller fra System76 har haft travlt med at lave et nyt Desktop Environment til Pop!_OS, og det betyder desværre nok at Redox OS aldrig bliver "færdigt" eller blot godt nok til daglig brug. Ellers ville det nok have været et godt bud.

Sprogene bør laves, så det er umuligt at lave pointerfejl,

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

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).

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.

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

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.

så mangler vi bare at få stoppet sjusket software udvikling.

Fleksibilitet og dovenskab (sjusk) er sjældent en god kombination; hvis det nok at gøre "ingenting", ved vi jo godt hvordan det ender. Programmørene skal også leve, det gør de kun, hvis de skriver kode.

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

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.

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

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

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

For dem, der vil vide lidt mere er her en FAQ:CHERI FAQ at University of Cambridge

WikiChip om N1