13:00:53 <|cos|> I managed to get libc with debugging symbols built after putting SOURCEDEBUG=yes in the right place, but that's not all the way to a debuggable state. 13:02:41 <|cos|> Skipping optimizations seems like a needed step. Also rebuilding C++ libraries, for which I am a bit more lost. Is core C++ part of illumos-gate? 13:04:25 <|cos|> My stackstrace is at the bottom of https://www.netizen.se/docs/urxvt-out_of_input in case anyone would happen to have a set of very helpful spare eyes. 13:43:59 |cos| what seems to be the problem there? 13:44:59 <|cos|> tsoome_: urxvt crashes, within minutes of normal use. i'm hoping to figure out why. 13:51:32 yes, that much I figured:) 13:53:36 but from that stack trace? if you are getting __cxa_throw from cmd_getc, it should be traceable from the source? 13:57:04 <|cos|> it is highly possible that my approach is all wrong. my assumption is that it'll be a challenge for me to figure out this bug even with debug symbols, but that i might have a chance with them. 14:11:17 <|cos|> the thing making it tricky to simply step the code is that there is a signal boundary to cross, but i guess discussing that would be way too verbose for this channel. 14:11:24 [illumos-gate] 17414 bhyve could iterate over GPTs better -- Patrick Mooney 14:16:42 ya. bad thing is that tar download does not seem to happen atm:) 19:05:14 [illumos-gate] 17405 clarify tools usage in nightly(1) -- Patrick Mooney 19:05:54 gotta love Intel putting out a security bulletin that literally says "A subset of affected processors may need to apply additional software mitigations, details of which can be found at the Linux* kernel Github* link in the Related Content section." where the link is simply to the top level of the Linux git repo, suggesting the fix is simply to adopt the Linux kernel in its entirety 19:06:07 https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/indirect-target-selection.html 19:07:51 alanc: lol 19:08:42 just guess which of the 1,352,981 commits in that repo apply to this issue, what are the odds? 19:16:47 any chance the CVE might be in the relevant commit msg? 19:17:00 just don't branch, imo 19:34:49 The CVE id appears in one of the documentation files, but I don't see it in the commit history 19:35:22 and the documentation was a separate commit from the fix: https://github.com/torvalds/linux/commit/1ac116ce6468670eeda39345a5585df308243dca 19:35:22 → GitHub commit 1ac116c: Documentation: x86/bugs/its: Add ITS documentation (committed) 19:40:29 pretend I made a pdp-10 joke 19:42:19 alanc: perhaps https://github.com/torvalds/linux/commit/f4818881c47fd91fcb6d62373c57c7844e3de1c0 ?? 19:42:36 seems a reasonable thought 19:42:46 I was going to say look at commits around (before?) the doc one, that have a wrmsr in 19:43:24 (I took the max power approach and looked for the files that referenced the tunable and then did a git blame) 19:43:41 which this wouldn't have found, because this looks to be super stupid 19:47:31 danmcd: I assume this is why you're updating ucode? 19:47:47 danmcd: so maybe you're interested in this goose too 19:48:17 Interesting... Xen leaked a day early too. 19:49:24 this is the one they told us last week was going to be released on Monday, ahead of the normal Patch Tuesday batch tomorrow 19:51:01 presumably because https://www.vusec.net/projects/training-solo/ is being presented at https://sp2025.ieee-security.org/ which starts today so may be available to attendees in the proceedings 19:52:04 or actually, to anyone with IEEE library access now: https://www.computer.org/csdl/proceedings/sp/2025/21B7ONGXzZ6 20:00:03 alanc: sounds right. 20:00:30 Oh BTW alanc esp => Xen may have leaked it early. 20:00:42 See the oss-security alias. 21:31:30 do any of you who know ID mapping, know of anything that would happen when the idmap service is restarted that does not happen when it is started? 21:32:32 or whether idmap changes its behaviour based on services or facilities that are available when it starts 21:32:51 the bug I'm chasing turns out to go away entirely if, after idmap is started, I restart it 21:33:15 which is unfortunate both in amount of time I've wasted, and amount of time I have to waste to get it broken 21:37:26 restart or refresh? 21:37:41 (doesn't the former stop/start, while the latter HUPs?) 21:38:21 also what behavior are you seeing specifically? 21:39:38 specifically restart, refresh didn't (though I did not change a property, and also refresh) 21:40:00 the behaviour is that the `findroot` test sommerfeld added fails, because the first SID vanishes from idmap's knowledge almost immediately 21:40:14 it can be condensed to `; /usr/bin/find . -sidacl S-1-5-21-44444444-55555555-66666666 && idmap dump -v && /usr/bin/find . -sidacl S-1-5-21-11111111-22222222-33333333 && idmap dump -v` 21:40:40 (you should pick an empty directory, or the find will take ages for no reason) 21:41:12 it works on x86, I should add 21:42:11 on arm, if idmap has not been restarted, the first SID vanishes from the 2nd dump 21:42:17 if it has been restarted, it's fine 21:42:24 I have not yet checked if it has been disabled/enabled, rather than restarted 21:42:38 because this is all a bit time consuming, now I know it has to be fully reset each time to test it 21:43:19 (this also means enabling the debugging is unfortunate, in as much as the act of doing so means it will now work) 21:49:33 disable && sleep 5 && enable is equivalent to 'restart'ing, result wise 22:05:14 richlowe: I recall you mentioning something like this a while back. some sort of machine-dependent quirk? hidden dependence on memory ordering? 22:07:26 I'm still trying to track down in what situations it works and doesn't. 'refresh' is not sufficient, even with a property change. 22:07:40 but immediately after reboot, is broken, it doesn't have to be a _clean_ image 22:08:06 tomorrow, it's truth table time just so I don't forget. 22:15:00 another one for IPD 14: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/strlog.h#L55 22:19:17 I'm not deeply familiar with the idmap code and it's got enough asynchrony to it that it's a pain to understand what it's going. 22:19:32 what it's doing or where it's going. take your pick.. 22:26:09 ephemeral mappings are stored in an sqlite (not sqlite3) database in /var/run/idmap/cache.db 22:27:05 so it could be an sqlite bug 22:27:15 long since fixed in sqlite3 22:43:03 so in terms of "how is the first start different from subsequent starts", the first one since reboot creates cache.db; later ones reuse it. 22:48:10 so one informative experiment would be to convert idmapd to sqlite3 and see if the problem goes away. 22:48:48 and, well, if it doesn't fix it on arm we've at least upgraded it to sqlite3 23:14:13 actually, I think there's some locking missing in idmapd around ephemeral id allocation. 23:15:46 allocation happens in `get_next_eph_uid`, called from `dynamic_ephemeral_mapping` and walking up the call stack I don't see anything taking a write lock. 23:26:23 (unless rpc-over-doors single-threads the server..)