linux-kernel - Re: Failover Kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0903051707211.30837@asgard.lang.hm>
Date:	Thu, 5 Mar 2009 17:10:00 -0800 (PST)
From:	david@...g.hm
To:	Tarkan Erimer <tarkan.erimer@...knet.net.tr>
cc:	David Newall <davidn@...idnewall.com>, linux-kernel@...r.kernel.org
Subject: Re: Failover Kernel

On Wed, 4 Mar 2009, Tarkan Erimer wrote:

> On 03/03/2009 05:29 AM, David Newall wrote:
>> It sounds like you want everything to just continue running.  I don't
>> 
> Yes, exactly. Backup kernel will take control when a crush occured without 
> need a reboot or halt.
>> see how that can be done.  All of those in-kernel tables and structures
>> would need to be migrated, and it follows, because there was a crash,
>> that any of them might have been corrupted.  Worse, you want this to
>> save you when you try running a new kernel which crashes, and being a
>> new kernel, it follows that any of those structures could be different;
>> it might not be possible to create equivalent structures for different
>> kernel versions.
>>
>> 
> Yes, that's right and it's the first thing needed to overcome. Maybe, it 
> could be implemented like this :
>
> - Primary kernel could be 2.6.x or 2.6.x.y (2.6.28 or 2.6.28.1)
> - Backup kernel could be one of these .y fix releases only: Like 2.6.28.5
>
> So; when they're from the same version, it will prevent kernel API and 
> structure changes.
> For resuming by backup kernel: The primary kernel could write a journal about 
> the needed things for backup to resume. Like process IDs, memory and process 
> situations etc. The same manner as the Journalled File Systems did (they 
> write a journal what they did to recover/resume at crash/disaster time).

wrong, kernel structures can change in any patch. they can even change 
with different configuration options.

but even if they are the same version and configuration options, that 
doesn't address the fact that you can't trust the in-kernel structures 
because they may have been damaged by whatever caused the crash.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/