18:55:09 hrm.. that's interesting.. 18:55:49 tsoome: so if you run loader on a mirrored boot disk where the zfs partition isn't readable, it doesn't look for the other mirror.. 18:55:54 you have to run loader from the other disk 18:56:15 i believe i have experienced this problem a few times with freebsd; it's my understanding that illumos loader is based on freebsd's? 18:56:28 yes 18:57:12 unfortunately, I don't have time right now to dig further (another issue with $REALLY_BIG_CUSTOMER just came up), but I can probably dig a bit more once that's resolved 19:06:33 it would be nice once we can eventually ditch legacy bios support.. 19:06:45 being able to assume UEFI would simplify a number of things a fair amount 19:07:33 @tsoome Is jbk ^^^ correct that if we deprecate BIOS things could get Much Simpler? 19:21:30 there used to be something that'd basically implement UEFI over the BIOS settings (more or less) 19:21:45 in EDK-II 19:21:52 but it got removed after 8-10 years 19:22:32 (though could probably revive it from the commit history) 19:36:56 My Haswell and Haswell-E Kebecloud nodes probably have UEFI over the BIOS settings. My HN and one netbooting CN use UEFI. 19:51:06 To be fair IF we do something that crazy we'll need a LONG lead time. 20:05:33 jbk loader should walk all DVA's 20:10:04 the BIOS version does have 2 principal issues - one is limited API to access hardware - so people have written drivers for boot loaders (like one can find in grub), and second one is loader size limit due to how its laid out in memory. UEFI has quite rich API, but how much one can actually use is unknown due to bugs:D 20:12:01 tsoome: it would appear it's not walking all of the DVAs... 20:12:32 one 'crazy' thing I had thought about was taking the zfs code there and turning it into a UEFI filesystem driver 20:13:24 so you could do things like browse pools (read only) from the UEFI shell 20:15:19 (it could also be a piece of a solution where it'd allow the kernel to read from a zpool while booting (similar to sparc) to load drivers, /etc/path_to_inst, etc and not need a ramdisk (could still do that, but wouldn't be required) 20:22:25 there was some work done in freebsd, boot1.efi was providing FS interface. However, that implies loading kernel with BS enabled (so you have no control over memory) while loading bits. Therefore i's a question about the architecture. AFAIK windows is doing something similar - first bits are loaded with help of UEFI and at some point when it has essential drivers loaded, the machine is taken over. 20:23:55 you have _some_ control.. though I think you have to coordinate with UEFI (at least until you exit boot services) 20:25:34 yea you can give hints, but thats basically it. 20:26:54 DVAs are walked in zio_read() in usr/src/boot/libsa/zfs/zfsimpl.c I think I did test it to verify, but I havent done it lately. probably good idea to recheck.... 21:21:31 with it getting late, maybe tomorrow I can try to dig into it 21:22:07 basically the boot disks are a mirrored zpool, but on the one, the zfs partition was read/write locked 21:25:31 jbk: out of curiosity, what's the underlying storage that has partition-level access controls like that? 21:26:00 sleep well jbk 21:26:32 I think maybe the disk is read-only, and not the partition? in the sentence 21:26:35 well it's more starting LBA-range 21:26:40 no, it's read and write 21:26:51 sommerfeld: TCG self encrypting drive 21:28:05 oh 21:29:17 you can define (non-overlapping) LBA ranges that can be read and/or write locked 21:30:07 technically some of the standards (maybe pyrite? can't recall) don't include encryption and just the read/write protect, but opal, enterprise, opalite all will generate an AES key to encrypt the range when you define it 21:30:42 jbk: ah, yeah, makes sense if you have to load the keys before you can meaningfully do i/o to the region .. raise the bar on accidentally whacking a slice. 21:33:22 the way the spec works, you actually have separate 'authorities' (think users) that you authenticate to the drive, and then manipulate the {read,write}locked setting.. the actual AES key shouldn't be able to be extracted from the drive 21:34:13 of course how a vendor implements it isn't really in the spec -- e.g. if they wrap the keys on the user's pins or not 21:34:39 or just 'if (user_has_permission) { allow_change_to_rw_state() }' 21:36:35 the whole spec is rather... uhm.. elaborate... 21:37:48 they define a reliable message based transport (including framing/reassembly) which AFAICT excactly 0 bits of hardware implement, instead opting for a much (much) simpler synchronous variant in the standard.. 21:38:29 (i.e. you send one packet, your request must fit in 1 packet, and you then wait until you get exactly 1 response) 21:41:33 is this one of those industry groups that produce weird overblown libraries? 21:42:16 huh, no, that was SNIA apparently 21:42:20 maybe still is 21:42:23 i don't know... there's no publicly available code I'm aware of, and we had to write our own 21:42:33 it's all a part of TCG 21:42:52 so a different subgroup(?) does the TPM standards 21:43:06 which does include a C API in the spec 21:44:10 (thought it's really not too bad -- they actually do a decent job with ABI versioning in the spec 21:45:40 the 'reference' Intel implementation of the libraries has a few non-standard bits (mostly assuming struct dirent includes file type in the code managing on-disk objects) 21:46:10 and probably uses autoconf and libtool more than it needs to... but that's far from the first project to do that... 21:53:57 which reminds me... I should probably go ahead and upstream my tpm2.0 driver 21:54:32 i had wanted to get the TABRM bits done, but not sure at this point when I'll be able to do that (without it, only one thing can have the device open at a time) 22:15:02 there is to my knowledge 0 reason to use libtool 22:15:38 I agree... 22:16:56 there's also something with their autoconf bits... if you try to run them (from checking out master).. at least on omnios, it fails in a way that seems inscruitable (even for m4).. so you end up wanting to stick releases where configure, libtool, etc have all been generated and are in the tarball 22:17:34 that used to often mean you were not using the version of auto* they were and something isn't compatible 22:17:44 but it's been a long long time, thankfully 22:17:53 supposedly it's a compatible version 22:18:18 these days the omnios folks usually already have whatever I need 22:18:41 I dread having to engage with meson etc, more seriously 22:18:45 but I also wouldn't be surprised if it's 'well we never tested that version but thought it'd work' 22:19:09 since there's currently no tpm driver, I don't believe they've been building the tpm2 utilities 22:19:57 though I have a pkgtools branch so I can use it on smartos that I probably need to upstream to jperkin at some point (and omni could probably use the same patches)