Age | Commit message (Collapse) | Author |
|
<sys/systm.h>; fixes build on vax due to <machine/macros.h> redeclaring
some functions from <lib/libkern/libkern.h> as inlines.
|
|
OK deraadt@
|
|
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.
ok tedu@ deraadt@
|
|
No actual change, but makes it easier to reuse the code elsewhere.
Suggested by Andre Smagin
|
|
interrupt context to a taskq running in a thread. however, there
is a concern that if we do that then we allow accidental use of
sleeping APIs in this work, which will make it harder to move the
work back to interrupts in the future.
guenther and kettenis came up with the idea of marking a proc with
CANTSLEEP which the sleep paths can check and panic on.
this builds on that so you create taskqs that run with CANTSLEEP
set except when they need to sleep for more tasks to run.
the taskq_create api is changed to take a flags argument so users
can specify CANTSLEEP. MPSAFE is also passed via this flags field
now. this means archs that defined IPL_MPSAFE to 0 can now create
mpsafe taskqs too.
lots of discussion at s2k15
ok guenther@ miod@ mpi@ tedu@ pelikan@
|
|
that are only used in this file.
tedu argues if something sucks we would fault before we can get to
these, and they dont do anything except maths. these symbols dont
need to be visible to ddb.
originally from Fritjof Bornebusch
suggested by and ok tedu@
|
|
when workqs were introduced, we provided a second argument so you
could pass a thing and some context to work on it in. there were
very few things that took advantage of the second argument, so when
i introduced pools i suggested removing it. since tasks were meant
to replace workqs, it was requested that we keep the second argument
to make porting from workqs to tasks easier.
now that workqs are gone, i had a look at the use of the second
argument again and found only one good use of it (vdsp(4) on sparc64
if you're interested) and a tiny handful of questionable uses. the
vast majority of tasks only used a single argument. i have since
modified all tasks that used two args to only use one, so now we
can remove the second argument.
so this is a mechanical change. all tasks only passed NULL as their
second argument, so we can just remove it.
ok krw@
|
|
things will happen when machines have 8 byte longs.
|
|
|
|
ok deraadt
|
|
extra warnings with gcc 3, due to the way we use siphash in the filesystem
code.
With dlg@
|
|
simplify a bit more, swapping only aligned values and then using memcpy
to fill the digest. fix confirmed by jsg.
ok jsg kettenis millert
|
|
looks good to deraadt@ miod@ and tedu@
|
|
context and making digest required to Final.
|
|
|
|
|
|
|
|
|
|
|
|
ok millert
|
|
|
|
naddy found sparc64 gets a little slower when unrolled.
ok deraadt
|
|
ok deraadt millert
|
|
This includes a commit made by Andy Polyakov <appro at openssl ! org>
to the OpenSSL source tree on Wed, 28 Jun 2006 with the following
message: "Mitigate cache-collision timing attack on last round."
OK naddy, miod
|
|
required to cast their pointers, which is ugly and possibly error
prone. accidentally casting an int to a pointer, for example, instead
of the address of the int. implicit void * casting is safer.
This updates the kernel hash interfaces to use void *. Similar changes
are possible for userland. I think it's safe, but there may be some
peculiar source compatbility issues there, so let's just do the kernel
first.
ok dlg millert
|
|
Pointed out by John-Mark Gurney <jmg at funkthat ! com>, thanks!
|
|
J. Bernstein, as described at https://131002.net/siphash/, and via
Andre Oppermanns implementation in FreeBSD.
this is supposed to be a good but cheap hash for use in places where
you want to protect against hash bucket flooding attacks.
yasuoka@ pointed me at this after i asked about possibilities for
protecting the in_pcb hash he was tinkering with.
naddy@ mikeb@ claudio@ and djm@ agree it is much better than doing nothing
commit deraadt@
|
|
will be used from.
this adds pool_setipl at IPL_VM to the crypto descriptor pools, and
removes all the splvm handling around the use of those pools.
tested by many via tech@
ok kettenis@ deraadt@
|
|
make the crypto taskq protect things at IPL_VM instead of IPL_HIGH.
everything else in crypto.c uses splvm/IPL_VM. it seems this IPL_HIGH
came about because the hand rolled task list and thread that crypto
used to use was converted to workqs, which unconditionally used
IPL_HIGH internally. when it was converted from workqs to tasks it
blindly ported the protection workqs gave.
tested by many via tech@ and snapshots
ok kettenis@
|
|
|
|
everything else in crypto.c uses splvm/IPL_VM. it seems this IPL_HIGH
came about because the hand rolled task list and thread that crypto
used to use was converted to workqs, which unconditionally used
IPL_HIGH internally. when it was converted from workqs to tasks it
blindly ported the protection workqs gave.
tested by many via tech@ and snapshots
ok kettenis@
|
|
ok deraadt@
|
|
ok mpi@ kspillner@
|
|
The interface has been disabled by default for about 4 years and
currently there's not much value in having it around at all.
ok deraadt
|
|
The interface has been disabled by default for about 4 years and
currently there's not much value in having it around at all.
ok deraadt
|
|
ok miod@, who has offerred to help with any MD fallout
ok guenther@
|
|
|
|
|
|
after discussions with beck deraadt kettenis.
|
|
don't need to be married.
ok guenther miod beck jsing kettenis
|
|
deflate(); this hurts interop with broken old openbsd releases; ok reyk@
|
|
a high compression ratio, e.g. for ping -s 10000 -p aa
- deal with inflate returning Z_BUF_ERROR if the output buffer is full.
this can happen in some edge cases with upgraded libz from 2004
ok mikeb@
|
|
|
|
ok jsing, markus
|
|
ancient code looked pretty crummy.
ok deraadt@
|
|
|
|
|
|
rather than requiring each algorithm to provide their own memory handling.
This matches the interface already provided by cryptosoft for
authentication algorithms and removes the need for zerokey functions.
ok mikeb@
|
|
|
|
rename the structure internals to id32_* in anticipation of an
idgen16() that might come in the future.
|