Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

21–30 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#21
post #10
post #3

Earlier quoted context omitted.

That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

This seems like a bit of a trite point unless many rust developers are actually working inside i386. Though the compiler itself might not work very well in i386. Not many people are whining about our C compiler toolchains not fitting into our microcontrollers.

Every port being self-hosting is a fundamental project value in OpenBSD. The reason being that they believe every port should be useful and functional, not just a novelty. And requiring that every port be self-hosting is a way to enforce this.

For example, the NetBSD project has a dreamcast port, but like most of their ports, it is crosscompiled. The last time I tried the port it would crash when put under high load for a while and would kernel panic when you tried to play audio. The netbsd dreamcast port is not functional in the sense that openbsd would like to enforce, something which is not relevant to netbsd and in no way denigrates them, but merely serves as an example.

Re: Integrating “safe” languages into OpenBSD?

#22
post #3
post #2

Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils

That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether its a good thing or a bad thing. Also in terms of systems languages I believe only rust has some potential to truly replace C. Although, a large part of C usage still takes place in the embedded world where rust has yet to be ported to many embedded processors. Go's GC makes it a show stopper for use in many places as for haskell I would be very interested to see more low level embedded programming going on in it.

Re: Integrating “safe” languages into OpenBSD?

#23
post #5
post #3

Earlier quoted context omitted.

That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

People are still using i386? I'd assume even if they are, it's such a tiny minority that it shouldn't be an excuse to hold everyone else back.

One of OpenBSDs sweet spots is turning old hardware into useful, secure, reliable, network infrastructure.

i386 might not be as popular as it was on 'normal' OS, but I wouldn't be surprised if OpenBSD had a lot of people still using it.

Re: Integrating “safe” languages into OpenBSD?

#24
post #15

The points made against switching to newer languages are valid. It will cost time, it will cost effort, it will take many years of work to convince stubborn maintainers to switch. But it will not stop _everyone_ from adopting better languages, and their efforts will eventually surpass the older, less secure systems. When there's feature parity, each and every new exploit will be called out: "this wouldn't have happen…

Yep, I look forward to the day OpenBSD is obsolete. How Theo can be so anal about features like ASLR but then completely disregard the potential of compiler enforced memory safety is beyond my cognitive power.

Considering the complete lack of viable competition in the space, that day is a long way off.

Re: Integrating “safe” languages into OpenBSD?

#25
post #12
post #2

Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils

>Such ecosystems come with incredible costs. For instance, rust cannot >even compile itself on i386 at present time because it exhausts the >address space. Is cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, envir…

I'm pretty sure that attack you describe is mentioned in literature as essentially undefeatable. I really wish I could remember exactly what the name of it was; the gist is, there has to be a first compiler somewhere. If at any point in the chain, the compiler is infected with a self-propagating virus that hides itself in the byte code of the binary, it can ensure that the exploit is in every future version of the compiler.

I may be remembering the details a bit wrong, but it was a good read.

Re: Integrating “safe” languages into OpenBSD?

#26
post #12

Earlier quoted context omitted.

>Such ecosystems come with incredible costs. For instance, rust cannot >even compile itself on i386 at present time because it exhausts the >address space. Is cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, envir…

I'm pretty sure that attack you describe is mentioned in literature as essentially undefeatable. I really wish I could remember exactly what the name of it was; the gist is, there has to be a first compiler somewhere. If at any point in the chain, the compiler is infected with a self-propagating virus that hides itself in the byte code of the binary, it can ensure that the exploit is in every future version of the co…

You want the "trusting trust" keyword.

Re: Integrating “safe” languages into OpenBSD?

#27
post #8
post #5

Earlier quoted context omitted.

People are still using i386? I'd assume even if they are, it's such a tiny minority that it shouldn't be an excuse to hold everyone else back.

Linux supported i386 until 2012, I think in this context it is more likely to refer to pre-Pentium 86 CPUs though (I'm not certain on that) I've seen i386 multiple times to also refer to any x86 Arch.

i386 in this context refers to 32bit intel x86 cpu architecture in general and generic pc compatibles specifically. OpenBSD currently runs on 486s and better:

> All CPUs compatible with the Intel 80486 or better,[0]

[0]https://www.openbsd.org/i386.html

Re: Integrating “safe” languages into OpenBSD?

#28
post #10
post #3

Earlier quoted context omitted.

That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

This seems like a bit of a trite point unless many rust developers are actually working inside i386. Though the compiler itself might not work very well in i386. Not many people are whining about our C compiler toolchains not fitting into our microcontrollers.

Linux and BSD ran for a long time on 32bit systems. 4GB of memory is an ocean in my mind. Those systems should be able to compile their own programs and tools.

On a related note, we will eventually be running development tools on microcontrollers. Not that little 16bit parts will run the tools, but that 16bit parts are going away. In price sensitive areas this will not happen, but for things with a larger budget why not run the tools right on the target? If your controller is an RPi why not use it for development?

Re: Integrating “safe” languages into OpenBSD?

#29
post #12

Earlier quoted context omitted.

>Such ecosystems come with incredible costs. For instance, rust cannot >even compile itself on i386 at present time because it exhausts the >address space. Is cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, envir…

I'm pretty sure that attack you describe is mentioned in literature as essentially undefeatable. I really wish I could remember exactly what the name of it was; the gist is, there has to be a first compiler somewhere. If at any point in the chain, the compiler is infected with a self-propagating virus that hides itself in the byte code of the binary, it can ensure that the exploit is in every future version of the co…

A talk by Ken Thompson, "trusting trust".

Re: Integrating “safe” languages into OpenBSD?

#30

Earlier quoted context omitted.

Yep, I look forward to the day OpenBSD is obsolete. How Theo can be so anal about features like ASLR but then completely disregard the potential of compiler enforced memory safety is beyond my cognitive power.

Considering the complete lack of viable competition in the space, that day is a long way off.

Why is Redox not viable competition?
Post reply on HN