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.
some code that reproduced the issue:
#include <u.h>
#include <libc.h>
typedef struct
{
char x[10];
vlong a;
} X;
X a;
X *f(void) { return &a; }
void
main(int argc, char *argv[])
{
f()->a = a.a;
}
producing:
TEXT f+0(SB),0,$0
MOVL $a+0(SB),AX
RET ,
RET ,
TEXT main+0(SB),0,$0
CALL ,f+0(SB)
CALL ,f+0(SB) <- bug
MOVL AX,CX
LEAL a+12(SB),DX
MOVL (DX),AX
MOVL AX,12(CX)
MOVL 4(DX),AX
MOVL AX,16(CX)
RET ,
GLOBL a+0(SB),$20
END ,
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
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.
when dragging a window edge, allow one to slide to a corner
or slide from corner to corner (usefull when inverting).
also make sure the right or bottom of the rectangle returned
by whichrect() is not outside of the screen (which makes
drawing slow).
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).
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.
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.
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.
previously, right shift >>0 resulted in >>32 being emited. this
is especially problematic when the shift count comes from a macro
expansion.
we now handle constant shift >>0 as <<0 (no shift) and allow
shift by 32 be specified.
this applies to logical right shift (>>) arithmetic right shift (->)
and right rotate (@>).
the prior implementation was unneccesarily complicated for
no good reason due to me misunderstanding how libc's nrand()
works. in contrast to libc, we already generate the *closest*
power-of-2 random number with mprand() in the sampling loop.
