also let us re-use (1S) for the man page section for the commands there

rmustacc: (since you've done a lot of NVMe) any thought on providing an NVMe passthru ioctl ala uscsi?

there's a number of tools (e.g. seagate's openseachest) that won't work w/ NVMe disks on illumos due to a lack of that (would be nice to have)

i thought there already is a passthru mechanism, used for vendor-specific commands

IIRC, it's limited to very specific things

yes, but it probably can be generalized. also would need to match whatever ioctl interface those tools expect

generally they want to just be able to submit an NVMe request similar to how with USCSI you can submit a CDB (obviously similar caveats apply in that requests that would change the state of the device in a manner that makes the OS upset may cause undesirable behavior)

I don't believe you can truly allow _arbitrary_ commands

Yeah

I think that caveat is not a great caveat haha

but it can be helpful when $OEM says 'run this tool'

because often trying to fight 'oh, no, our own tool provides the same information' is basically going to get you precisely nowhere

Sure, I think in the case of hostile vendors we could certainly extend the existing passthrough mechanism to safely arbitrate whatever that tool is giving you

Surely most of the things are just informational etc

it's not so much hostile as 'unless you're doing enough business to move our stock prices appreciably, we're not going to give you a lot of special attention'

so more dismissive? :)

yeah

Just because you feel it's justified doesn't mean it isn't hostile haha

generally it's stuff like identify

well i tend to think of hostile as having an element of animus

I think avarice is generally animus enough :P

which isn't the same as indifference (not that it's 'better'... just different)

but at least a lot of vendors are embracing more open source stuff

Yes! That's definitely a good sign

e.g. sometimes they'll be fine with output of an sg3_util command

(though it also has a similar lack of NMVe support)

I can't speak for rm but I would not be opposed to allow-listing bits of NVMe pass-through that we can determine are safe to allow

I had to make a similar decision with the WIP FTDI driver we're using at Oxide: basically if you want to start using ugen on the device, it needs to first stop being an in-kernel serial device

And then if you want to do serial again you have to let go of the ugen side

(we do it all dynamically, based on open devices etc)

i don't know if it'd need to rise to the level of an IPD (if it did, i'd imagine it'd be a minor one), but one thing that would be nice is to add an ioctl that'll do the {SATA,SCSI,NVMe} equivalent of SECURITY PROTOCOL IN/OUT (since the values passed are the same regardless of the underlying I/O protocol)

Best to just not have two cooks in the kitchen where we can, and to provide a curated side hatch where needed etc

(well SATA would be handled by the SATL, which I'm almost there in my changes to support that, so it'd really just need SCSI and NVMe)

What exactly is a security protocol haha

It seems extremely generic

it is

basically they take 2 parameters -- a protocol# and a protocol specific value + data

but one group manages the protocol namespace for all 3

Is it meant to be for things like FDE?

so 0 is a discovery mechanism

1-6 are for TCG (basically FDE)

guys, is there any plan to port the wlan drivers from OpenBSD or from FreeBSD?

one # is allocated for basically doing a form of IKEv2 to allow for OTW encryption (i.e. across the SAS, ... bus.. though not sure if any devices have actually implemented it)

there's one for IEEE1667

...

szilard: If you would like to port them, we can certainly offer help and advice!

jbk: transport encryption ... sounds wild haha

I feel like that would require you to support actually doing the encryption _in the SCSI stack_ though to be useful

I suspect it would require some cooperation with the HBA

where you'd associate a target with an SA or such

Yeah

though as I said, I'm not sure anything's actually implemented it to date

I suspect most uses are either TCG (for self encrypting drives) or IEEE1667

jclulow: I fear I dont posess the necessary knowledge.

IEEE1667 seems like it's basically "I have a private key and a certificate baked in that lets me prove that I'm me" ?

szilard: The challenge is generally that folks that possess the knowledge generally don't have the time/energy/motivation to work on something that isn't a thing they really need themselves, and generally don't have all the hardware either, etc

So, we can try to help you as you work to gain the knowledge, but I don't know that there is any spare capacity in terms of folks to do a port of the drivers on your behalf, etc

The kernel is just a big C program, though, ultimately. There's a lot of mystique in systems programming, but really the most important thing is just tenacity and having a goal in mind

jbk: I feel like at least in the TCG/FDE case, we should _probably_ provide dkio(4I) interfaces for that

Maybe in the IEEE1667 case as well. The encrypted transport stuff obviously feels a bit more like it would require HBA and target driver integration pretty deeply to be useful

TCG would be better modeled as a socket family (w/ the socket name being the disk name sans slice or such)

In that case (I'm not saying you're wrong, to be clear) it definitely feels like IPD territory haha

Just to outline why that is, etc

the thought was at least in the simple case, just providing a common ioctl interface for userland to do all of that

kinda like how mdio interfaces could be extended fairly trivially to NVMe

since NVMe reservations and SCSI-3 reservations are for the most part identical

It's certainly possible

jbk: I haven't given a ton of thought and am currently focused on ns management and extending that through libnvme. I think getting specific as to what we need will help.

I think figuring out what things they want to do and whether a truly do whatever you want is the right way forward. In particular, with libnvme we have a lot of logic around device locking, understanding impact, etc.

That at least has been helpful as even with vendor-specific command passthru some just read data and some erase all your data and knowing the difference is kind of important.

tsoome: does loader have the concept of leaving the background color alone?

(for serial, where I don't really want the configuration onto my local terminal)

I know for a graphic console "none" is a bit hard to implement :)

Hi. May I get a bit help? I am trying to attach an encrypted zfs to a nonGZ-zone, but I am facing this issue: pastebin.com/raw/0EEmZAQ1

the target folder /vault doesn't exists yet in the nonGZ-zone, can this be the culprit?

richlowe I was starting to think.... we do not deal with colors on serial console at all, because colors are handled at the terminal emulator - we can tell via CSI sequences to use specific colors, but thats about it. with local gfx console it is another story, tem needs initial setup.

actually, we do send ESC [ 0 m on serial port, thats terminal reset/normal. does that cause problem for you?

between loader terminating and the OS?

[illumos-gate] 16782 ilstr should support prepending to a string -- Joshua M. Clulow <josh⊙so>

alanc: does srn stand for something? ("Provide apm-like interfaces to Xorg")