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

On Thursday, 3 December 2020 at 10:36:45 UTC, Paulo Pinto wrote:
>
> 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.

The product page doesn't say anything about that, just a link to the TamaGo github page in "related resources". However, it does say that it supports running Linux and its connectivity options suggests that this is the intended use for this product.

On Thursday, 3 December 2020 at 10:51:09 UTC, IGotD- wrote:
> On Thursday, 3 December 2020 at 10:36:45 UTC, Paulo Pinto wrote:
>>
>> 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.
>
> The product page doesn't say anything about that, just a link to the TamaGo github page in "related resources". However, it does say that it supports running Linux and its connectivity options suggests that this is the intended use for this product.

A link that you obviously didn't follow.

No it doesn't run Linux at all.

Had you followed the link, https://github.com/f-secure-foundry/tamago

> The projects spawns from the desire of reducing the attack surface of embedded systems firmware by removing any runtime dependency on C code and Operating Systems.

And better yet, were you actually curious to learn about TamaGo, you would eventually land on this CCC talk.

"TamaGo - bare metal Go framework for ARM SoCs.
Reducing the attack surface with pure embedded Go.

https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_framework_for_arm_socs

However I see I keep wasting my time on D forums.

On Thursday, 3 December 2020 at 14:08:45 UTC, Paulo Pinto wrote:
>
> "TamaGo - bare metal Go framework for ARM SoCs.
> Reducing the attack surface with pure embedded Go.
>
> https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_framework_for_arm_socs
>
> However I see I keep wasting my time on D forums.

You can go and do programming in TamaGo anytime than waste you time here.

Go is similar to D that it requires a runtime in order to have most useful features. It would be interesting to know how big this runtime is. This is also not really a kernel but baremetal framework + app support, which can have interesting applications.

What I have seen is that D + runtime is too big for any kernel right now.

On Thursday, 3 December 2020 at 14:53:10 UTC, IGotD- wrote:
> On Thursday, 3 December 2020 at 14:08:45 UTC, Paulo Pinto wrote:
>>
>> "TamaGo - bare metal Go framework for ARM SoCs.
>> Reducing the attack surface with pure embedded Go.
>>
>> https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_framework_for_arm_socs
>>
>> However I see I keep wasting my time on D forums.
>
> You can go and do programming in TamaGo anytime than waste you time here.
>
> Go is similar to D that it requires a runtime in order to have most useful features. It would be interesting to know how big this runtime is. This is also not really a kernel but baremetal framework + app support, which can have interesting applications.
>
> What I have seen is that D + runtime is too big for any kernel right now.

Mmmm, human lives are more and more becoming dependent on the safe and reliable operation of hardware and software. "Small" bugs can cause a cascade of downstream hazards to thousands of people. "My programming language must have unions" and "I really really want the kernel to be small" will eventually not be acceptable excuses for non-maximally-safe software, whether it's a kernel or not.

On 12/3/20 9:52 AM, Abdulhaq wrote:
> On Thursday, 3 December 2020 at 14:53:10 UTC, IGotD- wrote:
>>
>> What I have seen is that D + runtime is too big for any kernel right now.
> 
> Mmmm, human lives are more and more becoming dependent on the safe and reliable operation of hardware and software. "Small" bugs can cause a cascade of downstream hazards to thousands of people. "My programming language must have unions" and "I really really want the kernel to be small" will eventually not be acceptable excuses for non-maximally-safe software, whether it's a kernel or not.

If enough programmers band together and demand change, perhaps unions will end up killing unions ;)

On 12/2/2020 7:04 AM, IGotD- wrote:
> I also forgot to mention that when there is an out of bound access, both C++ and D throw an exception. Exceptions are usually a big no no in kernels because the potential memory allocation. In kernels you want to reduce and have absolute control over memory allocations. Only the new proposal "lean exceptions" in C++ might be interesting for kernels.

D has configurable options on what to do on a buffer overflow. One of them, the simplest, is just execute a halt instruction.

On 12/3/2020 8:08 PM, Walter Bright wrote:
> On 12/2/2020 7:04 AM, IGotD- wrote:
>> I also forgot to mention that when there is an out of bound access, both C++ and D throw an exception. Exceptions are usually a big no no in kernels because the potential memory allocation. In kernels you want to reduce and have absolute control over memory allocations. Only the new proposal "lean exceptions" in C++ might be interesting for kernels.
> 
> D has configurable options on what to do on a buffer overflow. One of them, the simplest, is just execute a halt instruction.



https://dlang.org/dmd-windows.html#switch-checkaction

On Friday, 4 December 2020 at 04:08:31 UTC, Walter Bright wrote:
> One of them, the simplest, is just execute a halt instruction.

which wouldn't help kernel code at all fyi

On 12/3/2020 8:13 PM, Adam D. Ruppe wrote:
> On Friday, 4 December 2020 at 04:08:31 UTC, Walter Bright wrote:
>> One of them, the simplest, is just execute a halt instruction.
> 
> which wouldn't help kernel code at all fyi

Infinitely better than a buffer overflow.