Only on a real 286. At least since 486 the legacy switch has been INIT, not RESET.
Alexander Graf <ag...@suse.de> wrote: > > >Am 14.06.2013 um 08:56 schrieb Christian Borntraeger ><borntrae...@de.ibm.com>: > >> On 13/06/13 13:56, Anthony Liguori wrote: >>> Markus Armbruster <arm...@redhat.com> writes: >>> >>>> Peter Lieven <p...@kamp.de> writes: >>>> >>>>> On 13.06.2013 10:40, Stefan Hajnoczi wrote: >>>>>> On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: >>>>>>> I was thinking if it would be a good idea to zeroize all memory >>>>>>> resources on system reset and >>>>>>> madvise dontneed them afterwards. This would avoid system reset >>>>>>> attacks in case the attacker >>>>>>> has only access to the console of a vServer but not on the >physical >>>>>>> host and it would shrink >>>>>>> RSS size of the vServer siginificantly. >>>>>> I wonder if you'll hit weird OS installers or PXE clients that >rely on >>>>>> stashing stuff in memory across reset. >>>>> One point: >>>>> Wouldn't a memory test which some systems do at startup break >these as well? >>>> >>>> Systems that distinguish between warm and cold boot (such as PCs) >>>> generally run POST only on cold boot. >>>> >>>> I'm not saying triggering warm reboot and expecting memory contents >to >>>> survive is a good idea, but it has been done. >>> >>> Doesn't kexec do a warm reboot stashing the new kernel somewhere in >>> memory? >> >> It does something like that on s390. >> There is a diagnose instruction to the machine, that resets all >> subsystems and cpus in a defined state, but lets the memory >untouched. >> So we want to be able to define the components of the system which we >are >> going to reset and have two cases: >> 1. reset everything and clear the memory >> 2. just reset the cpus and devices, but leave the memory untouched >> >> For case 2 we basically want to avoid memory clearing AND bios >reloading > >Legacy 286 protected mode to real mode switching also happens through >the CPU reset PIN, so there certainly is a need to distinguish. > >Alex > >> >> >> -- Sent from my mobile phone. Please excuse brevity and lack of formatting.
