hrm.. that's interesting..

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

you have to run loader from the other disk

i believe i have experienced this problem a few times with freebsd; it's my understanding that illumos loader is based on freebsd's?

yes

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

it would be nice once we can eventually ditch legacy bios support..

being able to assume UEFI would simplify a number of things a fair amount

@tsoome Is jbk ^^^ correct that if we deprecate BIOS things could get Much Simpler?

there used to be something that'd basically implement UEFI over the BIOS settings (more or less)

in EDK-II

but it got removed after 8-10 years

(though could probably revive it from the commit history)

My Haswell and Haswell-E Kebecloud nodes probably have UEFI over the BIOS settings. My HN and one netbooting CN use UEFI.

To be fair IF we do something that crazy we'll need a LONG lead time.

jbk loader should walk all DVA's

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

tsoome: it would appear it's not walking all of the DVAs...

one 'crazy' thing I had thought about was taking the zfs code there and turning it into a UEFI filesystem driver

so you could do things like browse pools (read only) from the UEFI shell

(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)

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.

you have _some_ control.. though I think you have to coordinate with UEFI (at least until you exit boot services)

yea you can give hints, but thats basically it.

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

with it getting late, maybe tomorrow I can try to dig into it

basically the boot disks are a mirrored zpool, but on the one, the zfs partition was read/write locked

jbk: out of curiosity, what's the underlying storage that has partition-level access controls like that?

sleep well jbk

I think maybe the disk is read-only, and not the partition? in the sentence

well it's more starting LBA-range

no, it's read and write

sommerfeld: TCG self encrypting drive

oh

you can define (non-overlapping) LBA ranges that can be read and/or write locked

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

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.

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

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

or just 'if (user_has_permission) { allow_change_to_rw_state() }'

the whole spec is rather... uhm.. elaborate...

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

(i.e. you send one packet, your request must fit in 1 packet, and you then wait until you get exactly 1 response)

is this one of those industry groups that produce weird overblown libraries?

huh, no, that was SNIA apparently

maybe still is

i don't know... there's no publicly available code I'm aware of, and we had to write our own

it's all a part of TCG

so a different subgroup(?) does the TPM standards

which does include a C API in the spec

(thought it's really not too bad -- they actually do a decent job with ABI versioning in the spec

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)

and probably uses autoconf and libtool more than it needs to... but that's far from the first project to do that...

which reminds me... I should probably go ahead and upstream my tpm2.0 driver

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)

there is to my knowledge 0 reason to use libtool

I agree...

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

that used to often mean you were not using the version of auto* they were and something isn't compatible

but it's been a long long time, thankfully

supposedly it's a compatible version

these days the omnios folks usually already have whatever I need

I dread having to engage with meson etc, more seriously

but I also wouldn't be surprised if it's 'well we never tested that version but thought it'd work'

since there's currently no tpm driver, I don't believe they've been building the tpm2 utilities

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)