Hello, Ingo.

On Tue, Jan 25, 2011 at 03:09:48PM +0100, Ingo Molnar wrote:

I think the biggest areas of practical concern would be:

 - Can this mechanism ever, under any circumstance corrupt any real
   data, destroy the MBR or do other nasties. Can you think of any
   additional fail-safe measures where you could _further robustify
   the BIOS calls_ to make sure it can never go to the wrong
   sector(s)? I really do not want to think of trusting a BIOS to
   _write to my disk_.

It's quite unlikely but I wouldn't say it's completely impossible.
It's common for ATA controllers to have dual modes of operation - the
old IDE compatible interface by emulation which is used by BIOS and
older operating systems and newer interface (ahci) to be used by
modern OS.  Some need to be explicitly switched and some just need to
be accessed carefully.  If the controller is accessed by bIOS after
switched to ahci or commands are in progress via ahci, anything can
happen.

There's also HPA which changes the size of the device which we often
unlock.  As it's always at the end, it usually shouldn't cause
problems but there are BIOSen which expect certain things near the end
of the device (BIOS RAID ones).  I'm fairly sure nobody is testing
BIOSen for cases where the size of underlying device changes without
going through POST.

To summarize, it's unlikely but at the same time there are some
_truly_ scary beasts out in the wild.  There's certain level of
danger.

 - Is there some hidden disk area somewhere on PCs, or somewhere on
   a real partition on typical Linux distributions, which we could
   use without having to reinstall the box? This would increase
   utility and availability enormously. I'm thinking of partition
   _ends_ which sometimes get rounded in an awkward way and which
   are potentially skipped by most Linux filesystems. Even a very
   small, 512 bytes of area would be extremely useful for debugging
   weird suspend hangs ...

There are holes but writing to them without full knowledge of the
configuration can be quite dangerous.  I don't think it would be
possible to mass deploy it without manual configuration unless we
specifically reserve (and maybe mark) it in the filesystem.

 - Could we automate the recovery of the dump, and just put it into
   the regular kernel log on the next (successful) bootup (on a
   feature-enabled kernel)? That would make the log of the 'previous
   crash' very conveniently available in dmesg and the syslog. Tools
   like kerneloops could make use of it immediately.

Yeah, that would be actually quite nice.

All in one, a very intriguing idea IMO, and the hardest bits
(lowlevel x86 transition) is all implemented already.

I like the prospect too but am a bit skeptical whether this can be
made reliable enough to be a convenient tool.

Thanks.

-- 
tejun