-RFC2104 says that the block size of the hash algorithm must be used
for key/ipad/opad calculations. While formerly all ciphers used a block
length of 64, SHA384 and SHA512 use 128 bytes. So we can't use the
HMAC_BLOCK_LEN constant anymore. Add a new field to "struct auth_hash"
for the per-cipher blocksize.
-Due to this, there can't be a single "CRYPTO_SHA2_HMAC" external name
anymore. Replace this by 3 for the 3 different keysizes.
This was done by Open/FreeBSD before.
-Also fix the number of authenticator bits used tor ESP and AH to
conform to RFC4868, and remove uses of AH_HMAC_HASHLEN which did
assume a fixed authenticator size of 12 bytes.
FAST_IPSEC will not interoperate with KAME IPSEC anymore if sha2 is used,
because the latter doesn't implement these standards. It should
interoperate with at least modern Free/OpenBSD now.
(I've only tested with NetBSD-current/FAST_IPSEC on both ends.)
Now cobalt boots multiuser, but many programs complains
"clntudp_create: RPC: Program not registered"
as well as R5000 sgimips O2. Smells virtual cache alias issue around pool...
yesterday on powerpc broke overnight. Apparently adding one more
function before the call to dlsym() fixes things again. I hope
I don't have to add another one tomorrow ....
This makes interrupts on cobalt (and probably other Rm5200 machines) work,
and no bad side effect seen on R4400 ews4800mips.
Cobalt GENERIC kernel on RaQ still panics right after mountroot() though:
---
:
atabus1 at viaide0 channel 1
VIA Technologies VT83C572 USB Controller (USB serial bus, revision 0x02) at pci0 dev 9 function 2 not configured
wd0 at atabus0 drive 0
wd0: <QUANTUM FIREBALLlct15 15>
wd0: 14324 MB, 29104 cyl, 16 head, 63 sec, 512 bytes/sect x 29336832 sectors
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
pid 1(init): ABI set to O32 (e_flags=0x1007)
pid 4(sh): trap: cpu0, address error (load or I-fetch) in kernel mode
status=0x8003, cause=0x10, epc=0x801430a0, vaddr=0x8001
tf=0xc6471a88 ksp=0xc6471b28 ra=0x801f0c90 ppl=0x801f0c24
kernel: address error (load or I-fetch) trap
Stopped in pid 4.1 (sh) at netbsd:mutex_abort: lw v1,0(a0)
db> tr
0xc6471b28: mutex_abort+0 (8001,80380530,803cbb10,803ff840) ra 801f0c90 sz 0
0xc6471b28: mips_pmap_map_poolpage+90 (8001,80380530,803cbb10,803ff840) ra 80276788 sz 40
0xc6471b50: pool_grow+4c (8001,80380530,803cbb10,803ff840) ra 80276b64 sz 48
0xc6471b80: pool_catchup+34 (8001,80380530,803cbb10,803ff840) ra 80276418 sz 24
0xc6471b98: pool_get+50c (8001,80380530,803cbb10,803ff840) ra 801f11b8 sz 64
0xc6471bd8: pmap_enter_pv+e8 (8001,80380530,803cbb10,803ff840) ra 801f3054 sz 48
0xc6471c08: pmap_enter+138 (8001,80380530,803cbb10,803ff840) ra 802fd528 sz 64
0xc6471c48: uvm_fault_lower+24c (8001,80380530,803cbb10,803ff840) ra 802fec50 sz 96
0xc6471ca8: uvm_fault_internal+72c (83ed5b40,80380530,1,0) ra 802b5b08 sz 272
0xc6471db8: trap+8d0 (10,8,1,408fb8) ra 8018f22c sz 400
0xc6471f48: mips3_user_gen_exception+cc (10,8,1,408fb8) ra 0 sz 0
User-level: pid 4.1
db>
libgcc_s's __register_frame_info gets called from libc's CSU code before
the libc constructors are run. __register_frame_info in turn calls
pthread_mutex_lock. libpthread is not initialised at this point and
therefore pthread__self() traps when deferencing the thread register.
This worked before because the garbage from pthread__self() is
effectively ignored.
