Messages in this thread | | | Date | Fri, 6 Sep 2019 19:10:12 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged |
| |
On Fri, Sep 06, 2019 at 12:43:53PM -0400, Konrad Rzeszutek Wilk wrote: > Do you have insights on the best way to restructure the code for this?
Well, I only started thinking about this when you guys brought it on and you were actually serious about it. :)
So IINM, this is one of the livepatch problems where the universe before the patching and after the patching needs to be consistent, so to speak.
But how do you handle the case where feature detection has happened, a bunch of code is active now and running because the feature is there and then you disable that feature and all that code does what? And what do you tell the user programs which are using it?
Sounds a lot like a reboot to me. :-P
Was the code programmed with the ability to be gracefully disabled at any point in time, in mind? I doubt that. I don't think any of the CPU feature supporting code has been programmed to be disabled at arbitrary points in time.
Now, can you do something like suspend the CPUs, disable some features and resume them and make them re-detect it all again and act accordingly?
Sure, we do some of that but not comprehensively...
So my gut feeling is this is just the tip of the iceberg and the devil is in the detail and all sorts of similar proverbs.
Best guess would be, try to do it and see what kinds of problems you encounter and try to fix them cleanly. I betcha you'll be busy a long time...
:-)
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |