On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote: > > On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek > Marczykowski-Górecki wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com wrote: >> > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com >> wrote: >> > > >> > > I preemptively submitted this PR to see what the Qubes team thinks. >> > > https://github.com/QubesOS/qubes-vmm-xen/pull/70 >> > > >> > > I agree it probably should be fixed upstream, although I've seen the >> Qubes >> > > team make exceptions and apply their own changes. Upstream would >> probably >> > > take a huge amount of time to get merged and tested. I'm not a >> developer >> > > though so I'm sure you could explain the issue better than I. If you >> do >> > > mention it, CC me as well! I like the CLI argument idea, that's >> probably a >> > > much cleaner way of doing it and defaulting it to true. That way >> users >> > > could disable it if needed due to hardware screw-ups. >> > > >> > >> > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is >> > probably as good a place to start the (github) discussion I suppose. >> > >> > I expect Claudia is correct that it's really a Xen defect to address, >> > either with a flag to disable the check, or security/stability focused >> > checks only. >> > >> > Xen might point upwards again, of course, and tell AMD to fix their >> > microcode or manufacturer's their BIOS's... >> > >> > ...but if a disable flag could be added (--yes_i_know_what_im_doing >> caveat, >> > of course) that'd be a good short term workaround for the larger Qubes >> user >> > base that is less likely to be able to figure out how to get a build >> > working and rpm applied and keep up to date with upstream. >> >> (continuing discussion from the above PR) >> >> The patch as it is, is not acceptable, as it may introduce security >> and/or stability issues on some machines. Xen (and Linux too) assumes >> what CPU features is can use based on CPUID flags. If those changes >> during system runtime (including suspend/resume) some instructions or >> control registers may no longer be valid (->crash) or safe to use >> (->security issue). >> > > Appreciate you joining the discussion Marek, your input is really valued :) > > >> >> If that's just about microcode updates, that's probably BIOS bug - if it >> applies microcode update on system startup, it should do the same on >> system resume too. Anyway it's worth trying updating linux-firmware >> package, which carries microcode updates for AMD. This should make Xen >> apply microcode updates too - before checking those flags. >> I've just uploaded updated version of the package to the current-testing >> repository (both R4.0 and R4.1). >> > > I totally understand the resistance to merge the PR and that the real > cause of the issue should be fixed in BIOS or OS CPU microcode. > > I will be testing that new linux-firmware package on R4.0 shortly and will > report back, thanks for uploading it. I've used my laptop on and off all > day with suspending it multiple times using the "hacky" patch. If the new > microcode works, it shouldn't write the log line saying it has missing > features. I still have the vmm-xen packages I built with the modified patch > installed. >
I installed the new linux-firmware in dom0, rebooted and tested a suspend/resume. Sadly the Xen log says the bits changed still so I'm guessing this will have to be addressed by AMD and hardware manufacturers. Will have to put some thought into what to do next. > > >> >> If that's about something else, then fixing it would require finding >> what exactly is changing (and preferably also why). And only then find >> how to mitigate this issue. If specific flags would turn out to be not >> related to security features or otherwise having unwanted effects, then >> ignoring those changes would be an option. But ignoring _only those >> flags verified to be safe to ignore_, not all of them. >> > > I hope it doesn't come to that but we'll see. I wouldn't really know what > else to do besides complain to Lenovo and hope they yell up at AMD to > investigate. I assume it's something weird between hardware manufacturers > and AMD. > > >> >> - -- >> Best Regards, >> Marek Marczykowski-Górecki >> Invisible Things Lab >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> -----BEGIN PGP SIGNATURE----- >> >> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4/abcACgkQ24/THMrX >> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq >> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F >> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh >> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM >> 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz >> iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg== >> =h62J >> -----END PGP SIGNATURE----- >> > > P.S. the bits do change for me as stated in the Xen log when I resume from > a suspend. Here is what mine says. > > (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b) > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/07ec6e05-8a0f-41c6-916a-320e5fee25d5%40googlegroups.com.
