Microsoft
MicrosoftHey again pjmlp!
As a Microsoft employee I agree with your assessment that an embarrassing number of modern vulnerabilities come from a lack of memory safety, particularly in C. Personally, I have been an Ada dev, I am a fan of Rust and Golang and I love the innovation and progress being made in the space of language design. That being said, the value of open source software is in building what you need on top of what exists, and a huge amount of software exists in the open or in the private IP that is in C. As an engineer, the drive for purity and perfection in me would love to see it all converted to something like Rust. But I also recognize there is value in not reinventing the wheel for every project and that technology enables smaller groups to do more by building on things that exist. Also, keep in mind that while those languages are promising in many ways, supporting any additional languages is a challenge in the very small memory footprint Azure Sphere has.
Your concerns about C are a quality sentiment. But customer C applications in Azure Sphere are extremely limited in scope. A customer application is never serving as the foundation in a complex platform whose security is built on the combination of hardware, OS software and cloud services. A search will lead you to some impressive blog posts and whitepapers from researchers who have attempted to breach the foundations of Azure Sphere, even bringing 0-day Linux kernel exploits to the table, and not finding much of a foothold. What I think drives Azure Sphere forward is that “being perfect” in coding, even in memory safety, is not the meaning of security. Azure Sphere implements the 7 properties of highly secure devices, none of which are “be perfect in your code”. What Azure Sphere brings to the table is not a promise that trust can never be lost, it is the idea that trust can be renewed.