beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Userland/Libraries/LibImageDecoderClient/Client.cpp

104 lines
3.7 KiB
C++
Raw Normal View History

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 19:35:22 +00:00
/*
LibIPC: Stop exchanging client/server PIDs in greeting handshake The PIDs were used for sharing shbufs between processes, but now that we have migrated to file descriptor passing, we no longer need to know the PID of the other side.
2021-01-31 08:24:46 +00:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
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 19:35:22 +00:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
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 19:35:22 +00:00
*/
ImageDecoder: Use Core::AnonymousBuffer and Gfx::ShareableBitmap ...instead of sending shbufs back and forth. :^)
2021-01-16 22:58:57 +00:00
#include <LibCore/AnonymousBuffer.h>
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 19:35:22 +00:00
#include <LibImageDecoderClient/Client.h>
namespace ImageDecoderClient {
LibCore: Move Stream-based sockets into the `Core` namespace
2023-02-08 22:05:44 +00:00
Client::Client(NonnullOwnPtr<Core::LocalSocket> socket)
Userland: Rename IPC::ServerConnection=>IPC::ConnectionToServer This was done with CLion's automatic rename feature.
2022-02-25 10:27:37 +00:00
: IPC::ConnectionToServer<ImageDecoderClientEndpoint, ImageDecoderServerEndpoint>(*this, move(socket))
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 19:35:22 +00:00
{
}
LibWeb+LibImageDecoderClient: Reuse ImageDecoder service process The overhead from spawning a new ImageDecoder for every decoding job is way too large and causing other problems as well (#5421) Let's keep the same decoder open and reuse it as long as it's working.
2021-02-20 10:35:00 +00:00
void Client::die()
{
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
for (auto& [_, promise] : m_pending_decoded_images) {
promise->reject(Error::from_string_literal("ImageDecoder disconnected"));
}
m_pending_decoded_images.clear();
LibWeb+LibImageDecoderClient: Reuse ImageDecoder service process The overhead from spawning a new ImageDecoder for every decoding job is way too large and causing other problems as well (#5421) Let's keep the same decoder open and reuse it as long as it's working.
2021-02-20 10:35:00 +00:00
}
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
NonnullRefPtr<Core::Promise<DecodedImage>> Client::decode_image(ReadonlyBytes encoded_data, Function<ErrorOr<void>(DecodedImage&)> on_resolved, Function<void(Error&)> on_rejected, Optional<Gfx::IntSize> ideal_size, Optional<ByteString> mime_type)
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
{
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
auto promise = Core::Promise<DecodedImage>::construct();
if (on_resolved)
promise->on_resolution = move(on_resolved);
if (on_rejected)
promise->on_rejection = move(on_rejected);
if (encoded_data.is_empty()) {
promise->reject(Error::from_string_literal("No encoded data"));
return promise;
}
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
auto encoded_buffer_or_error = Core::AnonymousBuffer::create_with_size(encoded_data.size());
if (encoded_buffer_or_error.is_error()) {
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
dbgln("Could not allocate encoded buffer: {}", encoded_buffer_or_error.error());
promise->reject(encoded_buffer_or_error.release_error());
return promise;
LibGfx+Ladybird+Userland: Don't sniff for TGA images with only raw bytes Because TGA images don't have magic bytes as a signature to be detected, instead assume a sequence of ReadonlyBytes is a possible TGA image only if we are given a path so we could check the extension of the file and see if it's a TGA image. When we know the path of the file being loaded, we will try to first check its extension, and only if there's no match to a known decoder, based on simple extension lookup, then we would probe for other formats as usual with the normal sniffing method.
2023-01-15 19:50:32 +00:00
}
auto encoded_buffer = encoded_buffer_or_error.release_value();
memcpy(encoded_buffer.data<void>(), encoded_data.data(), encoded_data.size());
LibImageDecoderClient: Gracefully recover from decoder crashes :^) If the ImageDecoder service crashes while decoding an image for us, we now recover gracefully and simply return null. This shields the browser from bugs in our image decoders.
2021-02-20 10:33:34 +00:00
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
auto response = send_sync_but_allow_failure<Messages::ImageDecoderServer::DecodeImage>(move(encoded_buffer), ideal_size, mime_type);
if (!response) {
dbgln("ImageDecoder disconnected trying to decode image");
promise->reject(Error::from_string_literal("ImageDecoder disconnected"));
return promise;
LibImageDecoderClient: Gracefully recover from decoder crashes :^) If the ImageDecoder service crashes while decoding an image for us, we now recover gracefully and simply return null. This shields the browser from bugs in our image decoders.
2021-02-20 10:33:34 +00:00
}
ImageDecoder+LibImageDecoder+LibWeb: Support animations in ImageDecoder The ImageDecoder service now returns a list of image frames, each with a duration value. The code for in-process image decoding is removed from LibWeb, an all image decode requests are sent out-of-process to ImageDecoder. :^) This won't scale super well to very long and/or large animations, but we can work on improving that separately. The main goal here is simply to stop doing any image decoding inside LibWeb. Fixes #5165.
2021-01-29 21:30:48 +00:00
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
m_pending_decoded_images.set(response->image_id(), promise);
return promise;
}
Userland: Add try_* IPC handlers This enables calling auto-generated IPC methods in a way that doesn't crash the client if the peer disconnects.
2021-05-03 14:51:42 +00:00
ImageDecoder: Pass decoded images as Gfx::Bitmap over IPC Before this change, we were passing them as Gfx::ShareableBitmap. The problem is that shareable bitmaps keep their underlying file descriptor open, so that they can be shared again with someone else. When a Gfx::Bitmap is decoded from an IPC message, the file descriptor is closed and recovered immediately. This fixes an issue where we'd accumulate one file descriptor for every image decoded. This eventually led to descriptor starvation after enough images were loaded and still referenced at the same time.
2024-07-17 17:14:44 +00:00
void Client::did_decode_image(i64 image_id, bool is_animated, u32 loop_count, Vector<Optional<NonnullRefPtr<Gfx::Bitmap>>> const& bitmaps, Vector<u32> const& durations, Gfx::FloatPoint scale)
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
{
VERIFY(!bitmaps.is_empty());
auto maybe_promise = m_pending_decoded_images.take(image_id);
if (!maybe_promise.has_value()) {
dbgln("ImageDecoderClient: No pending image with ID {}", image_id);
return;
}
auto promise = maybe_promise.release_value();
LibImageDecoderClient: Decoded images with 0 frames are not successful Previously you could pass anything (e.g a text file) to ImageDecoder and it would "succeed" in decoding it and give you back a 0-frame result. Let's consider that state a failure instead.
2021-05-14 17:40:49 +00:00
ImageDecoder+LibImageDecoder+LibWeb: Support animations in ImageDecoder The ImageDecoder service now returns a list of image frames, each with a duration value. The code for in-process image decoding is removed from LibWeb, an all image decode requests are sent out-of-process to ImageDecoder. :^) This won't scale super well to very long and/or large animations, but we can work on improving that separately. The main goal here is simply to stop doing any image decoding inside LibWeb. Fixes #5165.
2021-01-29 21:30:48 +00:00
DecodedImage image;
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
image.is_animated = is_animated;
image.loop_count = loop_count;
image.scale = scale;
image.frames.ensure_capacity(bitmaps.size());
Userland: Return empty if ImageDecoder client receives an invalid frame This simplifies error checking for all the users of the ImageDecoder client.
2023-10-01 18:56:19 +00:00
for (size_t i = 0; i < bitmaps.size(); ++i) {
ImageDecoder: Pass decoded images as Gfx::Bitmap over IPC Before this change, we were passing them as Gfx::ShareableBitmap. The problem is that shareable bitmaps keep their underlying file descriptor open, so that they can be shared again with someone else. When a Gfx::Bitmap is decoded from an IPC message, the file descriptor is closed and recovered immediately. This fixes an issue where we'd accumulate one file descriptor for every image decoded. This eventually led to descriptor starvation after enough images were loaded and still referenced at the same time.
2024-07-17 17:14:44 +00:00
if (!bitmaps[i].has_value()) {
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
dbgln("ImageDecoderClient: Invalid bitmap for request {} at index {}", image_id, i);
promise->reject(Error::from_string_literal("Invalid bitmap"));
return;
}
Userland: Return empty if ImageDecoder client receives an invalid frame This simplifies error checking for all the users of the ImageDecoder client.
2023-10-01 18:56:19 +00:00
ImageDecoder: Pass decoded images as Gfx::Bitmap over IPC Before this change, we were passing them as Gfx::ShareableBitmap. The problem is that shareable bitmaps keep their underlying file descriptor open, so that they can be shared again with someone else. When a Gfx::Bitmap is decoded from an IPC message, the file descriptor is closed and recovered immediately. This fixes an issue where we'd accumulate one file descriptor for every image decoded. This eventually led to descriptor starvation after enough images were loaded and still referenced at the same time.
2024-07-17 17:14:44 +00:00
image.frames.empend(*bitmaps[i], durations[i]);
ImageDecoder+LibImageDecoder+LibWeb: Support animations in ImageDecoder The ImageDecoder service now returns a list of image frames, each with a duration value. The code for in-process image decoding is removed from LibWeb, an all image decode requests are sent out-of-process to ImageDecoder. :^) This won't scale super well to very long and/or large animations, but we can work on improving that separately. The main goal here is simply to stop doing any image decoding inside LibWeb. Fixes #5165.
2021-01-29 21:30:48 +00:00
}
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 20:23:16 +00:00
promise->resolve(move(image));
}
void Client::did_fail_to_decode_image(i64 image_id, String const& error_message)
{
auto maybe_promise = m_pending_decoded_images.take(image_id);
if (!maybe_promise.has_value()) {
dbgln("ImageDecoderClient: No pending image with ID {}", image_id);
return;
}
auto promise = maybe_promise.release_value();
dbgln("ImageDecoderClient: Failed to decode image with ID {}: {}", image_id, error_message);
// FIXME: Include the error message in the Error object when Errors are allowed to hold Strings
promise->reject(Error::from_string_literal("Image decoding failed or aborted"));
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 19:35:22 +00:00
}
}
Reference in a new issue Copy permalink