Outils & Logiciels

p. 04   Alimentation de laboratoire ALIENTEK DP100 : petite, mais costaud
p. 18   Un oscilloscope à pédale

Sécurité

p. 34   Concevoir, mettre en place et bidouiller un environnement basé sur le protocole industriel Modbus

FPGA & Gateware

p. 54   Mon premier projet FPGA : un ordinateur 8 bits complet en VHDL
p. 88   Pimp my LED counter, les performances de l’addition

Rétro

p. 112  Asterisk, RTC, PPP, CPC 464... Surfons comme en 1989 !

Quelque chose est sur le point de changer dans l’embarqué... et pas seulement.

La sécurité des systèmes est plus que jamais sur le devant de la scène. L’industrie entière s’est enfin rendu compte des répercussions potentiellement catastrophiques de failles de sécurité au plus bas niveau et redouble d’efforts pour « régler » le problème. Mais on a beau tenter de « sécuriser » les systèmes, les applications, les services et même les langages, si une faiblesse existe, héritée de plusieurs dizaines d’années d’histoire de l’informatique moderne, elle sera forcément exploitée. Cette faiblesse est la manière dont l’accès à la mémoire est géré par les processeurs et la corruption de cette mémoire, d’une façon ou d’une autre, représente statistiquement la principale cause des failles de sécurité.

Pour régler le problème, un nouveau paradigme a vu le jour et est sur le point de se généraliser, en particulier dans l’embarqué (dans un premier temps) : les capabilities et plus exactement l’adressage mémoire basée sur les capabilities. Le concept n’est pas nouveau, puisqu’il s’agit simplement d’associer une métadonnée à un objet (au sens large du terme), pour conférer ou non une « capacité » (d’où le nom) à manipuler cet objet. Ce qui est (presque) nouveau, en revanche, c’est d’intégrer ce mécanisme dans le processeur lui-même sous la forme d’une gestion mémoire étendue et d’instructions spécifiques. « Presque », parce que le System/38 d’IBM (1978) utilisait cette technologie, mais depuis, le mécanisme de pagination mémoire a été universellement adopté.

Le projet vers lequel convergent les recherches depuis quelque temps est celui de l’université de Cambridge : CHERI (pour Capability Hardware Enhanced Risc Instructions). Les constructeurs (ARM en tête avec son projet Morello, mais RISC-V n’est pas en reste), les éditeurs de logiciels, ainsi que les projets open source (Morello Linux, CheriBSD, LLVM, FreeRTOS, etc.) forcent la marche pour nous rapprocher d’un premier produit fini.

Difficile de prédire quand cette révolution aura lieu, et débarquera dans nos smartphones et nos SBC, mais elle est en route, et ça changera énormément de choses...

Denis Bodor