Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD may soon gain further memory protections: immutable userland mappings

marc.info

Post reply on HN
Print view View original

31–40 of 72 posts

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#31

Post by gigantaure »

chasil wrote: post #25
fsckboy wrote: post #18

Earlier quoted context omitted.

OpenBSD does great work, but for the record OpenSSH started as a fork of the free SSH program developed by Tatu Ylönen; later versions of Ylönen's SSH were proprietary software offered by SSH Communications Security. https://en.wikipedia.org/wiki/OpenSSH

Realistically, OpenBSD completely reimplemented protocol 2 themselves. Since nobody uses protocol 1 anymore, very little of the original code from Tatu Ylönen remains in operation with default settings. ps I have had to use the SSH commercial release under VMS, and the compatibilities with OpenSSH are quite unpleasant.

i just read that page[1] earlier this week. this gives a great view on the amount of work performed by the openssh project after the fork of the last open source version.

[1] https://www.openssh.com/history.html

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#32

Post by crest »

jart wrote: post #9

Now all we need is for PROT_EXEC to not imply PROT_READ like Android.

Why do you expect removing PROT_READ to provide a security gain when running open source software compiled using reproducible builds? Just the offset into an executable memory mapping is enough to know the executable code to be found. Sure it's a bit annoying, but it wouldn't prevent attackers from using it as ROP gadget.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#33

Post by Sunspark »

na85 wrote: post #29
kyledrake wrote: post #2

This security tech usually ends up in other platforms too, strongly recommend donating to their work: https://www.openbsdfoundation.org/donations.html

And thus the failure of BSD-style licensing is thrown into sharp relief: Why are these projects that are used by many large and extraordinarily profitable tech enterprises dependent on community donations? I recommend not donating, because to do so directly supports corporate parasitism.

The flip side of course is that improvements also come at the pace of volunteerism, and there are no boardroom meetings where a manager tells the BSD developers that they didn't type enough lines of code that week.

If a corp wants a feature improved or implemented if it doesn't exist, they will have to pay someone and then they have to decide whether they will contribute it. If they do not, then they have to maintain a fork themselves which requires ongoing resources.

At the end of the day, I don't think it really matters that much. The corps are providing a service not a software application. If they weren't using BSD, they'd be using something else.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#34

Post by hansendc »

kyledrake wrote: post #2

This security tech usually ends up in other platforms too, strongly recommend donating to their work: https://www.openbsdfoundation.org/donations.html

There honestly isn't that much "tech" to speak of here. We were literally talking about "immutable" mappings last week in Linux land: https://lore.kernel.org/all/b4f0dca5-1d15-67f7-4600-9a0a91e9...

That said, this would be great to see in OpenBSD (or any other OS).

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#35

Post by [deleted] »

na85 wrote: post #29
kyledrake wrote: post #2

This security tech usually ends up in other platforms too, strongly recommend donating to their work: https://www.openbsdfoundation.org/donations.html

And thus the failure of BSD-style licensing is thrown into sharp relief: Why are these projects that are used by many large and extraordinarily profitable tech enterprises dependent on community donations? I recommend not donating, because to do so directly supports corporate parasitism.

[deleted]

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#36

Post by 7vUYjPAG2fnx7fd »

hggh wrote: post #28
kyledrake wrote: post #2

This security tech usually ends up in other platforms too, strongly recommend donating to their work: https://www.openbsdfoundation.org/donations.html

Too bad they don't accept peer-to-peer electronic cash

> Bitcoin donation via BitPay: The OpenBSD Foundation can accept donations in BTC via BitPay

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#37

Post by iE4mHBzmoYezwbx »

na85 wrote: post #29
kyledrake wrote: post #2

This security tech usually ends up in other platforms too, strongly recommend donating to their work: https://www.openbsdfoundation.org/donations.html

And thus the failure of BSD-style licensing is thrown into sharp relief: Why are these projects that are used by many large and extraordinarily profitable tech enterprises dependent on community donations? I recommend not donating, because to do so directly supports corporate parasitism.

Really? Their biggest donors are large and extraordinarily profitable tech enterprises. (Like Google, Microsoft, and Facebook)

And thus the success of BSD-style licensing is thrown into sharp relief. (Also the fact that you or I can go use it as much as we want for free and do whatever we want to it.)

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#38

Post by hansendc »

brynet wrote: post #12
jart wrote: post #9

Now all we need is for PROT_EXEC to not imply PROT_READ like Android.

There was some work done on XOM (eXecute-only-memory) for arm64, but on at least x86 there isn't a separate page table bit for just read permissions, so there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible. Amusingly the 80286 supported execute-only segments, but this was dropped from 32-bit x86. [0] It is possible on Intel in VM guests using EPT (Extended Page Tables), mlarkin@ experiment…

> there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible.

I'll also add a [2]:

[2] There's no way to do it in the page tables. But, if you have Protection Keys for Userspace (PKU), you can get it ... kinda. You can have a PROT_READ|PROT_EXEC mapping, assign it a pkey, then set PKEY_DISABLE_ACCESS in the PKRU register for that key. In fact, if you have a PKU CPU and you do an unadorned mmap(PROT_EXEC), the kernel will allocate you a pkey and do this under the covers FOR you. Anyone who can execute WRPKRU can easily undo this protection, but it's better than nothing.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#40

Post by brynet »

hansendc wrote: post #38
brynet wrote: post #12

Earlier quoted context omitted.

There was some work done on XOM (eXecute-only-memory) for arm64, but on at least x86 there isn't a separate page table bit for just read permissions, so there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible. Amusingly the 80286 supported execute-only segments, but this was dropped from 32-bit x86. [0] It is possible on Intel in VM guests using EPT (Extended Page Tables), mlarkin@ experiment…

> there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible. I'll also add a [2]: [2] There's no way to do it in the page tables. But, if you have Protection Keys for Userspace (PKU), you can get it ... kinda. You can have a PROT_READ|PROT_EXEC mapping, assign it a pkey, then set PKEY_DISABLE_ACCESS in the PKRU register for that key. In fact, if you have a PKU CPU and you do an unadorned mmap(P…

kinda indeed.

As far as I can tell Intel PKU was only on Server-CPUs/Xeons until at least the 11th Gen (only later models?), and AMD Zen 3.

OpenBSD doesn't support protection keys, in any case.

Post reply on HN