OpenBSD: Immutable Userland Mappings | Hacker News Reader

OpenBSD: Immutable Userland Mappings

marc.info

85 pointssigna1136 comments

If I understand this, it can be looked as a kind of W^X. Yet another security advance I think. Cool.

OpenBSD gets better all the time, but not larger. It's what made me switch.

Do you use it as a desktop? My biggest problem there is WiFi. I predominantly use a laptop, and BSDs are notoriously bad at that use case. I tend to like to keep my servers and workstations on the same OS if possible. Hence, I haven't made the switch.

Anyway, all that to say, what are you running it on?

I’m currently using OpenBSD as my only operating system on my Thinkpad X1 carbon (gen 7).

Wifi works just fine. I remember that the wifi drivers aren’t part of the base install system for licensing reasons, but they provide a very simple tool that will download it and set it up.

Generally, with openBSD, if something is supported, it is supported correctly. My go to example is that my keyboard backlight controls work even from the tty terminals.

But also, if there is something that the developers don’t think they can support correctly, they don’t hesitate in removing it entirely from the OS. They removed Bluetooth support for example.

It’s not for everyone. But for me, I love the idea that I can trust my primary computing environment because the developers care soo much about the little details.

I can't say how it is for the Thinkpad but most of the time keyboard backlight control is done in hardware. You can catch the keypress event and sometimes control it from the OS but the dimming/brightening works completely independent of the OS.

Yeah, kb backlight even works under Linux most of the time. Monitor backlight works everywhere out of the box under OpenBSD though, nothing at all like the hackish mess on other systems.

Except when it doesn't, like on T450s laptops for instance.

That's what's great about OpenBSD. Other systems might support 802.11n, 802.11ac and stuff like that. But OpenBSD supports 802.11g, _correctly_. Not like Linux or Windows that support it, but _incorrectly_.

OpenBSD, in general, has better Wi-Fi support than the other BSDs. Not as good as Linux, but improvements are made regularly.

I was smart enough to buy a computer that OpenBSD is compatible with, so I don't have any of these issue of which you speak. I use a T420. I have more powerful computers at my disposal, a Talos workstation and a high core count recent AMD. But this is the computer I use 90% of the time, at least as an interface to the others.

I used OpenBSD on servers, but the lack of Bluetooth stack keeps me from using it on the desktop.

> lack of Bluetooth

You can use usb hardware bluetooth dongles [0] with OpenBSD, they are detected like any other audio device. I assume that there are a variety of these available.

[0] I'm using https://www.amazon.com/gp/product/B00ZYYPFHU

I primarily need it for my mouse, but that's good to know for audio.

FWIW, you can also get a mouse that wirelessly talks to a USB dongle, i.e. the interface to the PC is USB (which OpenBSD does support); the first hit I got is https://www.amazon.com/Logitech-M185-Swift-Wireless-Mouse/dp...

I use a cheap, wireless mouse with OpenBSD on a ThinkPad. I've never had a problem with it. No special configuration. It just works

You can have a look at the boot log for an idea how other users are doing on their hardware

https://dmesgd.nycbug.org/index.cgi?do=index&fts=OpenBSD

When using wifi that works [0] I actually quite like the use of ifconfig for making connections.

[0] I was actually surprised my particular ath9k chip was unsupported (it would panic the kernel is added) as it was fully supported in linux-libre.

OpenBSD has the only correct implementation of wifi among all Unix and Unix-like operating systems. It's really the best thing going.

If you're using Intel wifi, it's supported and works full speed.

Tempted to install it again but I have vague memories of tedious battles against the WiFi firmware on this me_cleaned laptop I have kicking around.

I legit wonder if it's not time for OpenBSD to switch to Java.

I mean, there's so much work to keep C safe and make sure memory is managed well, etc.

What the project needs is a virtual machine! Clearly they don't care about performance when security is on the line (they did disable multithreading, no?). A good virtual machine will be a small performance loss compared to dealing with this stuff... forever.

Of course, you still have to deal with user land binaries.

Garbage collection and just-in-time compilation in the kernel? I'm thinking you must be joking.

This mailing list article is about providing new or modified behavior in the kernel to guarantee behaviors - and security - to userland programs in any language.

Re: Disabling multithreading, I think you might be referring to disabling simultaneous multithreading (SMT) (edited: fixed thanks to a comment), also known as hyperthreading.

Nope,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

Or, for another example,

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

It is only incompatible with UNIX school of thought.

You mean simultaneous multithreading (SMT), aka hyperthreading.

Symmetric multiprocessing (SMP) is when all processors have uniform distance from all memory, as opposed to non-uniform memory access (NUMA).

D'oh! You're absolutely right. Fixed my comment, thank you!

Linux's eBPF is JIT compiled and has its memory managed fwiw. There are lots of virtual machines in kernels, they're an excellent fit.

Sure, but this seems like a non-sequitur. eBPF has its memory managed in a very different sense than a garbage collector, eBPF programs cannot loop, and so on.

Java's virtual machine is so substantially different it's hard to know where to begin.

You can start here, for bare metal deployments,

https://www.ptc.com/en/products/developer-tools/perc

I don't understand why this non-sequitur keeps going! There seems to be a lot of point-missing here.

OpenBSD is a kernel and a general purpose operating system. It runs arbitrary userland software.

Rewriting the kernel in Java will not make C user code safer, and the cost to convert OpenBSD is so nontrivial as to make it an absurd suggestion. I mean, really truly absurd. As in, "am I even talking to real people who work with software?" absurd. If you think it's a good idea to rewrite a posix-compatible OS kernel in Java, by all means, go do so and make a patch against OpenBSD. It's a monumental undertaking, and I'm sure it'll be impressive!

On the other hand, rewriting userland software in Java (from C) will definitely make it safer, but users can already do this and are choosing not to. The goal of this change is to make it easier to write safer C.

A bare metal language runtime is a kernel....

I am fully aware UNIX clones will never use anything beyond C for most part, although there are some famous UNIXes like Apollo that did indeed trail another path.

The context of this thread is adding syscall to the kernel to allow C userland programs to be safer.

Even if the kernel were written in Java - which is, again, absurd to ask of the OpenBSD developers - it would still be a viable syscall to add for user mode programs written in memory unsafe languages.

Only way to make C "safer", is to follow Solaris footsteps, hardware memory tagging.

Even if we had memory safety I think immutable userland mappings would be a valid and interesting technique to implement.

OpenBSD still has not switched to advanced technologies like file system journaling, so Java is probably a stretch.

Why not Rust?

How would rust do anything to help?

Reply on news.ycombinator.com