Commit graph

5 commits

Author SHA1 Message Date
Tom
7399874479 AK: Add trivial structure validation to SharedBuffer
If we're sharing buffers, we only want to share trivial structures
as anything else could potentially share internal pointers, which
most likely is going to cause problems due to different address
spaces.

Fix the GUI::SystemTheme structure, which was not trivial, which
is now caught at compile time.

Fixes #3650
2020-10-02 15:38:07 +02:00
Ben Wiederhake
934d4d4033 Meta+Services: Make clang-format-10 clean 2020-09-25 21:18:17 +02:00
Andreas Kling
aba793fb3e LibIPC: Share most of the code between {Client,Server}Connection
This patch introduces IPC::Connection which becomes the new base class
of ClientConnection and ServerConnection. Most of the functionality
has been hoisted up to the base class since almost all of it is useful
on both sides.

This gives us the ability to send synchronous messages in both
directions, which is needed for the WebContent server process.
Unlike other servers, WebContent does not mind blocking on a response
from its client.
2020-09-12 14:49:29 +02:00
Andreas Kling
94ddb07e58 LibIPC+Services: Make ClientConnection take socket as NonnullRefPtr
This avoids getting into the awkward situation where the socket is
still part-owned by main() in multi-instance service. Also it just
reads nicer.
2020-07-06 13:30:11 +02:00
Andreas Kling
e3782a7f99 ImageDecoder: Add a new service for out-of-process image decoding :^)
The new ImageDecoder service (available for members of "image" via
/tmp/portal/image) allows you to decode images in a separate process.

This will allow programs to confidently load untrusted images, since
the bulk of the security concerns are sandboxed to a separate process.

The only API right now is a synchronous IPC DecodeImage() call that
takes a shbuf with encoded image data and returns a shared buffer and
metadata for the decoded image.

It also comes with a very simple library for interfacing with the
ImageDecoder service: LibImageDecoderClient. The name is a bit of a
mouthful but I guess we can rename it later if we think of something
nicer to call it.

There's obviously a bit of overhead to spawning a separate process
for every image decode, so this is mostly only appropriate for
untrusted images (e.g stuff downloaded from the web) and not necessary
for trusted local images (e.g stuff in /res)
2020-06-22 21:47:00 +02:00