Date: Thu, 16 Jul 2015 08:20:52 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: ed@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: FreeBSD_HEAD_i386 - Build #592 - Fixed Message-ID: <392416010.3.1437034853018.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <510929818.1.1437023860876.JavaMail.jenkins@jenkins-9.freebsd.org> References: <510929818.1.1437023860876.JavaMail.jenkins@jenkins-9.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD_HEAD_i386 - Build #592 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/592/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/592/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/592/console Change summaries: 285622 by ed: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?392416010.3.1437034853018.JavaMail.jenkins>