[Opendnssec-develop] Re: hsmbully considered harmful?

[Rick van Rein]

Hey Jakob,

> when I ran hsmbully on the Sun SCA6000, it crashed the machine...  
> kaboom!

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
terms.

> 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:  
> ffffffff8f3d8140
>         rcx: fffffe800098e838  r8: ffffffff8f4e3f40  r9:  
> ffffffff8f54a240
>         rax:                0 rbx:                0 rbp:  
> fffffe800098e850
>         r10: fffffe800098ec78 r11: ffffffff8f4e3f40  
> r12:               b8
>         r13:                4 r14:                4 r15:  
> ffffffff8a2d8000
>         fsb: ffffffff80000000 gsb: ffffffff89d66800   
> ds:               43
>          es:               43  fs:                0  gs:               
> 1c3
>         trp:                e err:                2 rip:  
> fffffffffb836c8b
>          cs:               28 rfl:            10246 rsp:  
> fffffe800098e828
>          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?

-Rick