[GSoC 2024] Fixing IPC in WebKit | Haiku Project

Probably would be sufficient to make this a 64bit Integer and use randomization to allocate them.

It will be huge ABI break that will require to recompile everything.

Randomizing on it’s own would not be a abi break I think. Would maybe be sufficient.

Yes, randomization will reduce a risk of intentional attack, but not completely solve issue.

1 Like

So, the approach of creating a BLooper when creating the BMessenger turns out to be messier than I would like. So I’m going to go with the approach of expanding Haiku’s API slightly. I built a simple test, and it looks like this approach will work!



These changes are relatively minor and will not create any ABI compatibility problem. Therefore, the simplest solution is to change the classes where they are in Haiku, there is no reason so far to copy them. If we end up having ABI problems, sure, we can change our mind, but I don’t see why that would be the case here.


And it works!


In the first line WebProcess sends a message and in the third line NetworkProcess receives it! :tada:

I used a pair of two ports, each going the opposite direction, to communicate. It works well, I think I didn’t have to modify any of WebKit’s code, and the code is clean. Now it’s time to upload that Haiku API change.


Exciting! : D



1 Like

So, after a lot more thought about connections, I realized that it could actually be quite simple to use UNIX sockets. Previously, I thought that in order to use UNIX sockets, I would have to figure out how to make them work with BLoopers, but it now looks like that isn’t necessary.

Anyway, after some discussion, I’ve decided to try using them. If it works, then we’ll have little to no Haiku-specific code for connections, yielding a maintenance cost of very near zero!


IIRC we already have private accessor classes for these functions, i.e. have a look at BMessengerPrivate etc.

Yes, that’s what I used in the demo :slight_smile:

Of course, it’s not ideal to use a private API outside of Haiku. Ideally, we would make that public.

WebKit is on the borderline of Haiku. It is a separate codebase due to its size, but the goal is to have it as integrated in the OS as the other “kits” eventually. So, it would be acceptable in this case.

New APIs also tend to stay private (but exposed) for some time anyways (for example in libshared, although this has additional safeguards). This allows to experiment with them before committing to a stable API. At the moment the application ecosystem is small enough that rebuilding all the ones using private APIs is still acceptable. Someday that won’t be the case anymore.

Anyways, let’s see if using UNIX sockets can work, this would be the solution with less maintenance and, as far as I can see, no downsides.


And UNIX sockets do indeed work :slight_smile:

Time to clean up the code!


Great news !


The pull request has been merged!

Now I want to figure out what it takes to get things to display.


Now WebKit is trying to display things. It’s just encountering errors as it tries to do so. So here I go trying to fix them.

I’m also watching for a good place to write a blog post, since this is no longer about fixing IPC :wink:.