<baka>
ruled out some random differences i noticed, stuff like "perhaps it doesnt like spaces in the description string anymore".
<baka>
heh. generated 1000+ new rsa2048 keys, all load fine into the agent. related discoveries: 25MB vm memory is enough for 1000 keys easily. but ssh-add -l stops working around 500 keys. :D
<baka>
oh. or not. interesting. the "ssh-add -l" fails with "out of memory"
<baka>
it claims to successfully add more keys at that point though.
jnavila_ has joined #mirage
<reynir>
Haha
<baka>
well, i am not going to open a ticket for that one. :D
<baka>
but it was worth a try if i could find some other key that refuses to load.
<reynir>
I could probably do that more efficiently. I think the output is first assembled in memory and then sent
<baka>
wouldnt bother, afair more than three keys is not very useful since thats a limit on the ssh handshake side.
<reynir>
I use 6 keys, and using IdentitiesOnly + IdentityFile in ~/.ssh/config fixes that
<baka>
adding key encrpytion is going to drive up memory need a lot. (well, "a lot". openssh is using 16kb per key afaict)
<baka>
hannes: if my primary work key for the last 15 years turns out to be "invalid", i am going to cry!
<hannes>
baka: as I said, I'd _try_ that. I'm not saying that your key does not use prime numbers.
<hannes>
(but then, the error from priv_of_primes should be somewhere -- hopefully the ssh-agent doesn't eat it, but displays it on console)
<baka>
(oh, now "ssh-add -D" also says "out of memory" agent-side, but again, i guess 1000 keys is slightly overdoing it.)
<baka>
probably tries to fetch a list first. :D
<reynir>
Huh, interesting
<baka>
no message whatsoever (besides the generic qubesrpc logging) on the agent console when the add fails.
<baka>
gonna read some code.
<baka>
(well, not that this is likely to help. but now i have plans to sprinkle the central "match request with" with a LOT of Log.info!)
<baka>
huh. that remove_all_identities looks like it really shouldnt be able to run into oom
jnavila_ has quit [Ping timeout: 246 seconds]
<reynir>
Yea
<reynir>
If the key is considered invalid the agent should throw a parse error AFAICT
<reynir>
Ah, but parse errors are logged as debug messages!
<reynir>
48s/debug/warn/
<reynir>
baka: it's a bit annoying that in order to reproduce you'd have to hand me over your very secret key :D
<reynir>
baka: Can you add »Logs.Src.set_level src Logs.Debug;« to the beginning of Unikernel.Main.start ?
jnavila_ has joined #mirage
<hannes>
reynir: I doubt you'll convince baka to hand over their private key -- I'd suggest instead to try to isolate the root cause on some branches (being it with more printf debugging to ensure that e.g. parsing was successful)
<reynir>
:)
jnavila_ has quit [Ping timeout: 246 seconds]
<hannes>
and if reported on warning level, this should be visible in the console by default (unikernels use info level by default) -- instead of modifying code, you can "mirage configure -t xen -l \*:debug" to increase the log level (or at boot time in case you have boot arguments)
<reynir>
It's reported on debug level
jnavila has joined #mirage
<hannes>
you should use warning level :)
<baka>
reynir: thats why i was trying to find some key i can hand over. :D
<baka>
reynir: where is that "Unikernel.Main.start"?
<reynir>
baka: unikernel.ml, but hannes's suggesting of using mirage config -t xen -l \*:debug is nicer
<baka>
*frowns* ... checking. :)
<baka>
(ah, thats hiding in builder-mirage!)
<baka>
thats not the kind of thing i need to nuke my ~/.opam for to be sure, yes?
<reynir>
wait, maybe I'll just make it log as warning instead..
<baka>
nah! i want to see it on full debug level anyways!
<reynir>
OK :)
<baka>
there might be more interesting stuff!
<hannes>
baka: no need to nuke your .opam.
jnavila has quit [Ping timeout: 256 seconds]
jnavila has joined #mirage
<baka>
heh. so it is logging more now, i am getting three lines of qrpc logging for each connection instead of one, still nothing related to the error though.
<baka>
"ssh-add -l" and "ssh-add badkey" still log the same generic three lines.
<hannes>
this is reasonable good news ;)
<baka>
reynir: oh, unrelated but because of that topic yesterday ... what are you seeing the rng from now? does it include the qubes-random-seed from qubesdb?
<hannes>
well, for me. not for you since you've to look further for the issue
<reynir>
baka: I added about 470 keys until I got out of memory, and then ssh-add -D worked :o
<baka>
reynir: yeah, i am confused how i got it to the point where -D stopped working, because i am very sure it did work with 1k keys on an earlier run.
<baka>
reynir: who knows, i may have driven it so far oom that allocating an empty array didnt work anymore! :D
<reynir>
:D
<baka>
(no, i am not going to add forced garbage collection calls to the agent. thats for the firewall!)
hannes_qubes has joined #mirage
<hannes_qubes>
I'll use this to transport some data -- https://pastebin.com/sVi4nZk5 contains the commit IDs which may be useful to get into mini-os/next-pvh branch.
hannes_qubes has quit [Remote host closed the connection]
jnavila_ has joined #mirage
jnavila has quit [Ping timeout: 246 seconds]
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #mirage
jnavila_ has quit [Remote host closed the connection]
<baka>
hannes: hm-hm. did the repo-add and mirage configure and build ... and the binary has the same hash as before the repo add.
<baka>
hannes: which is probably related to the -dev part of mirage-dev, i dont know what that means or how to make the build use it.
<hannes>
baka: after the repo add, maybe you need an opam update
<hannes>
you'll need an opam upgrade for sure if you already have stuff installed into your switch. you should receive mirage version 3.7.7(!) during this upgrade
<baka>
ah. opam update is part of the build, but upgrade is not.
<baka>
a "nuke ~/.opam and try again" is already running, i guess that is upgradey enough.
<hannes>
yes, that should do the trick as well
<baka>
"restart, reinstall, replace"
jnavila has joined #mirage
<hark>
so, in PrintExn there is a type called location (with is a record with file, line number ,etc) but i can't find a function to go from a raw_backtrace_slot to a location, and raw_backtrace_slot is an abstract type
<hark>
is the only way to get a non string version of the backtrace to parse the string (you can go from a raw_backtrace to a string)
<hark>
i am trying to write something that gives line numbers in log entries
<hannes>
hark: AFAICT, there's Printexc.convert_raw_backtrace_slot which gives you a backtrace_slot
<hannes>
and then "Printexc.Slot.location : t -> location option" (where t is defined as type alias to a backtrace_slot)
<hark>
aah, now i see, backtrace_slot has a location function
<hark>
s/function/value
<hannes>
baka: does it compile + does it run?
<hannes>
i still don't quite understand xen vs qubes target -- afaict qubes-ssh-agent and qubes-mirage-firewall use "-t xen", and not "-t qubes" -- any idea why this is the case? or: when should I use "-t qubes", and what (in mirage) should depend on "-t qubes"?
<baka>
hannes: yes, it compiled, 85 min ... ugh ...and it used mirage 3.7.7
<baka>
oeh. i am unsure how to run it now.
<baka>
i probably need some other version of grub...
<hannes>
qvm-pref set virt-mode pvh and run it
<baka>
yes, thats what i tried. doesnt work at all, probably because i am using pvgrub, and am now looking for some kind of pvhgrub ...
<hannes>
there shouldn't be the need for grub anymore iiuc
<baka>
oh. i a using the templated version, as in the unikernel is _inside_ the vm root fs, and is loaded from there by grub.
<baka>
guess for testing i could try copying it to dom0 ...
<baka>
(as soon as i remmeber how to do that!)
<hannes>
hmm, from my pov there's no "root fs", there's just the unikernel in dom0 ;)
<baka>
pft, thats the legacy format!
<hannes>
oh :/
<baka>
i will try with dom0 kernel for testing, it makes sense to cut out grub for the moment.
<baka>
i _do_ have a grub-x86_64-xen.bin here that looks like it might be a pvh-capable grub2 ... but not changing two major parts at once mebbe.
<baka>
doesnt start, doesnt print anything to console log
<hannes>
doesn't sound convincing then :/
<baka>
nah, i meant ... if i deploy it as a dom0 kernel ... it doesnt start and doesnt tell me why.
<baka>
it fails moderately quickly though, way sooner than qrexec timeout
<baka>
lets wait a bit if someone else has more success than me, it might be something in my build process.
<hannes>
maybe i can convince myself to boot qubes and try that myself ;)
<baka>
(cranked up memory to 100 just in case, nope, doesnt help)
adhux0x0f0x3f has joined #mirage
adhux0x0f0x3f-- has joined #mirage
adhux0x0f0x3f has quit [Ping timeout: 240 seconds]
<hark>
baka: you shouldn't use a grub at all
adhux0x0f0x3f has joined #mirage
<hark>
aah, it is what you are trying to get to work, nevermind
adhux0x0f0x3f-- has quit [Ping timeout: 240 seconds]
adhux0x0f0x3f-- has joined #mirage
adhux0x0f0x3f has quit [Ping timeout: 240 seconds]
<baka>
hark: well, _something_ needs to load the unikernel, and for the last year or so that has been grub here.
<baka>
marmarek: so what grub magic handshake do i need for mirage-pvh? :D
<hark>
baka: you are running on xen no?
<hark>
then xl can load the unikernel
<baka>
hark: qubes, which means xen, and "templated" means the unikernel is not available in dom0.
Hrundi_V_Bakshi has joined #mirage
<baka>
hark: the general idea is to have mirage vms in a templated form so you dont need to install them in dom0. longterm goal being to get away from "everyone needs to compile their own mirage vms", more "users can install a mirage-vm compiled/provided by others".
<hark>
aah, so there will be a pvgrub qubes template?
mahmudov has quit [Ping timeout: 264 seconds]
<baka>
hark: the pvgrub is already there in dom0 actualy, and thats what qubes is considering the "kernel" for these mirage vms.
<baka>
hark: and the template rootfs has a grub.cfg and the unikernel.
<baka>
hark: this has been working quite well for me, but i am probably the only one who uses it. :/
mahmudov has joined #mirage
<reynir>
hannes: IIRC the qubes target does some things automatically, qubesdb and maybe networking. I don't remember why I'm not using it in the ssh-agent
<marmarek>
what you need in your VM, is a config for that grub
<marmarek>
AFAIR the issue is that grub currently (2.04 version) don't know how to load native PVH binaries, only legacy entry point (and maybe multiboot2)
Hrundi_V_Bakshi has quit [Quit: No Ping reply in 180 seconds.]
Hrundi_V_Bakshi has joined #mirage
<hannes>
marmarek: i suspect the latter is easier for us to fix -- though I've no clue what this entails.. are there tools around to generate a multiboot2 image out of a pvh image?
<marmarek>
not sure, but most likely involve changes to the boot code (x86_64.S, x86_hvm.S)
<marmarek>
not sure how start_info is communicated using multiboot, fortunately on PVH we need much less of it
<marmarek>
is it only cmdline now? maybe also memory map (but not sure about it really)
<hannes>
there's no start_info used anymore afaics
<hannes>
the static "cmdline" is used, apart from that hvm_get_parameter (on the OCaml side, likely need to re-check the mini-os side)
<hannes>
baka: oh, incidentally I found an issue in the mirage-xen branch I prepared/advertised... a rebuild (opam reinstall mirage-xen followed by mirage clean && mirage configure && mirage build) may lead to better working pvh unikernels
<hannes>
marmarek: yes, it looks like cmdline is the only thing that uses hvm_start_info
<marmarek>
if so, that should be not that complex, as I think multiboot2 also contains cmdline easily accessible
<hannes>
doesn't look too complex (though i always thought our minios/unikernel image would be 64bit elf executable -> now they say it must be 32bit (maybe minios switches to 64bit mode early on), and boot arguments are available via a struct where ebx points to)
jnavila has quit [Remote host closed the connection]
<hannes>
ah, the solo5 virtio binding uses multiboot for cmdline and mapped memory (afaict, mini-os pvh uses some other magic for memory maps)
hannes_qubes has joined #mirage
<hannes_qubes>
hmm, any non-trivial unikernel (that uses network / rng / ...) does immediately exit with the pvh-branches :( I don't even see any output from mini-os on the console
hannes_qubes has quit [Remote host closed the connection]
Hrundi_V_Bakshi has quit [Ping timeout: 250 seconds]
<marmarek>
initial pvh boot part is also 32bit, but switches to 64bit very early (still in x86_hvm.S)