2015-10-22 11:09:25 +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$");
|
|
|
|
|
|
|
|
#include <sys/param.h>
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
#include <sys/imgact.h>
|
2015-10-22 11:09:25 +00:00
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/proc.h>
|
|
|
|
#include <sys/sysent.h>
|
|
|
|
|
|
|
|
#include <vm/vm.h>
|
|
|
|
#include <vm/pmap.h>
|
|
|
|
|
|
|
|
#include <machine/frame.h>
|
|
|
|
#include <machine/pcb.h>
|
|
|
|
#include <machine/vmparam.h>
|
|
|
|
|
|
|
|
#include <compat/cloudabi/cloudabi_util.h>
|
|
|
|
|
|
|
|
#include <compat/cloudabi64/cloudabi64_syscall.h>
|
|
|
|
#include <compat/cloudabi64/cloudabi64_util.h>
|
|
|
|
|
|
|
|
extern const char *cloudabi64_syscallnames[];
|
|
|
|
extern struct sysent cloudabi64_sysent[];
|
|
|
|
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
static void
|
|
|
|
cloudabi64_proc_setregs(struct thread *td, struct image_params *imgp,
|
|
|
|
unsigned long stack)
|
|
|
|
{
|
|
|
|
struct trapframe *regs;
|
|
|
|
|
|
|
|
exec_setregs(td, imgp, stack);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The stack now contains a pointer to the TCB and the auxiliary
|
|
|
|
* vector. Let x0 point to the auxiliary vector, and set
|
|
|
|
* tpidr_el0 to the TCB.
|
|
|
|
*/
|
|
|
|
regs = td->td_frame;
|
2017-11-24 07:35:08 +00:00
|
|
|
regs->tf_x[0] =
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
stack + roundup(sizeof(cloudabi64_tcb_t), sizeof(register_t));
|
2017-11-26 14:45:56 +00:00
|
|
|
(void)cpu_set_user_tls(td, TO_PTR(stack));
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
}
|
|
|
|
|
2015-10-22 11:09:25 +00:00
|
|
|
static int
|
2017-06-12 21:03:23 +00:00
|
|
|
cloudabi64_fetch_syscall_args(struct thread *td)
|
2015-10-22 11:09:25 +00:00
|
|
|
{
|
2017-06-12 21:03:23 +00:00
|
|
|
struct trapframe *frame;
|
|
|
|
struct syscall_args *sa;
|
2015-10-22 11:09:25 +00:00
|
|
|
int i;
|
|
|
|
|
2017-06-12 21:03:23 +00:00
|
|
|
frame = td->td_frame;
|
|
|
|
sa = &td->td_sa;
|
|
|
|
|
2015-10-22 11:09:25 +00:00
|
|
|
/* Obtain system call number. */
|
|
|
|
sa->code = frame->tf_x[8];
|
|
|
|
if (sa->code >= CLOUDABI64_SYS_MAXSYSCALL)
|
|
|
|
return (ENOSYS);
|
|
|
|
sa->callp = &cloudabi64_sysent[sa->code];
|
2016-07-08 20:09:21 +00:00
|
|
|
sa->narg = sa->callp->sy_narg;
|
2015-10-22 11:09:25 +00:00
|
|
|
|
|
|
|
/* Fetch system call arguments. */
|
|
|
|
for (i = 0; i < MAXARGS; i++)
|
|
|
|
sa->args[i] = frame->tf_x[i];
|
|
|
|
|
|
|
|
/* Default system call return values. */
|
|
|
|
td->td_retval[0] = 0;
|
|
|
|
td->td_retval[1] = frame->tf_x[1];
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
cloudabi64_set_syscall_retval(struct thread *td, int error)
|
|
|
|
{
|
|
|
|
struct trapframe *frame = td->td_frame;
|
|
|
|
|
|
|
|
switch (error) {
|
|
|
|
case 0:
|
|
|
|
/* System call succeeded. */
|
|
|
|
frame->tf_x[0] = td->td_retval[0];
|
|
|
|
frame->tf_x[1] = td->td_retval[1];
|
|
|
|
frame->tf_spsr &= ~PSR_C;
|
|
|
|
break;
|
|
|
|
case ERESTART:
|
|
|
|
/* Restart system call. */
|
|
|
|
frame->tf_elr -= 4;
|
|
|
|
break;
|
|
|
|
case EJUSTRETURN:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* System call returned an error. */
|
|
|
|
frame->tf_x[0] = cloudabi_convert_errno(error);
|
|
|
|
frame->tf_spsr |= PSR_C;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
cloudabi64_schedtail(struct thread *td)
|
|
|
|
{
|
|
|
|
struct trapframe *frame = td->td_frame;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initial register values for processes returning from fork.
|
|
|
|
* Make sure that we only set these values when forking, not
|
|
|
|
* when creating a new thread.
|
|
|
|
*/
|
|
|
|
if ((td->td_pflags & TDP_FORKING) != 0) {
|
|
|
|
frame->tf_x[0] = CLOUDABI_PROCESS_CHILD;
|
|
|
|
frame->tf_x[1] = td->td_tid;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
int
|
2015-10-22 11:09:25 +00:00
|
|
|
cloudabi64_thread_setregs(struct thread *td,
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
const cloudabi64_threadattr_t *attr, uint64_t tcb)
|
2015-10-22 11:09:25 +00:00
|
|
|
{
|
|
|
|
struct trapframe *frame;
|
|
|
|
stack_t stack;
|
|
|
|
|
|
|
|
/* Perform standard register initialization. */
|
2016-08-24 10:13:18 +00:00
|
|
|
stack.ss_sp = TO_PTR(attr->stack);
|
2017-01-17 22:05:52 +00:00
|
|
|
stack.ss_size = attr->stack_len;
|
2016-08-24 10:13:18 +00:00
|
|
|
cpu_set_upcall(td, TO_PTR(attr->entry_point), NULL, &stack);
|
2015-10-22 11:09:25 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Pass in the thread ID of the new thread and the argument
|
|
|
|
* pointer provided by the parent thread in as arguments to the
|
|
|
|
* entry point.
|
|
|
|
*/
|
|
|
|
frame = td->td_frame;
|
|
|
|
frame->tf_x[0] = td->td_tid;
|
|
|
|
frame->tf_x[1] = attr->argument;
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
|
|
|
|
/* Set up TLS. */
|
2017-11-26 14:53:56 +00:00
|
|
|
return (cpu_set_user_tls(td, TO_PTR(tcb)));
|
2015-10-22 11:09:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct sysentvec cloudabi64_elf_sysvec = {
|
|
|
|
.sv_size = CLOUDABI64_SYS_MAXSYSCALL,
|
|
|
|
.sv_table = cloudabi64_sysent,
|
|
|
|
.sv_fixup = cloudabi64_fixup,
|
|
|
|
.sv_name = "CloudABI ELF64",
|
|
|
|
.sv_coredump = elf64_coredump,
|
|
|
|
.sv_pagesize = PAGE_SIZE,
|
|
|
|
.sv_minuser = VM_MIN_ADDRESS,
|
|
|
|
.sv_maxuser = VM_MAXUSER_ADDRESS,
|
|
|
|
.sv_stackprot = VM_PROT_READ | VM_PROT_WRITE,
|
|
|
|
.sv_copyout_strings = cloudabi64_copyout_strings,
|
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on
operating systems cannot be modified easily (Windows, Mac OS X). The
idea is that we want to just run them without any sandboxing. Now
that CloudABI executables are PIE, this is already a bit easier, but TLS
is still problematic:
- CloudABI executables want to write to the %fs, which typically
requires extra system calls by the emulator every time it needs to
switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it
also becomes harder for the emulator to store a backup of the old
value of %fs. To solve this, let's no longer overwrite %fs, but just
%fs:0.
As CloudABI's C library does not use a TCB, this space can now be used
by an emulator to keep track of its internal state. The executable can
now safely overwrite %fs:0, as long as it makes sure that the TCB is
copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts,
only containing a bogus TCB. We don't really care about its contents on
FreeBSD.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5836
2016-04-06 11:11:31 +00:00
|
|
|
.sv_setregs = cloudabi64_proc_setregs,
|
2016-03-09 18:38:30 +00:00
|
|
|
.sv_flags = SV_ABI_CLOUDABI | SV_CAPSICUM | SV_LP64,
|
2015-10-22 11:09:25 +00:00
|
|
|
.sv_set_syscall_retval = cloudabi64_set_syscall_retval,
|
|
|
|
.sv_fetch_syscall_args = cloudabi64_fetch_syscall_args,
|
|
|
|
.sv_syscallnames = cloudabi64_syscallnames,
|
|
|
|
.sv_schedtail = cloudabi64_schedtail,
|
|
|
|
};
|
|
|
|
|
|
|
|
INIT_SYSENTVEC(elf_sysvec, &cloudabi64_elf_sysvec);
|
|
|
|
|
|
|
|
Elf64_Brandinfo cloudabi64_brand = {
|
|
|
|
.brand = ELFOSABI_CLOUDABI,
|
|
|
|
.machine = EM_AARCH64,
|
|
|
|
.sysvec = &cloudabi64_elf_sysvec,
|
2017-03-22 22:28:13 +00:00
|
|
|
.flags = BI_CAN_EXEC_DYN | BI_BRAND_ONLY_STATIC,
|
2015-10-22 11:09:25 +00:00
|
|
|
};
|