[Opendnssec-develop] Re: hsmbully considered harmful?
Rick van Rein
rick at openfortress.nl
Tue Aug 18 08:14:27 UTC 2009
> when I ran hsmbully on the Sun SCA6000, it crashed the machine...
Ehm? That is not only surprising, but it's also very little information
for me to work on. I certainly do my best to test thoroughly, but I
would not imagine any commercial HSM to "go kaboom", regardless of
what that means, when spoken to over its PKCS #11 interface. If it does,
it almost certainly qualifies as a bad implementation.
> I think we should add a note telling people that running hsmbully can
> be harmful.
That's as good as saying "don't use this tool". If there is any problem
we should specify in detail what it is, rather than use subjective scary
> to be honest, I'm not sure I'm ready to ship this tool just yet. of
> course it shouldn't crash, but IMHO if people want to test if their
> HSM is OpenDNSSEC compliant they better just try the libhsm
> speedtester for now (btw, should we install that by default?).
Has the speedtester been designed as an exhaustive PKCS #11 test?
If so, we have duplicate code and one can go. If not, then there
is an added value for hsmbully.
If an HSM cracks on any PKCS #11 call, it's a bad implementation,
it's as simple as that. I know it's human nature, and often correct,
to blame the new code, but really, this sounds to me like a broken HSM.
I make no bypass calls to anything that is not PKCS #11, after all.
People should be warned about those instead of about a tool testing it?
> panic[cpu1]/thread=ffffffff8f3d8140: BAD TRAP: type=e (#pf Page fault)
> rp=fffffe800098e730 addr=b8 occurred in module "unix" due to a NULL
> pointer dereference
> hsmbully: #pf Page fault
> Bad kernel fault at addr=0xb8
> pid=788, pc=0xfffffffffb836c8b, sp=0xfffffe800098e828, eflags=0x10246
> cr0: 80050033<pg,wp,ne,et,mp,pe> cr4: 6f0<xmme,fxsr,pge,mce,pae,pse>
> cr2: b8 cr3: 11dc25000 cr8: c
> rdi: b8 rsi: 0 rdx:
> rcx: fffffe800098e838 r8: ffffffff8f4e3f40 r9:
> rax: 0 rbx: 0 rbp:
> r10: fffffe800098ec78 r11: ffffffff8f4e3f40
> r12: b8
> r13: 4 r14: 4 r15:
> fsb: ffffffff80000000 gsb: ffffffff89d66800
> ds: 43
> es: 43 fs: 0 gs:
> trp: e err: 2 rip:
> cs: 28 rfl: 10246 rsp:
> ss: 30
> fffffe800098e640 unix:die+da ()
> fffffe800098e720 unix:trap+5e6 ()
> fffffe800098e730 unix:_cmntrap+140 ()
> fffffe800098e850 unix:mutex_enter+b ()
> fffffe800098e8c0 mca:mca_setpass+d3 ()
> fffffe800098eb40 mca:set_pin+16e ()
> fffffe800098eba0 kcf:common_submit_request+1842 ()
> fffffe800098ebf0 kcf:process_req_hwp+cf ()
> fffffe800098ec30 kcf:kcf_submit_request+2c7 ()
> fffffe800098ed70 crypto:set_pin+26a ()
> fffffe800098ed80 crypto:crypto_ioctl+59 ()
> fffffe800098ed90 genunix:cdev_ioctl+1d ()
> fffffe800098edb0 specfs:spec_ioctl+50 ()
> fffffe800098ede0 genunix:fop_ioctl+25 ()
> fffffe800098eec0 genunix:ioctl+ac ()
> fffffe800098ef10 unix:brand_sys_syscall32+1a3 ()
> -- cut --
These are calls inside the PKCS #11 implementation, right? You --cut-- so
I cannot be sure, but these labels are not mine.
The Initiation Test surely is a devious one, trying to bypass loging in
and such. I am getting the impression that we bypassed a thing that is not
welcomed by this PKCS #11 implementation.
This is not new to me, by the way (except for the boldness of actually
crashing). PKCS #11 implementations rarely live up to spec. I'd hoped
that HSM's (from Sun) would be better.
Could I have access to this machine, and try myself?
More information about the Opendnssec-develop