Ny ARM-processor kommer med imponerende sikkerhedsfordele
-
af
_tweak
mboost-dp1
Arm Limited
Jeg havde kun hørt om det ét sted, nemlig via PHK på v2.dk - så her blev jeg glad for lige at kunne læse om det andetstedsfra, men... :-)
Uanset - fedt! Ny hardware tech er tit fedt. Det bliver spændende hvilke problemer det så trækker med sig, og om programmer uden videre kan recompiles til den arkitektur, eller skal refaktoreres - hvilket jeg gætter på betyder, at det ikke kommer til at batte en prut.
Uanset - fedt! Ny hardware tech er tit fedt. Det bliver spændende hvilke problemer det så trækker med sig, og om programmer uden videre kan recompiles til den arkitektur, eller skal refaktoreres - hvilket jeg gætter på betyder, at det ikke kommer til at batte en prut.
Spændende. Som jeg læser Microsoft bloggen: https://msrc-blog.microsoft.com/2022/01/20/an_armf... er der tale om en "næste generations" MMU der ikke bare beskytter processer mellem processer, men registrerer for hver eneste pointer hvad den har af read og write rettigheder, hvor. Rettighederne defineres i et hierarkisk princip.
Det lyder kompliceret. Gad vide hvor meget performance penalty det giver. Omvendt betyder det vel at man kan få hardware til at lave array bounds checking. Det kan måske give speed-ups i nogle sprog / VMs.
Det lyder kompliceret. Gad vide hvor meget performance penalty det giver. Omvendt betyder det vel at man kan få hardware til at lave array bounds checking. Det kan måske give speed-ups i nogle sprog / VMs.
#2 Det kan være at det giver performance penalty (håber det ikk). Men omvendt kan man håbe at det trækker den anden vej, med at antivirusserne er blevet optimeret til det. Den skal jo muligvis pludselig lave mindre end før fordi der er mindre antal sårbarheder at holde øje med nu.
Vi har allerede fået perfomance penalty med Spectre og Meltdown sårbarhederne, så jeg håber ikke det her også tynger processoren.
Vi har allerede fået perfomance penalty med Spectre og Meltdown sårbarhederne, så jeg håber ikke det her også tynger processoren.
#3
Feature kunne bruges til at restricte en pointer til kun at kunne tilgå det memory der blev initielt allokeret.
char *p = malloc(100);
vil kun kunne tilgå de 100 bytes.
Men der findes sprog som allerede kan begrænse pointere på den måde idag. Og kan man leve med sådan en restriktion, så skulle man nok ikke have valgt C.
Men man kan også bruge den feature til at isolere forskellige dele af et program, således at de ikke kan tilgå hinandens memory. OO encapsulation i HW.
Og jeg gætter på at det vil være mere interessant.
Feature kunne bruges til at restricte en pointer til kun at kunne tilgå det memory der blev initielt allokeret.
char *p = malloc(100);
vil kun kunne tilgå de 100 bytes.
Men der findes sprog som allerede kan begrænse pointere på den måde idag. Og kan man leve med sådan en restriktion, så skulle man nok ikke have valgt C.
Men man kan også bruge den feature til at isolere forskellige dele af et program, således at de ikke kan tilgå hinandens memory. OO encapsulation i HW.
Og jeg gætter på at det vil være mere interessant.
#6 Ja, "pæn" C og C++ kode vil nok kunne compiles til at udnytte disse features direkte, med passende udvidelser i standard libraries i f.eks. malloc og free. Men der er rigtig meget cowboykode derude hvor pointere kastes rundt og peger på alt muligt. Det vil kræve porting og måske omskrivning.
Mon ikke det ender med at lavkritisk og legacy kode for lov til at køre som det plejer mens kritisk serverkode og systemkode opdateres til at udnytte disse features. En dag.
Mon ikke det ender med at lavkritisk og legacy kode for lov til at køre som det plejer mens kritisk serverkode og systemkode opdateres til at udnytte disse features. En dag.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund