third_party
/
virglrenderer
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2566 Commits
1 Branch
0 Tags
6.6 MiB
Tag: Branch: Tree: 8d452da883
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8d452da883'
${ noResults }
virglrenderer/server/render_worker.h

51 lines
1.4 KiB
Raw Normal View History Unescape

virgl: add render server The render server is a daemon that sits idle waiting for commands. When requested to create a context, it forks and creates the context in a subprocess. This isolates contexts from each other, from the server process, and from the client process. Because a context process can execute untrusted commands and depends on GPU drivers, the isolation should improve the security. There is also a multi-thread mode where each context is executed by a thread. This mode is used to ease debugging, but maybe someone will find a use case for it. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
/*
* Copyright 2021 Google LLC
* SPDX-License-Identifier: MIT
*/
#ifndef RENDER_WORKER_H
#define RENDER_WORKER_H
#include "render_common.h"
enum render_worker_jail_seccomp_filter {
/* seccomp_path is ignored and seccomp is disabled */
RENDER_WORKER_JAIL_SECCOMP_NONE,
/* seccomp_path is a file containing a BPF program */
RENDER_WORKER_JAIL_SECCOMP_BPF,
/* seccomp_path is a file containing a minijail policy */
RENDER_WORKER_JAIL_SECCOMP_MINIJAIL_POLICY,
RENDER_WORKER_JAIL_SECCOMP_MINIJAIL_POLICY_LOG,
};
struct render_worker_jail *
server: move worker count to render_worker_jail Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
render_worker_jail_create(int max_worker_count,
enum render_worker_jail_seccomp_filter seccomp_filter,
virgl: add render server The render server is a daemon that sits idle waiting for commands. When requested to create a context, it forks and creates the context in a subprocess. This isolates contexts from each other, from the server process, and from the client process. Because a context process can execute untrusted commands and depends on GPU drivers, the isolation should improve the security. There is also a multi-thread mode where each context is executed by a thread. This mode is used to ease debugging, but maybe someone will find a use case for it. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
const char *seccomp_path);
void
render_worker_jail_destroy(struct render_worker_jail *jail);
server: listen to SIGCHLD to reap workers No more confusing zombie processes. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
int
render_worker_jail_get_sigchld_fd(const struct render_worker_jail *jail);
bool
server: rework worker apis and internals Now that render_worker_jail tracks workers, the apis are simplified such that - render_worker_create forks a subprocess - render_worker_destroy kills a subprocess - render_worker_jail_reap_workers reaps all exited subprocesses Also add render_worker_jail_detach_workers that can be called by a forked subprocess to "detach" (free without killing/reaping) workers. v2: replace some checks for worker->{destroyed,reaped} by asserts (Ryan) Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1) Reviewed-by: Ryan Neph <ryanneph@google.com> (v1)
3 years ago
render_worker_jail_reap_workers(struct render_worker_jail *jail);
void
render_worker_jail_detach_workers(struct render_worker_jail *jail);
virgl: add render server The render server is a daemon that sits idle waiting for commands. When requested to create a context, it forks and creates the context in a subprocess. This isolates contexts from each other, from the server process, and from the client process. Because a context process can execute untrusted commands and depends on GPU drivers, the isolation should improve the security. There is also a multi-thread mode where each context is executed by a thread. This mode is used to ease debugging, but maybe someone will find a use case for it. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
struct render_worker *
render_worker_create(struct render_worker_jail *jail,
int (*thread_func)(void *thread_data),
void *thread_data,
size_t thread_data_size);
void
server: rework worker apis and internals Now that render_worker_jail tracks workers, the apis are simplified such that - render_worker_create forks a subprocess - render_worker_destroy kills a subprocess - render_worker_jail_reap_workers reaps all exited subprocesses Also add render_worker_jail_detach_workers that can be called by a forked subprocess to "detach" (free without killing/reaping) workers. v2: replace some checks for worker->{destroyed,reaped} by asserts (Ryan) Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1) Reviewed-by: Ryan Neph <ryanneph@google.com> (v1)
3 years ago
render_worker_destroy(struct render_worker_jail *jail, struct render_worker *worker);
virgl: add render server The render server is a daemon that sits idle waiting for commands. When requested to create a context, it forks and creates the context in a subprocess. This isolates contexts from each other, from the server process, and from the client process. Because a context process can execute untrusted commands and depends on GPU drivers, the isolation should improve the security. There is also a multi-thread mode where each context is executed by a thread. This mode is used to ease debugging, but maybe someone will find a use case for it. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
bool
server: rework worker apis and internals Now that render_worker_jail tracks workers, the apis are simplified such that - render_worker_create forks a subprocess - render_worker_destroy kills a subprocess - render_worker_jail_reap_workers reaps all exited subprocesses Also add render_worker_jail_detach_workers that can be called by a forked subprocess to "detach" (free without killing/reaping) workers. v2: replace some checks for worker->{destroyed,reaped} by asserts (Ryan) Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1) Reviewed-by: Ryan Neph <ryanneph@google.com> (v1)
3 years ago
render_worker_is_record(const struct render_worker *worker);
virgl: add render server The render server is a daemon that sits idle waiting for commands. When requested to create a context, it forks and creates the context in a subprocess. This isolates contexts from each other, from the server process, and from the client process. Because a context process can execute untrusted commands and depends on GPU drivers, the isolation should improve the security. There is also a multi-thread mode where each context is executed by a thread. This mode is used to ease debugging, but maybe someone will find a use case for it. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Ryan Neph <ryanneph@google.com>
3 years ago
#endif /* RENDER_WORKER_H */