00:30:18 has anyone done a ssh intermediate install for a FDE encrypted freebsd server 00:30:46 aka, boot freebsd, ssh into it, decrypt the actual OS, then boot that? 00:30:56 if someone has I would be interested in the docs for it 00:31:57 (I am still working on decryption over serial, I just have an idea of testing ssh decryption for serial-less devices) 00:50:08 i'd love to figure out how we make it easy to package up an initrd-like thing for use-cases like that 00:50:58 something stupid simple like I toss dropbear into an initrd to decrypt and kick-off the reroot? that /feels/ right 00:51:00 ANOTHER TALK IDEA!!! 00:51:21 kevans: you could embed a small ssh impl into the second stage loader.. 00:51:34 loader-sshd-lua! 00:51:49 we have a hard no on more things for bios loader, and for uefi loader it doesn't even need to be particularly small 00:52:34 minimal dropbear is apparently within 1M and probably not incredibly painful to make build in the stand environment 00:52:37 well with UEFI just enable ssh at boot... although the network config would be complicated wouldn't it... 00:53:18 we allocate ~200M for our ESPs these days and use a tiny fraction of that, even a few MB is a drop in the bucket 00:53:42 tsoome: illumos have a need for anything funky like that? ^ 00:54:01 oops crashed my terminal 00:54:29 I wonder how you would even embed dropbear 00:54:53 you would probably want to strip it down as much as possible, but dropbear is already pretty basic... 00:55:09 issue is dropbear adds attack surface, if you add dropbear, and you use openssh for your server, you have to worry about the security of both... 00:55:40 you're 100% not getting openssh into your loader environment any time soon, though 00:55:51 that brings us back to the notion of an initrd :-) 01:04:45 why the initrd? 01:04:55 wouldn't the s2 loader be better? 01:05:08 output the s2 loader, aka the boot menu, over ssh? 01:05:16 then you can also configure the server over ssh as well! 01:05:59 say you do an update, and fuck it, then you can select the snapshot of ROOT/default 01:06:57 well I keep saying stage 2, but in theory, you could output the entire loader, you could have a script which parses your rc.conf, and then copies this over to a config within the ESP which provides the network config for the sshd on boot? 01:09:59 hmm I just realised why this wouldn't work, theres no network knowledge in the loader, I forgot the loader is stupid 01:10:54 bummer :/ 01:14:19 kevans: freebsd doesnt have an initrd does it? 01:14:59 I thought the third stage of the loader pretty muich does what Linux would use initrd for? 01:20:29 right, but you can see already where the idea starts to look attractive as an option 01:21:38 most people would just stay with loader, but more interesting use-cases can be served with full kernel support 01:29:01 hmmm 01:29:37 its still not as good as serial access though, moment a remote update fails to boot, and you are away at EuroBSDCon (for example) you would need remote hands 01:29:52 i mean, you'd still get serial into the initrd 01:29:53 I wonder how Linux users do this 01:30:13 how does Linux distros failover the backup initrd? 01:30:25 I know they make a backup initrd, but I never questioned how they failover 01:30:55 i think with a setup like that, you'd just inject the initrd as the next stage after loader and expect it to kexec or reroot depending on how much you care about packaging your production kernel into the initrd 01:33:48 kevans: so let me get your theory correct, you would basically embed a mini freebsd install like a linux initrd which the loader will chainload on boot, this will then have an sshd embedded into it, and be a *mostly* functional freebsd kernel (and basic userspace for recovery?) and then once you enter the passphrase over ssh, it kexec (boots the FDE kernel) and then how does rerooting work? 01:34:25 wouldn't you need to unmount root in order to mount the other root, but then how does the other root mount? a syscall? 01:35:02 if you kexec you don't reroot, and you may not need to kexec if you're OK just having a copy of the kernel unencrypted 01:35:05 linux initrd-style* 01:35:07 sorry 01:35:11 not actually Linux, I meant the style 01:35:24 reroot is a specific concept that already exists, see reboot(8) -r 01:35:25 kevans: is there a downside to kexec? 01:35:44 ooo inteeresting... 01:35:52 hold a minute 01:36:00 in theory this could be done with a RPI pretty easily 01:36:09 install a freebsd install onto the microsd card 01:36:21 kexec brings its own risks, you're relying on the current kernel to leave things in a reasonable state for the next kernel to init 01:36:30 have that run an sshd, then decrypt the partition, mount it somewhere, and then kexec the kernel from it? 01:36:46 hmmm 01:36:49 so kexec not perfect then :/ 01:37:00 having your kernel unencrypted is a pretty major attack vector 01:37:22 it's probably fine for most drivers 01:37:53 you could sign the kernel, and check the signature from a signature stored encrypted on the FD 01:37:55 FDE 01:38:07 but by then you could have been pwned (already typed in the passphrase) 01:38:08 well, maybe a pretty major attack vector, right? that's making an assumption about your threat model 01:38:11 however it does allow for detection 01:38:43 kevans: if you are FDE your server, your threat mdoel is someone broke into your home/office and wants to exfiltrate the data on your server 01:38:45 if you care enough then you start with secureboot and use veriexec for next stage verification 01:38:59 that same secure boot which was compromised on many devices, that one? :p 01:39:19 I feel like the loader is a smaller attack vector anyways 01:39:31 "if you are FDE your server" -> you're making bold assumptions about my motivation for doing that 01:39:38 true true 01:39:49 FDE mainly just helps with disposing of the drives after :) 01:40:15 perhaps I don't use ZFS, or I don't like ZFS's native encryption, so I just encrypt the whole thing but the relevant bits are only a fraction of what's encrypted 01:40:32 this is how i do my laptop, for instance 01:41:07 I have long been interested in the idea of embedding the freebsd loader as a coreboot payload :p 01:41:15 likely chainloaded from seabios 01:41:40 you get a few MBs of room on most NOR flash iirc 01:42:53 anyways then you can move the loader to write protected NOR (although the laptop will now only ever boot FreeBSD xD) 01:43:02 read and write* 01:43:31 issue is you can get around this with a SOIC-8 clip, because its currently not possible for any open source hacker to replace bootguard :/ 01:45:23 "that same secure boot which was compromised on many devices, that one?" -> from my perspective this isn't necessarily a complete takedown of secureboot; it's still a pretty reasonable idea and working with it still provides reasonable protections against less sophisticated actors 01:47:45 but hey if your attacker has the time to reprogram your hardware, you got bigger issues 01:48:06 yeah, there's also that :-) 01:48:12 although you could swap a SOIC-8 with a WSON-8, solder it to the board, just as an extra fuck you to an attacker 01:48:53 but then updating your loader (say if you rotated your signature key for your boot chain) would be a pain... desoldering the chip, slapping it into a socket, reprogramming it, and resoldering it 01:49:09 kevans: its almost 3am, my brain is just trying to nerd out over anything right now 01:49:50 went offtopic, so kexec/no-kexec doesn't matter too much in the grand scheme of things 01:50:28 which makes me wonder, in theory couldn't you reroot already? 01:50:45 yes, but right now your kernel is on the other side of the wall 01:52:07 in theory, say if you had two partitions, one unencrypted, one geli, you get the loader to boot the unencrypted one, (not sure how, but assume you do), then when this boots, it starts a sshd, you ssh in, you decrypt, and mount the FDE partition, and then reroot? 01:52:31 obviously not as perfect as the initrd idea of yours, but one which can be done without any osdev... 01:52:34 right? 01:55:11 yeah 01:55:16 i mean, initrd has its own flaws 01:55:47 the way I could think of doing it, is running through bsdinstall, then once that reboots you into the unencrypted install, make a partition with the free space, geli it, init zfs, make installworld (no kernel would be needed because you are rerooting) and then you can reroot into the FDE install 01:55:50 and doing it probably wouldn't take that much osdev, just working out the right incantations and then figuring out how you want to construct the image 01:56:28 oh boy, updating such an abomination would be a pain in the arse 01:57:01 imo you just treat it as a disposible artifact 01:57:12 wdym? 01:57:34 ideally you just have a mkinitrd type thing, specify the kernel and some binaries you want to wrap into it and it works out the dependencies somehow 01:57:51 now we are getting linuxy :p 01:57:57 so then whenever you apply an update of any kind, you just blow away the initrd and rebuild it from the running system 01:58:11 ~just like Linux!~ 01:58:18 is that how they do it? 01:58:28 kevans: yeah they regenerate the initrd every kernel update 01:58:41 their package managers usually have a hook to trigger a inird regen 01:59:31 i don't know that i'd go for an auto-update, personally, but i'm also not advocating it as part of average user's boot chain 02:00:04 anyways when I was talking about the abomination I was talking about my idea... I guess you could have a ufs partition for /boot, and then a ufs partition for / (both unencrypted) then do zfs just for the encrypted volume, and then mount the ufs /boot into /boot on the rerooted install, and then you can make installkernel/make installworld? 02:00:26 or... zroot and zboot :p 02:00:49 and just mount the zfs volume for /boot from the zboot pool into the reroot :p 02:01:13 kevans: sounds like fun! 02:01:43 it used to be the case that one standard setup you could get out of the installer was actually two zpools 02:01:50 one called whatever you name it, one called 'bootpool' 02:02:24 bootpool was just the contents of /boot, and your root pool had a symlink into the bootpool 02:03:51 yeah but your bootpool still needs a root, to boot first, so that you can ssh into the bootpool install, and then reroot? 02:04:05 right, you'd have to expand it a bit for your scheme to work 02:04:42 I should finish my serial debugging first before starting new projects :p 02:04:50 in theory you could probably get away with specifying via kenv an rc replacement that just runs sshd and waits 02:05:02 reaping the benefits of bapt's work 02:05:03 although I should be quick, I might get arrested for freebsd warcrimes for this one :p 02:05:33 kevans: you can hotplug the rc? 02:06:13 you're damn right you can ;) 02:06:27 imagine the blogpost potential for this shit... 02:06:54 http://cgit.freebsd.org/src/commit/?id=9f2ad7c09709e bapt wanted it to allow testing of his rcd 02:07:06 so in theory, the bootpool would need an sshd, and geli, and any libs geli depends on? 02:07:08 it is the freebsd way 02:07:11 oh and reboot ofc 02:07:19 yeah, sounds reasonable 02:07:29 sounds like you could shrink that into a few MBs 02:07:42 well maybe more than a few 02:08:13 ./boot is 350MB on my lapotp 02:08:33 but the /boot can just be remounted actually anyways 02:09:18 yeah, in a traditional setup you mount both pools and symlink the bootpool into place so you don't have two copies and kldload can still work 02:09:21 better yet, this would be pcbios compatible too! 02:09:48 i'm interested in hearing about how your experiments go if you decide to start fucking with it 02:09:52 why symlink it? 02:10:08 I see no reason I cant just mount the /boot partition from the other pool into the reroot 02:10:14 because you still have to have a /boot path within the bootpool, so you end up with /boot -> /bootpool/boot 02:10:23 hmmm..... 02:10:36 I thought the reroot would unmount that all though? 02:10:41 mounting it there might just work, but I think there was an ordering concern of some sort 02:11:08 > The system kills all processes, unmounts all filesystems, 02:11:10 yes, but then the zpool rc script would probably bring it back depending on how your cache file is setup 02:11:37 but the zpool rc script would mount the zpool partitions no? 02:11:46 oh wait no, it tries to mount all zfs partitions ugh 02:12:26 but if zroot has no /boot... 02:12:38 ah fuck 02:12:53 this is probably where 3:00am starts to be a challenge :-) 02:12:55 so with default zfs partitioning /boot is stored within zroot/ROOT/default 02:13:36 so I would also need to partition off the /boot on the unencrypted install, then it can just mount the zroot's empty /boot dir 02:13:40 on reroot 02:13:45 unless im missing something? 02:15:32 but yeah good point, sleepy time 02:15:43 yeah, i don't know, heh 02:16:02 it's end of day here and i'm running on like 3 hours of sleep, so i'm also losing my ability to reason a bit 02:18:41 hah 02:18:55 goodnight 02:19:35 night 07:40:45 <_Posterdati_> Reinhilde: on debian it worked, then I installed freebsd for speed 07:41:09 <_Posterdati_> Reinhilde: I remember I access fan speed with acpi 07:41:18 <_Posterdati_> which make sense 07:41:50 <_Posterdati_> secondly I cannot have memtest86 check all memory, it only get half memory and 2 on 4 cpus 07:42:12 On debian you were able to access the fan speed? _Posterdati_ 07:42:12 <_Posterdati_> memtest86 is the image provided by freebsd with pkg 07:42:46 <_Posterdati_> Reinhilde: yes I was, I had psensor 07:42:59 <_Posterdati_> Reinhilde: the machine was so slow with debian 07:43:11 <_Posterdati_> Reinhilde: freebsd performs better on this i5 07:43:15 right 07:43:22 _Posterdati_, you don't have to highlight me with every message 07:43:30 _Posterdati_, it starts to get annoying after about the second message in a row 07:43:33 _Posterdati_, so maybe please don't 07:43:39 <_Posterdati_> uh ok 07:44:38 right, that out of the way: `pensor` here refers to what? a command? some kernel-related API? 07:44:45 er, `psensor`, s key broken 07:44:57 oh, high level, GUI based sensor reader 07:44:59 <_Posterdati_> it uses lm-sensors 07:45:51 to my knowledge that is linux-specific. do you know what underlying driver was in use on the linux side to pull that data? 07:46:07 <_Posterdati_> I do not recall 07:46:17 <_Posterdati_> acpi for sure, and coretemp 07:46:35 <_Posterdati_> and some asus specific driver 07:48:06 if you `kldload aibs` as root, does anything show up under `sysctl dev.aibs.` that would be of interest 07:49:36 <_Posterdati_> sysctl: unknown oid 'dev.aibs' 07:50:01 you already kldload'ed aibs? 07:50:09 <_Posterdati_> yes 07:51:52 k. then just at a first approximation the driver in question may not exist for freebsd 07:53:00 <_Posterdati_> ok 07:54:55 what was the motherborad again? 07:55:28 <_Posterdati_> Asus K55VD 07:56:40 <_Posterdati_> latest bios 411 07:57:19 wait is this a laptop 07:57:33 <_Posterdati_> yes it is 07:57:41 try `kldload acpi_asus` 07:57:46 <_Posterdati_> ok 07:58:08 thouh i'm not sure what that'll do, and the nodes would be under hw.acpi.asus 07:58:14 likely won't give you fan spede access 07:58:40 <_Posterdati_> same error 07:59:00 nothing at all under `sysctl hw.acpi.asus`? 07:59:06 <_Posterdati_> nothing 07:59:20 did you install the OS under a BIOS type firmware or UEFI 07:59:23 <_Posterdati_> this is one of the first laptop with uefi 07:59:33 if the machine can use UEFI but you used BIOS the CSM may be incomplete 07:59:39 <_Posterdati_> ah 07:59:48 <_Posterdati_> how can I check that? 08:00:09 are you asking how you can check whether you installed via CSM? 08:00:23 efibootmgr as root would probably error 08:00:47 <_Posterdati_> it returns indos 08:00:49 <_Posterdati_> infos 08:00:58 <_Posterdati_> Boot to FW: false 08:01:07 <_Posterdati_> BootCurrent: 0000 08:01:15 <_Posterdati_> Timeout: 0 seconds 08:01:27 <_Posterdati_> BootOrder: 0000, 0001 08:01:39 <_Posterdati_> +Boot0000* FreeBSD 08:01:51 <_Posterdati_> Boot0001* CD/DVD Drive 08:02:13 please don't paste multi line program output into irc 08:02:17 for long pastes - this one's thankfully over already, use a pastebin, such as debian's pastezone https://paste.debian.net/ 08:02:26 <_Posterdati_> ok 08:02:52 (there's nothing in the TOS that requires the pastes to be related to a debian irc channel, so it shuold be fine for us here) 08:02:55 and to see how you booted sysctl machdep.bootmethod 08:03:22 <_Posterdati_> UEFI 08:06:47 <_Posterdati_> no idea? 08:07:20 nimaje, ah thank 08:07:39 _Posterdati_, yeah the driver probably doesn't exist. hopefully you're ok without your fan speeds for now 08:08:02 <_Posterdati_> temps are a bit higher for the cpu 08:08:50 that can happen, it's possible you were finding debian slow because you'd done some scheduler tweaks to keep the cpu colder? 08:08:51 <_Posterdati_> 346 K 08:09:06 <_Posterdati_> I did nothing 08:09:15 <_Posterdati_> not even frequency scaling 08:10:04 oily josh teh third of syria palaestina, 73°C? 08:10:28 <_Posterdati_> yes 08:10:35 <_Posterdati_> it is a bit high 08:12:03 do you have thermal paste 08:12:09 <_Posterdati_> yes 08:12:23 <_Posterdati_> changed six months ago 08:13:47 <_Posterdati_> fan was cleaned 08:14:01 <_Posterdati_> and sometimes I use air to flush dust 08:14:19 okay 08:14:22 so the machine just runs hot 08:14:34 <_Posterdati_> because fan does not change speed 08:14:44 <_Posterdati_> at boot it goes high 08:14:56 <_Posterdati_> then slow down during boot 08:15:40 <_Posterdati_> there are dev.cpu.X.coretemp.tjmax = 105.0C 08:15:45 <_Posterdati_> but I cannot change it 08:15:55 <_Posterdati_> it says read only parameter 08:17:33 yes 08:17:35 it is 08:17:46 <_Posterdati_> now I placed the laptop over a fancoil hatch :) 08:17:48 at that temperature the machine should switch off automatically to protect itself. 08:17:59 <_Posterdati_> temp is decreasing 08:18:05 <_Posterdati_> ok 08:18:50 <_Posterdati_> 40 C 08:18:53 <_Posterdati_> now 08:19:14 should be an acceptable temporary workaround 08:19:47 <_Posterdati_> :( 08:19:52 <_Posterdati_> cannot work with it :) 08:20:33 oh 08:21:26 <_Posterdati_> what is dev.cpu.X.coretemp.delta ? 08:21:53 does `sysctl -d dev.cpu.X.coretemp.delta` tell nothing? 08:22:09 <_Posterdati_> yes it does 08:22:59 <_Posterdati_> a changing number from 59 to 63 08:23:09 <_Posterdati_> now 65 08:23:47 `-d` stands for describe; i seem to recall that delta was meant to be the "delta between current temperature and Tjunction.max" 08:24:09 <_Posterdati_> Delta between TCC activation and current temperature 09:02:36 is this intel cpu? 09:02:45 hello 09:08:18 as coretemp is working, it has to be intel, for amd it would be amdtemp 09:42:53 you can't change built tjmax. what i suggest ( if the CPU is 6th or newer generation ) is to set epp to 100 - that's maximum powersave 09:43:58 i.e dev.hwpstate_intel.%cpunumber.epp = 100 ( and then for all cores ) 09:44:29 if, then, maximum performance needed i set all to "0" 09:44:39 it works quite well 09:45:23 powerd, as well as powerdxx do not work with hwpstate driver and it is useless to set them, if tried at all 12:41:01 There is no mention here of etcupdate/merging of etc files... How should that happen now with pkgbase? https://docs.freebsd.org/en/books/handbook/cutting-edge/#pkgbase 12:57:34 pkg has a three way merge facility, I think with @config in the plist 14:43:38 nimaje: I believe that three way merge has failed me. I don't know why yet. https://dan.langille.org/2026/08/07/freebsd-etc-pam-d-sshd-was-updated-overwritten-no-merge-attempt/ 18:12:14 I was absolutely shocked that I couldn't mount a UDF disk image - I burned a few hours on this until I found this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=120989 18:14:21 but it looks like someone is working on it now, but really didn't occur to me that something that's been around for so long wasn't supported. 18:15:21 you can blame Sylve I guess, because when working on converting a Windows VM from BIOS to UEFI I had to pull things off the windows install DVD and... oops. Had to resort to the mac for that. 18:33:31 spork_css_: probably weak workaround to mount, but assume "7z x" could works there... ;D 19:03:58 dvl: did it drop a /etc/pam.d/sshd.pkg{new,save} file in? 19:06:23 dvl: it does try a three-way merge, but if that fails then it's supposed to install the 'new' version as foo.pkgnew and let you reconcile the differences 20:34:08 it would be convenient if it told you there are relevant files and to run find /etc /usr/local/etc -name '*.pkgnew' -ls to see the files 22:04:24 kevans: No /etc/pam.d/sshd.pkg{new,save} found. :/ 22:05:30 kevans: for any of the jails, on any host. 22:14:41 there any way to enlarge the max pf table name limit? 31 chars is tough to squeeze into 22:22:44 should really be doubled 23:34:55 scoobybejesus: this cannot happen in /usr/local, but agreed on principle 23:38:31 It really should be added to the Handbook documentation. Almost every 3rd party guide/how-to for pkgbase includes it. 23:38:49 I'm surprised it's not there already (might just be a lingering needed approval, though)