Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

Paulo Pinto pjmlp at progtools.org
Thu Dec 3 10:36:45 UTC 2020


On Thursday, 3 December 2020 at 10:12:35 UTC, Max Haughton wrote:
> 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?


The whole software stack is 100% written in TamaGo (bare metal Go 
for ARM SoCs), which obviously you didn't bother to read about on 
the product page.


>>
>> 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.

Hence why Go has unsafe package for breaking  outside the safety 
features.

Ironically, what I get from these kind of replies is that 
companies like F-Secure or PTC/Aicas/Astrobe (*bare metal* 
Java/Oberon) deliver, whereas here one keeps arguing how bad GC 
is and it is time to reboot the whole D language for an imaginary 
crowd to finally adopt it.

In the end, maybe those languages are the ones being adopted.

https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2020_06_SSTIC/SSTIC2020%20-%20Pursuing%20Durably%20Safe%20Systems%20Software.pdf



More information about the Digitalmars-d mailing list