d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
9324dcb395
freebsd-skq/sys/compat/cloudabi/cloudabi_proc.c

148 lines
4.2 KiB
C
Raw Normal View History

Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
/*-
* Copyright (c) 2015 Nuxi, https://nuxi.nl/
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Implement normal and abnormal process termination. CloudABI does not provide an explicit kill() system call, for the reason that there is no access to the global process namespace. Instead, it offers a raise() system call that can at least be used to terminate the process abnormally. CloudABI does not support installing signal handlers. CloudABI's raise() system call should behave as if the default policy is set up. Call into kern_sigaction(SIG_DFL) before calling sys_kill() to force this. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-11 19:41:31 +00:00
#include <sys/param.h>
Limit rights on process descriptors. On CloudABI, the rights bits returned by cap_rights_get() match up with the operations that you can actually perform on the file descriptor. Limiting the rights is good, because it makes it easier to get uniform behaviour across different operating systems. If process descriptors on FreeBSD would suddenly gain support for any new file operation, this wouldn't become exposed to CloudABI processes without first extending the rights. Extend fork1() to gain a 'struct filecaps' argument that allows you to construct process descriptors with custom rights. Use this in cloudabi_sys_proc_fork() to limit the rights to just fstat() and pdwait(). Obtained from: https://github.com/NuxiNL/freebsd
2015-07-31 10:21:58 +00:00
#include <sys/capsicum.h>
#include <sys/filedesc.h>
Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079
2015-07-16 07:05:42 +00:00
#include <sys/imgact.h>
Let proc_raise() call into pksignal() directly. Summary: As discussed with kib@ in response to r285404, don't call into kern_sigaction() within proc_raise() to reset the signal to the default action before delivery. We'd better do that during image execution. Change the code to simply use pksignal(), so we don't waste cycles on functions like pfind() to look up the currently running process itself. Test Plan: This change has also been pushed into the cloudabi branch on GitHub. The raise() tests still seem to pass. Reviewers: kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3076
2015-07-14 12:16:14 +00:00
#include <sys/lock.h>
Add DECLARE_MODULE() to the "cloudabi" kernel module. This kernel module does not require any explicit initialization, but a module declaration is needed to let the "cloudabi64" kernel module automatically pull this in. Obtained from: https://github.com/NuxiNL/freebsd
2015-08-05 16:45:47 +00:00
#include <sys/module.h>
Let proc_raise() call into pksignal() directly. Summary: As discussed with kib@ in response to r285404, don't call into kern_sigaction() within proc_raise() to reset the signal to the default action before delivery. We'd better do that during image execution. Change the code to simply use pksignal(), so we don't waste cycles on functions like pfind() to look up the currently running process itself. Test Plan: This change has also been pushed into the cloudabi branch on GitHub. The raise() tests still seem to pass. Reviewers: kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3076
2015-07-14 12:16:14 +00:00
#include <sys/mutex.h>
Implement normal and abnormal process termination. CloudABI does not provide an explicit kill() system call, for the reason that there is no access to the global process namespace. Instead, it offers a raise() system call that can at least be used to terminate the process abnormally. CloudABI does not support installing signal handlers. CloudABI's raise() system call should behave as if the default policy is set up. Call into kern_sigaction(SIG_DFL) before calling sys_kill() to force this. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-11 19:41:31 +00:00
#include <sys/proc.h>
Let proc_raise() call into pksignal() directly. Summary: As discussed with kib@ in response to r285404, don't call into kern_sigaction() within proc_raise() to reset the signal to the default action before delivery. We'd better do that during image execution. Change the code to simply use pksignal(), so we don't waste cycles on functions like pfind() to look up the currently running process itself. Test Plan: This change has also been pushed into the cloudabi branch on GitHub. The raise() tests still seem to pass. Reviewers: kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3076
2015-07-14 12:16:14 +00:00
#include <sys/signalvar.h>
Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079
2015-07-16 07:05:42 +00:00
#include <sys/syscallsubr.h>
Make forking of CloudABI processes work. Just like FreeBSD+Capsicum, CloudABI uses process descriptors. Return the file descriptor number to the parent process. To the child process we both return a special value for the file descriptor number (CLOUDABI_PROCESS_CHILD). We also return the thread ID of the new thread in the copied process, so the threading library can reinitialize itself. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-20 13:46:22 +00:00
#include <sys/unistd.h>
Implement normal and abnormal process termination. CloudABI does not provide an explicit kill() system call, for the reason that there is no access to the global process namespace. Instead, it offers a raise() system call that can at least be used to terminate the process abnormally. CloudABI does not support installing signal handlers. CloudABI's raise() system call should behave as if the default policy is set up. Call into kern_sigaction(SIG_DFL) before calling sys_kill() to force this. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-11 19:41:31 +00:00
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
#include <compat/cloudabi/cloudabi_proto.h>
Make forking of CloudABI processes work. Just like FreeBSD+Capsicum, CloudABI uses process descriptors. Return the file descriptor number to the parent process. To the child process we both return a special value for the file descriptor number (CLOUDABI_PROCESS_CHILD). We also return the thread ID of the new thread in the copied process, so the threading library can reinitialize itself. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-20 13:46:22 +00:00
#include <compat/cloudabi/cloudabi_syscalldefs.h>
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
int
cloudabi_sys_proc_exec(struct thread *td,
struct cloudabi_sys_proc_exec_args *uap)
{
Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079
2015-07-16 07:05:42 +00:00
struct image_args args;
Don't forget to invoke pre_execve() and post_execve(). CloudABI's proc_exec() was implemented before r282708 introduced pre_execve() and post_execve(). Sync up by adding these missing calls.
2015-08-17 13:07:12 +00:00
struct vmspace *oldvmspace;
Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079
2015-07-16 07:05:42 +00:00
int error;
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
Don't forget to invoke pre_execve() and post_execve(). CloudABI's proc_exec() was implemented before r282708 introduced pre_execve() and post_execve(). Sync up by adding these missing calls.
2015-08-17 13:07:12 +00:00
error = pre_execve(td, &oldvmspace);
if (error != 0)
return (error);
Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079
2015-07-16 07:05:42 +00:00
error = exec_copyin_data_fds(td, &args, uap->data, uap->datalen,
uap->fds, uap->fdslen);
if (error == 0) {
args.fd = uap->fd;
error = kern_execve(td, &args, NULL);
}
Don't forget to invoke pre_execve() and post_execve(). CloudABI's proc_exec() was implemented before r282708 introduced pre_execve() and post_execve(). Sync up by adding these missing calls.
2015-08-17 13:07:12 +00:00
post_execve(td, error, oldvmspace);
Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079
2015-07-16 07:05:42 +00:00
return (error);
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
}
int
cloudabi_sys_proc_exit(struct thread *td,
struct cloudabi_sys_proc_exit_args *uap)
{
The si_status field of the siginfo_t, provided by the waitid(2) and SIGCHLD signal, should keep full 32 bits of the status passed to the _exit(2). Split the combined p_xstat of the struct proc into the separate exit status p_xexit for normal process exit, and signalled termination information p_xsig. Kernel-visible macro KW_EXITCODE() reconstructs old p_xstat from p_xexit and p_xsig. p_xexit contains complete status and copied out into si_status. Requested by: Joerg Schilling Reviewed by: jilles (previous version), pho Tested by: pho Sponsored by: The FreeBSD Foundation
2015-07-18 09:02:50 +00:00
exit1(td, uap->rval, 0);
Implement normal and abnormal process termination. CloudABI does not provide an explicit kill() system call, for the reason that there is no access to the global process namespace. Instead, it offers a raise() system call that can at least be used to terminate the process abnormally. CloudABI does not support installing signal handlers. CloudABI's raise() system call should behave as if the default policy is set up. Call into kern_sigaction(SIG_DFL) before calling sys_kill() to force this. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-11 19:41:31 +00:00
/* NOTREACHED */
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
}
int
cloudabi_sys_proc_fork(struct thread *td,
struct cloudabi_sys_proc_fork_args *uap)
{
fork: pass arguments to fork1 in a dedicated structure Suggested by: kib
2016-02-04 04:22:18 +00:00
struct fork_req fr;
Limit rights on process descriptors. On CloudABI, the rights bits returned by cap_rights_get() match up with the operations that you can actually perform on the file descriptor. Limiting the rights is good, because it makes it easier to get uniform behaviour across different operating systems. If process descriptors on FreeBSD would suddenly gain support for any new file operation, this wouldn't become exposed to CloudABI processes without first extending the rights. Extend fork1() to gain a 'struct filecaps' argument that allows you to construct process descriptors with custom rights. Use this in cloudabi_sys_proc_fork() to limit the rights to just fstat() and pdwait(). Obtained from: https://github.com/NuxiNL/freebsd
2015-07-31 10:21:58 +00:00
struct filecaps fcaps = {};
Make forking of CloudABI processes work. Just like FreeBSD+Capsicum, CloudABI uses process descriptors. Return the file descriptor number to the parent process. To the child process we both return a special value for the file descriptor number (CLOUDABI_PROCESS_CHILD). We also return the thread ID of the new thread in the copied process, so the threading library can reinitialize itself. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-20 13:46:22 +00:00
int error, fd;
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
Use CAP_EVENT instead of CAP_PDWAIT. The cloudlibc pdwait() function ends up using FreeBSD's kqueue() in combination with EVFILT_PROCDESC. This depends on CAP_EVENT -- not CAP_PDWAIT. Obtained from: https://github.com/NuxiNL/freebsd
2015-08-12 11:07:03 +00:00
cap_rights_init(&fcaps.fc_rights, CAP_FSTAT, CAP_EVENT);
fork: pass arguments to fork1 in a dedicated structure Suggested by: kib
2016-02-04 04:22:18 +00:00
bzero(&fr, sizeof(fr));
fr.fr_flags = RFFDG | RFPROC | RFPROCDESC;
fr.fr_pd_fd = &fd;
fr.fr_pd_fcaps = &fcaps;
error = fork1(td, &fr);
Make forking of CloudABI processes work. Just like FreeBSD+Capsicum, CloudABI uses process descriptors. Return the file descriptor number to the parent process. To the child process we both return a special value for the file descriptor number (CLOUDABI_PROCESS_CHILD). We also return the thread ID of the new thread in the copied process, so the threading library can reinitialize itself. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-20 13:46:22 +00:00
if (error != 0)
return (error);
/* Return the file descriptor to the parent process. */
td->td_retval[0] = fd;
return (0);
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
}
int
cloudabi_sys_proc_raise(struct thread *td,
struct cloudabi_sys_proc_raise_args *uap)
{
Implement normal and abnormal process termination. CloudABI does not provide an explicit kill() system call, for the reason that there is no access to the global process namespace. Instead, it offers a raise() system call that can at least be used to terminate the process abnormally. CloudABI does not support installing signal handlers. CloudABI's raise() system call should behave as if the default policy is set up. Call into kern_sigaction(SIG_DFL) before calling sys_kill() to force this. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-11 19:41:31 +00:00
static const int signals[] = {
[CLOUDABI_SIGABRT] = SIGABRT,
[CLOUDABI_SIGALRM] = SIGALRM,
[CLOUDABI_SIGBUS] = SIGBUS,
[CLOUDABI_SIGCHLD] = SIGCHLD,
[CLOUDABI_SIGCONT] = SIGCONT,
[CLOUDABI_SIGFPE] = SIGFPE,
[CLOUDABI_SIGHUP] = SIGHUP,
[CLOUDABI_SIGILL] = SIGILL,
[CLOUDABI_SIGINT] = SIGINT,
[CLOUDABI_SIGKILL] = SIGKILL,
[CLOUDABI_SIGPIPE] = SIGPIPE,
[CLOUDABI_SIGQUIT] = SIGQUIT,
[CLOUDABI_SIGSEGV] = SIGSEGV,
[CLOUDABI_SIGSTOP] = SIGSTOP,
[CLOUDABI_SIGSYS] = SIGSYS,
[CLOUDABI_SIGTERM] = SIGTERM,
[CLOUDABI_SIGTRAP] = SIGTRAP,
[CLOUDABI_SIGTSTP] = SIGTSTP,
[CLOUDABI_SIGTTIN] = SIGTTIN,
[CLOUDABI_SIGTTOU] = SIGTTOU,
[CLOUDABI_SIGURG] = SIGURG,
[CLOUDABI_SIGUSR1] = SIGUSR1,
[CLOUDABI_SIGUSR2] = SIGUSR2,
[CLOUDABI_SIGVTALRM] = SIGVTALRM,
[CLOUDABI_SIGXCPU] = SIGXCPU,
[CLOUDABI_SIGXFSZ] = SIGXFSZ,
};
Let proc_raise() call into pksignal() directly. Summary: As discussed with kib@ in response to r285404, don't call into kern_sigaction() within proc_raise() to reset the signal to the default action before delivery. We'd better do that during image execution. Change the code to simply use pksignal(), so we don't waste cycles on functions like pfind() to look up the currently running process itself. Test Plan: This change has also been pushed into the cloudabi branch on GitHub. The raise() tests still seem to pass. Reviewers: kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3076
2015-07-14 12:16:14 +00:00
ksiginfo_t ksi;
struct proc *p;
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
Let proc_raise() call into pksignal() directly. Summary: As discussed with kib@ in response to r285404, don't call into kern_sigaction() within proc_raise() to reset the signal to the default action before delivery. We'd better do that during image execution. Change the code to simply use pksignal(), so we don't waste cycles on functions like pfind() to look up the currently running process itself. Test Plan: This change has also been pushed into the cloudabi branch on GitHub. The raise() tests still seem to pass. Reviewers: kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3076
2015-07-14 12:16:14 +00:00
if (uap->sig >= nitems(signals) || signals[uap->sig] == 0) {
/* Invalid signal, or the null signal. */
return (uap->sig == 0 ? 0 : EINVAL);
Implement normal and abnormal process termination. CloudABI does not provide an explicit kill() system call, for the reason that there is no access to the global process namespace. Instead, it offers a raise() system call that can at least be used to terminate the process abnormally. CloudABI does not support installing signal handlers. CloudABI's raise() system call should behave as if the default policy is set up. Call into kern_sigaction(SIG_DFL) before calling sys_kill() to force this. Obtained from: https://github.com/NuxiNL/freebsd
2015-07-11 19:41:31 +00:00
}
Let proc_raise() call into pksignal() directly. Summary: As discussed with kib@ in response to r285404, don't call into kern_sigaction() within proc_raise() to reset the signal to the default action before delivery. We'd better do that during image execution. Change the code to simply use pksignal(), so we don't waste cycles on functions like pfind() to look up the currently running process itself. Test Plan: This change has also been pushed into the cloudabi branch on GitHub. The raise() tests still seem to pass. Reviewers: kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3076
2015-07-14 12:16:14 +00:00
p = td->td_proc;
ksiginfo_init(&ksi);
ksi.ksi_signo = signals[uap->sig];
ksi.ksi_code = SI_USER;
ksi.ksi_pid = p->p_pid;
ksi.ksi_uid = td->td_ucred->cr_ruid;
PROC_LOCK(p);
pksignal(p, ksi.ksi_signo, &ksi);
PROC_UNLOCK(p);
return (0);
Import the CloudABI datatypes and create a system call table. CloudABI is a pure capability-based runtime environment for UNIX. It works similar to Capsicum, except that processes already run in capabilities mode on startup. All functionality that conflicts with this model has been omitted, making it a compact binary interface that can be supported by other operating systems without too much effort. CloudABI is 'secure by default'; the idea is that it should be safe to run arbitrary third-party binaries without requiring any explicit hardware virtualization (Bhyve) or namespace virtualization (Jails). The rights of an application are purely determined by the set of file descriptors that you grant it on startup. The datatypes and constants used by CloudABI's C library (cloudlibc) are defined in separate files called syscalldefs_mi.h (pointer size independent) and syscalldefs_md.h (pointer size dependent). We import these files in sys/contrib/cloudabi and wrap around them in cloudabi*_syscalldefs.h. We then add stubs for all of the system calls in sys/compat/cloudabi or sys/compat/cloudabi64, depending on whether the system call depends on the pointer size. We only have nine system calls that depend on the pointer size. If we ever want to support 32-bit binaries, we can simply add sys/compat/cloudabi32 and implement these nine system calls again. The next step is to send in code reviews for the individual system call implementations, but also add a sysentvec, to allow CloudABI executabled to be started through execve(). More information about CloudABI: - GitHub: https://github.com/NuxiNL/cloudlibc - Talk at BSDCan: https://www.youtube.com/watch?v=SVdF84x1EdA Differential Revision: https://reviews.freebsd.org/D2848 Reviewed by: emaste, brooks Obtained from: https://github.com/NuxiNL/freebsd
2015-07-09 07:20:15 +00:00
}
Add DECLARE_MODULE() to the "cloudabi" kernel module. This kernel module does not require any explicit initialization, but a module declaration is needed to let the "cloudabi64" kernel module automatically pull this in. Obtained from: https://github.com/NuxiNL/freebsd
2015-08-05 16:45:47 +00:00
MODULE_VERSION(cloudabi, 1);
Reference in New Issue Copy Permalink