cinap_lenrek [Mon, 7 Nov 2016 21:20:10 +0000 (22:20 +0100)]
kernel/qio: big cleanup of qio functions
remove bl2mem(), it is broken. a fault while copying to memory
yields a partially freed block list. it can be simply replaced
by readblist() and freeblist(), which we also use for qcopy()
now.
remove mem2bl(), and handle putting back remainer from a short
read internally (splitblock()) avoiding the releasing and re-
acquiering of the ilock.
always attempt to free blocks outside of the ilock.
have qaddlist() return the number of bytes enqueued, which
avoids walking the block list twice.
cinap_lenrek [Mon, 7 Nov 2016 21:08:21 +0000 (22:08 +0100)]
devloopback: simplify loopoput()
remove unneeded waserror() block, loopoput is alled from
loopbackbwrite only so we will always get called with a
*single* block, so the concatblock() is not needed.
cinap_lenrek [Sat, 5 Nov 2016 17:26:12 +0000 (18:26 +0100)]
devmnt: avoid memory copies of I/O rpc buffer by using bwrite()
given that devmnt will almost always write into a pipe
or a network connection, which supports te bwrite routine,
we can avoid the memory copy that would have been done by
devbwrite(). this also means the i/o buffer for writes
will get freed sooner without having to wait for the 9p
rpc to get a response, saving memory.
theres one case where we have to keep the rpc arround and
that is when we write to a cached file, as we want to update
the cache with the data that was written, but the user buffer
cannot be trusted to stay the same during the rpc.
cinap_lenrek [Sun, 30 Oct 2016 22:30:13 +0000 (23:30 +0100)]
8c: fix double compiling FNX complex lvalue in cgen64()
sugen() calls cgen64() speculatively so that when cgen64() returns
zero, it will fall back and compile 64-bit copy.
the bug was that cgen64() compiled the left hand side and then recursively
called cgen64() again, which didnt handle the memory copy so it returned
zero and sugen() would compile the left hand side again resulting in two
function calls being emited.
cinap_lenrek [Mon, 24 Oct 2016 18:56:11 +0000 (20:56 +0200)]
fix bugs and cleanup cryptsetup code
devfs:
- fix memory leak in devfs leaking the aes key
- allocate aes-xts cipher state in secure memory
- actually check if the hexkey got fully parsed
cryptsetup:
- get rid of stupid "type YES" prompt
- use genrandom() to generate salts and keys
- rewrite cryptsetup to use common pbkdf2 and readcons routines
- fix alot of error handling and simplify the code
- move cryptsetup command to disk/cryptsetup
- update cryptsetup(8) manual page
cinap_lenrek [Sun, 23 Oct 2016 02:09:27 +0000 (04:09 +0200)]
pc/archacpi: don't do acpi initialization in the kernel, provide generic acpimem routines
get rid of _INI and _REG method calls, this is not full acpi environment
anyway and all we really want todo at kernel boot time is figuring out
the interrupt routing. aux/acpi can try to enable more stuff if it needs
to later when battery status desired.
dont snoop memory space regions in amlmapio(), this is just wrong as
amlmapio() is *lazily* mapping regions as they are accessed, so the
range table would never be really complete. instead, we provide generic
access to the physical address space, excluding kernel and user memory
with acpimem file.
we cannot retry posts and we do not know for sure if a
post had any side effect when we got no status, so always
make a new connection for a post request.
kernel: rekey chacha state on each randomread() invocation
we can encrypt the 256 bit chacha key on each invocation
making it hard to reconstruct previous outputs of the
generator given the current state (backtracking resiatance).
kernel: xoroshiro128+ generator for rand()/nrand()
the kernels custom rand() and nrand() functions where not working
as specified in rand(2). now we just use libc's rand() and nrand()
functions but provide a custom lrand() impelmenting the xoroshiro128+
algorithm as proposed by aiju.
we now access the user buffer in randomread() outside of the lock,
only copying and advancing the chacha state under the lock. this
means we can use randomread() within the fault handling path now
without fearing deadlock. this also allows multiple readers to
generate random numbers in parallel.
kernel: tsemacquire() use MACHP(0)->ticks for time delta
we might wake up on a different cpu after the sleep so
delta from machX->ticks - machY->ticks can become negative
giving spurious timeouts. to avoid this always use the
same mach 0 tick counter for the delta.
devcap: timeout capabilities after a minute, fix memory leak, paranoia
the manpage states that capabilities time out after a minute,
so we add ticks field into the Caphash struct and record the
time when the capability was inserted. freeing old capabilities
is handled in trimcaps(), which makes room for one extra cap
and frees timed out ones.
we also limit the capuse write size to less than 1024 bytes to
prevent denial of service as we have to copy the user buffer.
(memory exhaustion).
we have to check the from user *before* attempting to remove
the capability! the wrong user shouldnt be able to change any
state. this fixes the memory leak of the caphash.
do the hash comparsion with tsmemcmp(), avoiding timing
side channels.
allocate the capabilities in secret memory pool to prevent
debugger access.