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: <1188264269.2050.16.camel@caritas-dev.intel.com>
Date:	Tue, 28 Aug 2007 09:24:29 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Pavel Machek <pavel@....cz>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>, vgoyal@...ibm.com,
	nigel@...el.suspend2.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-pm@...ts.linux-foundation.org,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/2 -mm] kexec based hibernation

On Mon, 2007-08-27 at 13:15 +0000, Pavel Machek wrote:
> Hi!
> 
> > >> > Does this make sense?
> > >> 
> > >> Yes, this is a sensible optimization. But I think it may be better to
> > >> make bootloader load kernel D directly into a specified memory location.
> > >> For example, we can add a option to "kernel" command of grub. 
> > >> 
> > >> And, I think we can do more in bootloader. Such as we can prepare
> > >> two
> > >
> > > Yes, that would be nice.
> > >
> > > It will mean quite a bit of work, but I guess it should be the long
> > > term goal. Loading restore kernel directly from bootloader means:
> > >
> > > 1) it is fast -- no need to boot another kernel
> > >
> > > 2) it is "classical" way of doing things
> > >
> > > On the other hand, we loose flexibility that way:
> > >
> > > 1) it locks you onto one bootloader
> > >
> > > 2) you no longer have userland there to do uncompression, decryption,
> > > etc..
> > 
> > True although for the uncompression and decryption those aren't exactly foreign
> > requirements for bootloaders.
> 
> Well, uncompression yes, but crypto? What is that, some kind of
> trusted computing thingie?
> 
> We do RSA for uswsusp, that may be a bit of problem for a bootloader,
> but I'm glad bootloaders are bloated already :-).

As far as I know, the grub 2.0 uses a modular implementation scheme.
That is, every OS loader (Multi-boot, Linux, FreeBSD etc), partition
table, file system is implemented as a module, and these modules can be
statically linked into the final image.

So I think the hibernation image loading can be implemented in grub 2.0
in a manageable way. :)

Best Regards,
Huang Ying
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