In order to link a user space executable we will need access to a few
section that are not normally used when linking the kernel.  Add these
sections when we have selected CONFIG_UNIKERNEL_LINUX.

Add case to not throw warnings for COMMON symbols from application code.

Make the KBUILD_VMLINUX_OBJS contain the application library when UKL is
enabled.

Co-developed-by: Thomas Unger <tommyu@bu.edu>
Signed-off-by: Thomas Unger <tommyu@bu.edu>
Co-developed-by: Matthew Boyd <mboydmcse@gmail.com>
Signed-off-by: Matthew Boyd <mboydmcse@gmail.com>
Co-developed-by: Eric B Munson <munsoner@bu.edu>
Signed-off-by: Eric B Munson <munsoner@bu.edu>
Co-developed-by: Ali Raza <aliraza@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

The kernel normally skips loading this segment as it is not inlcuded in
standard builds. However, when linked with an application in the Unikernel
configuration the segment will be present. Load PT_TLS when configured as a
unikernel.

Signed-off-by: Ali Raza <aliraza@bu.edu>

Because UKL removes the barrier between kernel and user space, we need to
track if we are executing application code or kernel code to ensure that we
take the appropriate actions on transitions. When we transition to kernel
code, we need to handle RCU and on the way to user code we need to check if
scheduling needs to happen, etc.  We cannot use the CS value from the stack
because it will always be set to the kernel value.  These functions will be
used in a later change to entry_64.S to identify the execution context for
the current thread.

Co-developed-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Co-developed-by: Ali Raza <aliraza@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

If a UKL application makes a system call, it won't go through with the
syscall assembly instruction. Instead, the application will use the call
instruction to go to the kernel entry point. Instead of adding checks to
the normal entry_SYSCALL_64 to see if we came here from a UKL task or a
normal application task, we create a totally new entry point called
ukl_entry_SYSCALL_64. This allows the normal entry point to be unchanged
and simplifies the UKL specific code as well.

ukl_entry_SYSCALL_64 is similar to entry_SYSCALL_64 except that it has to
populate %rcx with return address manually (syscall instruction does that
automatically for normal application tasks). This allows the pt_regs to be
correct. Also, we have to push the flags onto the user stack, because on
the return path, we first switch to user stack, then pop the flags and then
return. Popping the flags would restart interrupts, so we dont want to be
stuck on kernel stack when an interrupt hits. All this can be done with an
iret instruction, but call/iret pair performans way slower than a call/ret
pair.

Also, on the entry path, we make sure the context flag i.e., in_user is set
to 1 to indicate we are now in kernel context so any new interrupts dont
have to go through kernel entry code again. This is normally done with the
CS value on stack, but in UKL case that will always be a kernel value. On
the way back, the in_user is switched back to 2 to indicate that now
application context is being entered. All non-UKL tasks have the in_user
value set to 0.

The UKL application uses a slightly different value for CS, instead of
0x33, we use 0xC3. As most of the tests compare only the least significant
nibble, they behave as expected. The C value in the second nibble allows us
to distinguish between user space and UKL application code.

Rest of the code makes sure the above mentioned in_user context tracking is
done for all entry and exit cases i.e., for interrupts, exceptions etc.  If
its a UKL task, if in_user value is 2, we treat it as an application task,
and if it is 1, we treat it as coming from kernel context. We skip these
checks if in_user is 0.

swapgs_restore_regs_and_return_to_usermode changes also make sure that
in_user is correct and then we iret back.

Double fault handling is special case. Normally, if a user stack suffers a
page fault, hardware switches to a kernel stack and pushes a frame onto the
kernel stack. This switch only happens if the execution was in user
privilege level when the page fault occurred. For UKL, execution is always
in kernel level, so when the user stack suffers a page fault, no switch to
a pinned kernel stack happens, and hardware tries to push state on the
already faulting user stack. This generates a double fault. So we handle
this case in the double fault handler by assuming any double fault is
actually a user stack page fault. This can also be fixed by making all page
faults go through a pinned stack using the IST mechanism. We have tried and
tested that, but in the interest of touching as little code as possible, we
chose this option instead.

Co-developed-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Co-developed-by: Thomas Unger <tommyu@bu.edu>
Signed-off-by: Thomas Unger <tommyu@bu.edu>
Co-developed-by: Ali Raza <aliraza@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

When configured for UKL, access_ok needs to account for the unified address
space that is used by the kernel and the process being run. To do this,
they need to check the task struct field added earlier to determine where
the execution that is making the check is running. For a zero value, the
normal boundary definitions apply, but non-zero value indicates a UKL
thread and a shared address space should be assumed.

Signed-off-by: Ali Raza <aliraza@bu.edu>

… UKL

Normally, this check ensures that a kernel task has not ended up somehow
raising a page fault in the user part of address space. This is done by
checking if the CS value on stack. UKL always has the kernel value so this
check will always fail. This change makes sure that this check is only done
for non-UKL tasks by checking the in_user flag.

