00:52:20 also let us re-use (1S) for the man page section for the commands there 17:23:04 rmustacc: (since you've done a lot of NVMe) any thought on providing an NVMe passthru ioctl ala uscsi? 17:24:02 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) 17:24:53 i thought there already is a passthru mechanism, used for vendor-specific commands 17:25:12 IIRC, it's limited to very specific things 17:25:44 yes, but it probably can be generalized. also would need to match whatever ioctl interface those tools expect 17:26:52 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) 17:26:56 I don't believe you can truly allow _arbitrary_ commands 17:27:02 Yeah 17:27:15 I think that caveat is not a great caveat haha 17:27:33 but it can be helpful when $OEM says 'run this tool' 17:27:53 because often trying to fight 'oh, no, our own tool provides the same information' is basically going to get you precisely nowhere 17:28:40 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 17:28:56 Surely most of the things are just informational etc 17:29:32 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' 17:29:41 so more dismissive? :) 17:29:49 yeah 17:29:55 Just because you feel it's justified doesn't mean it isn't hostile haha 17:29:56 generally it's stuff like identify 17:30:11 well i tend to think of hostile as having an element of animus 17:30:31 I think avarice is generally animus enough :P 17:31:04 which isn't the same as indifference (not that it's 'better'... just different) 17:32:44 but at least a lot of vendors are embracing more open source stuff 17:32:55 Yes! That's definitely a good sign 17:33:16 e.g. sometimes they'll be fine with output of an sg3_util command 17:33:29 (though it also has a similar lack of NMVe support) 17:33:32 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 17:34:20 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 17:34:29 And then if you want to do serial again you have to let go of the ugen side 17:34:40 (we do it all dynamically, based on open devices etc) 17:35:13 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) 17:35:14 Best to just not have two cooks in the kitchen where we can, and to provide a curated side hatch where needed etc 17:35:57 (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) 17:37:31 What exactly is a security protocol haha 17:37:41 It seems extremely generic 17:37:53 it is 17:38:19 basically they take 2 parameters -- a protocol# and a protocol specific value + data 17:38:30 but one group manages the protocol namespace for all 3 17:38:42 Is it meant to be for things like FDE? 17:38:43 so 0 is a discovery mechanism 17:38:54 1-6 are for TCG (basically FDE) 17:39:35 guys, is there any plan to port the wlan drivers from OpenBSD or from FreeBSD? 17:39:50 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) 17:39:57 there's one for IEEE1667 17:39:58 ... 17:39:58 szilard: If you would like to port them, we can certainly offer help and advice! 17:40:15 jbk: transport encryption ... sounds wild haha 17:40:40 I feel like that would require you to support actually doing the encryption _in the SCSI stack_ though to be useful 17:41:27 I suspect it would require some cooperation with the HBA 17:41:47 where you'd associate a target with an SA or such 17:41:53 Yeah 17:42:03 though as I said, I'm not sure anything's actually implemented it to date 17:42:24 I suspect most uses are either TCG (for self encrypting drives) or IEEE1667 17:43:43 jclulow: I fear I dont posess the necessary knowledge. 17:43:50 IEEE1667 seems like it's basically "I have a private key and a certificate baked in that lets me prove that I'm me" ? 17:44:43 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 17:45:23 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 17:45:58 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 17:46:48 jbk: I feel like at least in the TCG/FDE case, we should _probably_ provide dkio(4I) interfaces for that 17:47:47 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 17:48:53 TCG would be better modeled as a socket family (w/ the socket name being the disk name sans slice or such) 17:49:26 In that case (I'm not saying you're wrong, to be clear) it definitely feels like IPD territory haha 17:49:48 Just to outline why that is, etc 17:49:58 the thought was at least in the simple case, just providing a common ioctl interface for userland to do all of that 17:50:17 kinda like how mdio interfaces could be extended fairly trivially to NVMe 17:50:38 since NVMe reservations and SCSI-3 reservations are for the most part identical 17:51:46 It's certainly possible 18:03:00 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. 18:04:29 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. 18:04:49 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. 19:36:12 tsoome: does loader have the concept of leaving the background color alone? 19:36:39 (for serial, where I don't really want the configuration onto my local terminal) 19:36:58 I know for a graphic console "none" is a bit hard to implement :) 19:51:11 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: https://pastebin.com/raw/0EEmZAQ1 19:51:42 the target folder /vault doesn't exists yet in the nonGZ-zone, can this be the culprit? 20:12:24 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. 20:16:49 actually, we do send ESC [ 0 m on serial port, thats terminal reset/normal. does that cause problem for you? 20:21:20 between loader terminating and the OS? 20:25:30 [illumos-gate] 16782 ilstr should support prepending to a string -- Joshua M. Clulow 23:17:06 alanc: does srn stand for something? ("Provide apm-like interfaces to Xorg")