so i created a bhyve machine (omnios iso in cd drive) which compiled and booted fine. vmadm info shows vnc port, and netstat confirms something listening on the port, and a vnc connecting to it (mine, from windows machine). I've tried 3 different vnc clients, but no data is flowing

so vnc client is definitely connecting, but there's no data transfer. Any ideas? googling old post suggests vnc is a problem on bhyve machines

I found the platform logs - I was allocating too much ram (surprisingly -- it was 4G less than total memory)

hrm...

does this panic look familiar to anyone?

... also it's unfortunate that most of the arc cases revolving around kcf never made it out...

jbk: what is it you're wondering? (I don't have answers, but also questions)

well just there's a lot of undocumented intent as well as big picture things

like I suspect there's some sort of intended model for devices (or perhaps different models), but I've not found anything that explains it

like I guess maybe there's an assumption of some sort of asynchronous request queue for providers

??

that would make sense, given how hardware was until it was CPUs

but I don't know if it's true

like I have update the tpm2.0 driver (it's limited to 1 open connection from userland, mostly because internally we need it before I can finish the annoying bits for supporting multiple clients)

(if people are ok with that, I can put it up for review, otherwise I was going to wait until that's done)

but

future work it might be nice to expand the kcf support for the tpm driver (at least for 2.0 devices) to be more than an rng support

but then the question is how to do that?

kcf seems to have assumptions that are largely undocumented (and trying to walk through the layers of it with its heavy use of macros and indirection does add a layer of challenge)

so how to map that to what the tpm can do?

(e.g. 1 request at a time)

like, should I create a queue for requests for kcf providers? is there any sort of timing expectation where the driver should back off or exert backpressure?

(the latter is of particular concern considering how many times we've been burned badly by the zio pipeline's lack of)

(a busy enough system can generate enough zios to exaust even multi-GB systems)

and trigger the deadman

stuff like that

which I suspect would at least be partially answered by the cases in there

also how do providers get chosen?

e.g. a tpm2.0 module can be thought of as a special kind of HSM+other stuff

my brain says "isn't that a softtoken adjacent question?"

but the one thing it's not is speedy

danmcd and sommerfeld might know that

(via ipsec)

but maybe you want the tpm20 to hold some wrapping keys and use it to unlock some other stuff, so you'd probably want it to decrypt the data even though it's slower than the CPU

because you don't want certain bits of it to leave the tpm module for security reasons

etc

jbk: been a long time since I looked at anything related to that. there are multiple reasons to do crypto offload (performance, assurance) and they are often in conflict with each other...

like, if it's just an accelerator you might want to do short blocks in software and large blocks in hw, but that means you can't lock down the keys in hardware only...

and if you go down the assurance path you end up dealing with FIPS certification or equivalent which has been known to threaten sanity.

a bit (have been dealing with common criteria for something and it's... a thing)

but, yes, any time you introduce async queueing you need to introduce a backpressure mechanism

the tpm2.0 has some potentially interesting bits you can do with policy

but for now it's just one request at a time and for the rand bits at least, it'll return CRYPTO_BUSY if it's in the middle of another request (e.g. from userland)

which i hope is ok

(if anyone wants a peek.. jasonbking/illumos-gate bef60ef is the commit for the driver)

err...

→ GitHub commit 5c4b011: TPM 2.0 driver (no TAB support) (committed)

that one's correct

i also tried to isolate the tpm1.2 specific stuff in case we decide at some point to drop support for it

since they're pretty hard to find these days and not very useful even if you do have them

FYI: if you happen to have the problem where USB 3 devices don't show up after a reboot (until you unplug and replug them) you should take a look at: illumos.topicbox.com/groups/developer/T7b412760d78e8a22