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