Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Max Haughton]

On Thursday, 3 December 2020 at 10:07:19 UTC, IGotD- wrote:
> On Thursday, 3 December 2020 at 09:04:56 UTC, Paulo Pinto wrote:
>>
>> F-Secure apparently is living in a phantasy world, 
>> https://www.f-secure.com/en/consulting/foundry/usb-armory
>
> How does this product has to do with safe and unsafe language 
> designs?
>
> On Thursday, 3 December 2020 at 09:16:06 UTC, Paulo Pinto wrote:
>>
>> Ah, and NVidia is going phantasy land as well, 
>> https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous-driving/
>
> The answer is still no, you cannot write a kernel in a safe 
> language without breaking  outside the safety features. You can 
> write a kernel in Rust but many portions must be in unsafe 
> mode, for example unions are not safe in Rust. Ada and SPARK 
> are likely to be good languages if you want to create stable SW 
> however like I wrote before in order to write a kernel you're 
> likely to step outside the safety harness in these languages as 
> well. Kernel SW is inherently unsafe.

Just because you have to take some liberties with the safety 
features doesn't mean you have to avoid them entirely. If you 
look at the Linux kernel, a huge amount of the code could nearly 
be in userspace when you take into account how it actually works. 
For example, implementing a high level system call like 
perf_event_open is practically doable as a library with the right 
msr set.

With a safe language you can carefully contain and test unsafe 
constructs, with C you don't even have the option of doing that.