Signed-off-by: Ali Raza <aliraza@bu.edu>

For a UKL thread, returning to a signal handler is not done with iret or
sysret.  This means we need to adjust the way the return stack frame is
handled for these threads.  When constructing the signal frame, we leave
the previous frame in place because we will return to it from the signal
handler.  We also leave space for pushing eflags and the return address.
UKL threads will only use the __KERNEL_DS value in the ss register and 0xC3
in the cs register.

Co-developed-by: Eric B Munson <munsoner@bu.edu>
Signed-off-by: Eric B Munson <munsoner@bu.edu>
Co-developed-by: Ali Raza <aliraza@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

The UKL application still relies on much of the setup done to start a
standard user space process, so we still need to use much of that path.
There are several areas that the UKL application doesn't need or want so we
bypass them in the case of UKL. These are: ELF loading, because it is part
of the kernel image; and segments register value initialization.  We need
to record a starting location for the application heap, this normally is
the end of the ELF binary, once loaded. We choose an arbitrary low address
because there is no binary to load. We also hardcode the entry point for
the application to ukl__start which is the entry point for glibc plus the
'ukl_' prefix.

Suggested-by: Thomas Unger <tommyu@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

From: Eric B Munson <munsoner@bu.edu>

The UKL process might depend on setup that is to be done by user space
prior to its initialization.  We need a way to let userspace signal that it
is ready for the UKL process to run. We will have setup a special name for
this process in the kernel config and if this name is passed to exec that
will start the UKL process. This way, if user space setup is required we
can be sure that the process doesn't run until explicitly started.

If a more traditional unikernel execution is desired, set the init= boot
param to the UKL process name.

Suggested-by: Thomas Unger <tommyu@bu.edu>
Signed-off-by: Eric B Munson <munsoner@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

Add the KConfig file that will enable building UKL. Documentation
introduces the technical details for how UKL works and the motivations
behind why it is useful. Sample provides a simple program that still uses
the standard system call interface, but does not require a modified C
library.

Co-developed-by: Eric B Munson <munsoner@bu.edu>
Signed-off-by: Eric B Munson <munsoner@bu.edu>
Co-developed-by: Ali Raza <aliraza@bu.edu>
Signed-off-by: Ali Raza <aliraza@bu.edu>

The UKL Base model allows for the UKL process to interact with the
kernel by making a direct function call to the system call handler.
However, the system call handler does a number of book keeping jobs on
top of selecting the appropriate system call and routing the results
back such as RCU management and signal and scheduler checking. We may
not want these to happen on each invocation from the UKL process.

This patch introduces two related changes: the ability to control the
bypass of entry/exit code and symbols to be used to do the bypass. These
changes give the UKL process the ability to toggle bypass at runtime and
to control how often the standard entry/exit code is run. By default we
route every 11th call through the standard entry and exit to ensure that
the work done there still happens. The new symbols are generated as part
of the system call definition macros and are callable directly by the
UKL process.

Signed-off-by: Ali Raza <aliraza@bu.edu>

The IRET instruction is more expensive than RET and while syscalls are
now using RET instead of SYSRET, interrupts and faults still use the
more expensive exit when returning to the UKL process. Add a config
option that allows the kernel to use RET instead of IRET when returning
to the UKL process from an interrupt or fault.

Signed-off-by: Ali Raza <aliraza@bu.edu>

We want these to be available, but they are unlikley to be sent
upstream. We will control usage with a config option that will enable
them only when requested.

Signed-off-by: Eric B Munson <munsoner@bu.edu>

copy_from_user() checks the input address and the size to make sure that
the entire copied region have valid, user space addresses. When the
calling task is UKL, this may not be the case (e.g. the source address
is in UKL .data or .bss segments). The hacky solution is to accept the
full 64bits as valid source addresses for the UKL tasks.

Signed-off-by: Eric B. Munson <munsoner@bu.edu>

These features are incompatible with UKL. Disable them until we can find
a solution that will only disable them for the UKL tasks.

Signed-off-by: Eric B. Munson <munsoner@bu.edu>

We have send and recv msg which work on file descriptors, buffers, and
lengths, but older UKL experiments expect sendmsg to take an IOV
structure pointer. Add a tcp_write shortcut which will continue to take
the file descriptor and translate the buffer and length to an IOV.

Signed-off-by: Eric B Munson <munsoner@bu.edu>

Given that these are always streams (we know they are TCP connections)
there is no need to calculate the stream position, it is always 0.

Fix the creation of the msghdr structure.

Signed-off-by: Eric B Munson <munsoner@bu.edu>

All of the GDB scripts make references to to modules and the module code
in configured headers. However, if a kernel is built with MODULES=n, as
UKL is, this code will fail and prevent the loading of the other GDB
helper functions. There is probably a cleaner way that uses the config
values than this hammer, but modules are not going to be a thing for
UKL for now.

Signed-off-by: Eric B Munson <munsoner@bu.edu>