Idées & Perspectives

Explorer le développement AI-first, les garde-fous de code et l'architecture de la jetabilité.

abstract-interpretationstatic-analysismetainfer

Meta a trouvé 100 000 bugs dans du code de production avec un analyseur statique qui n'exécute jamais le programme

Infer de Meta utilise l'interprétation abstraite et la bi-abduction pour trouver les déréférencements nuls, les fuites de mémoire et les race conditions en raisonnant sur la structure du code, pas sur son exécution. Voici comment ça marche et comment l'utiliser sur votre propre codebase.

Meta a livré plus de 100 000 correctifs de bugs qui ont été attrapés par un analyseur statique avant que le code n'atteigne jamais un utilisateur. L'outil…
abstract-interpretationstatic-analysissafety-criticalaviation

L'analyse statique ne peut pas prouver que votre avion ne s'écrasera pas. Elle peut prouver quelque chose de plus utile.

L'interprétation abstraite sur-approxime chaque état possible du programme. Si une division par zéro est inaccessible dans l'abstraction, elle est inaccessible dans le code réel. Voici comment cela fonctionne et où cela atteint ses limites.

L'analyse statique ne peut pas prouver qu'un avion ne s'écrasera pas. Elle peut prouver que la boucle de contrôle de votre altimètre ne divisera jamais par…
abstract-interpretationstatic-analysisruntime-errorsverification

Comment prouver que votre code ne contient aucune erreur d'exécution (et pourquoi vous finirez probablement par abandonner)

L'interprétation abstraite permet de prouver l'impossibilité des erreurs d'exécution avant même l'exécution. Voici comment cela fonctionne réellement, pourquoi c'est difficile, et où cela s'inscrit dans votre chaîne d'outils.

Votre suite de tests passe. Votre vérificateur de types est vert. Vous livrez. Deux heures plus tard, la production génère une sur un cas limite auquel…
hardware-assisted-safetychericporting

Votre code C peut s'exécuter sur du matériel à capacités sans rewrite complet

L'ABI hybride de CHERI vous permet de porter du code C vers du matériel à capacités de manière incrémentale. Voici comment compiler, ce qui casse, et comment réparer sans rewrite l'intégralité de votre codebase.

Vous disposez d'une codebase C trop volumineuse pour être rewrite en Rust et trop critique pour rester exposée aux dépassements de tampon. Le matériel à…
hardware-assisted-safetycapability-hardwarecherisoftware-history

Le hardware de capabilities n'a pas échoué. Il est arrivé 40 ans trop tôt.

La sécurité mémoire au niveau matériel était possible dès les années 1970. Voici pourquoi les architectures de capabilities ont sans cesse perdu face aux modèles de mémoire plate, et pourquoi CHERI change enfin la donne.

Soixante-dix pour cent des CVE sont des bugs de memory safety. Des buffer overflows, des use-after-free, des double frees. Le genre de vulnérabilités qui…
hardware-assisted-safetysandboxingcwebassembly

Votre dépendance C peut faire planter l'intégralité de votre processus. WebAssembly peut l'empêcher.

Les conteneurs sont disproportionnés pour isoler une seule bibliothèque C. Compilez-la en WebAssembly et exécutez-la dans un sandbox WASI pour la memory safety, l'accès au filesystem par capabilities et le confinement des crashes sans Docker.

Un simple null pointer dereference au sein d'une bibliothèque C peut faire planter l'intégralité de votre application. Si cette bibliothèque parse des entrées…
hardware-assisted-safetymemory-corruptionmobileasan

Votre téléphone dispose déjà d'un matériel qui détecte la corruption de la mémoire

ARM Memory Tagging Extension et GWP-ASan rendent possible la détection de la sécurité mémoire en production sur les appareils mobiles modernes. Voici comment ils fonctionnent et à quoi ressemblent les compromis.

Votre téléphone peut détecter la corruption de la mémoire en production. Pas avec l'instrumentation complète que vous exécutez en CI, et pas à chaque…
hardware-assisted-safetybuffer-overflowmemory-safetycheri

Les Buffer Overflows Continuent d'Arriver Parce Que Nous Les Corrigeons dans le Logiciel

CHERI est une extension matérielle qui transforme chaque pointer en une bounded capability. Voici comment elle arrête les buffer overflows au niveau du CPU, ce que cela coûte et comment l'essayer sur du matériel réel.

Les buffer overflows figurent dans le CWE Top 25 depuis vingt ans. Nous avons les stack canaries, l'ASLR, le DEP, la control-flow integrity et les langages…
cleanroom-correctnessllmformal-proofsautomation

Les LLM ne peuvent pas prouver que votre code est correct, mais ils peuvent écrire le code répétitif qui le fait

La vérification Cleanroom nécessite de générer et de lever des obligations de preuve. Voici comment les LLM automatisent l'annotation et la génération de conditions de vérification afin que vous puissiez vous concentrer sur les preuves réellement difficiles.

Le génie logiciel Cleanroom exige que vous prouviez la correction de votre code avant de le compiler. Cela semble noble jusqu'à ce que vous passiez trois…
cleanroom-correctnessprocessefficiencypragmatism

Cleanroom Offre 0,1 Défaut par KLOC. Vous N'avez Pas Besoin du Rituel Complet pour Y Arriver.

L'ingénierie logicielle Cleanroom divise les taux de défauts par 100, mais l'adoption complète exige des équipes de test séparées et des preuves formelles. Voici un sous-ensemble pragmatique qui capture la majeure partie du bénéfice sans le overhead.

L'ingénierie logicielle Cleanroom offre 0,1 défaut par mille lignes de code. La moyenne industrielle est de 10 à 50. Le hic, c'est que le Cleanroom complet…