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-next>] [day] [month] [year] [list]
Date:	Tue, 03 Nov 2009 01:43:39 -0500
From:	Eric Windisch <eric@...kthis.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: FatELF patches...

First, I apologize if this message gets top-posted or otherwise
improperly threaded, as I'm not currently a subscriber to the list (I
can no longer handle the daily traffic).  I politely ask that I be CC'ed
on any replies.

In response to Alan's request for a FatELF use-case, I'll submit two of
my own.

I have customers which operate low-memory x86 virtual machine instances.
Until recently, these ran with as little as 64MB of RAM.  Many customers
have chosen 32-bit distributions for these systems, but would like the
flexibility of scaling beyond 4GB of memory.  These customers would like
the choice of migrating to 64-bit without having to reinstall their
distribution.

Furthermore, I'm involved in several "cloud computing" initiatives,
including interoperability efforts.  There has been discussion of
assuring portability of virtual machine images across varying
infrastructure services.  I could see how FatELF could be part of a
solution to this problem, enabling a single image to function against
host services running a variety of architectures.

As for negatives: I'm running ZFS which now supports deduplication, so
this might potentially eliminate my own concerns in regard to storage.
Eventually, Btrfs will provide this capability under Linux directly. The
networking isn't much of an issue either, as I have my own mirrors for
the popular distributions.  While this isn't the typical end-user
environment, it might be a typical environment for companies facing the
unique problems FatELF solves.

I concede that there are a number of ways that solutions to these
problems might be implemented, and FatELF binaries might not be the
optimal solution.  Regardless, I do feel that use cases do exist, even
if there are questions and concerns about the implementation.

-- 
Regards,
Eric Windisch

--
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