[haiku-commits] Re: haiku: hrev53362 - src/add-ons/kernel/drivers/graphics/radeon src/add-ons/kernel/drivers/graphics/3dfx src/add-ons/kernel/drivers/graphics/radeon_hd src/add-ons/kernel/drivers/graphics/neomagic headers/private/system

  • From: waddlesplash <waddlesplash@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 13 Aug 2019 09:40:49 -0400

On Tue, Aug 13, 2019, 9:07 AM Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:

Am 13/08/2019 um 14:06 schrieb waddlesplash:
On Tue, Aug 13, 2019, 4:20 AM Axel Dörfler <axeld@xxxxxxxxxxxxxxxx
<mailto:axeld@xxxxxxxxxxxxxxxx>> wrote:
8a0c9d52c629: OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA.
What's the point of this? For shared memory you now need this flag, but
it doesn't really improve security at all.
Huh? Why?

This makes it impossible for e.g. an application to clone the heap areas
of another application and, say, steal passwords, among many other
things. So I'm not sure what you mean here

Er, okay, point taken :-)
However, if you need to specify that flag, the area is still completely
open. And shared memory isn't exactly used sparsely, either.


It seems to be used relatively sparsely. app_server and media_server use it
to communicate, but the vast majority of allocated memory by both userland
and the kernel is not marked cloneable and is thus now protected.

What we'd need is to specify who can clone this area -- but doing so
would already imply that one wants it cloneable in the first place.
Yes, that would be the next step; but it would be pretty involved so I
have no plans to do it in the near future; the syscalls audit is
probably more significant for now.

Yeah, it would definitely be nice to have Haiku be more secure. But as
long as ports work how ports work, there is not that much we can do
about it...


What do you mean by this? Anyone can write to a port, but that shouldn't be
too much of a problem as long as the application on the other end does some
validation, right?

-waddlesplash

Other related posts: