All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Gorm Hansen <jacobg@diku.dk>
To: xen-devel@lists.sourceforge.net
Subject: Re: boot loaders for domain != 0
Date: Thu, 03 Feb 2005 17:09:28 -0800	[thread overview]
Message-ID: <4202CB48.2040704@diku.dk> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D1236E4@liverpoolst.ad.cl.cam.ac.uk>

Ian Pratt wrote:
>>For what it's worth, I think doing a quick mount, read, and 
>>then umount 
>>is the easiest approach since it extends well to doing things like 
>>peeking at an ISO's contents by mounting an ISO image.  Using 
>>libraries 
>>would probably introduce some nasty dependencies without 
>>really gaining 
>>much...
> 
> 
> From a security POV, using libext2 etc would be raher better. I just
> don't trust Linux to be defensive enough mounting a potentially
> malicious bag of bits. [I once came across an ext2 file systems that
> deterministically crashed Linux whenever I mounted it. It's been a
> couple of years, but I reckon such bugs are still lurking.]

Then libext2 would have to run as a non-root user, and feed its output 
to a root process doing the actual domain building, assuming that there 
is no way of making the domain builder or libz choke on the kernel image 
that is...

For real security, all this stuff has to be happen within the domU. In a 
perfect world, privileged code should never read user-supplied data, but 
given that this world is not perfect, you could relax that to not 
reading any variable-length user-supplied data.

Given that both the (perhaps compressed) ELF image and the Ext2 
filesystem contain variable-length data, neither should be read by code 
in dom0.

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

  reply	other threads:[~2005-02-04  1:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-03 22:11 boot loaders for domain != 0 Ian Pratt
2005-02-04  1:09 ` Jacob Gorm Hansen [this message]
2005-02-04  2:16   ` Building domains as a lesser user (was Re: boot loaders for domain != 0) Anthony Liguori
2005-02-04  3:12     ` Jacob Gorm Hansen
2005-02-04  3:16     ` Jacob Gorm Hansen
2005-02-04  3:34       ` Anthony Liguori
2005-02-04  3:56         ` Jacob Gorm Hansen
  -- strict thread matches above, loose matches on Subject: below --
2005-02-03 17:28 boot loaders for domain != 0 Ian Pratt
2005-02-03 18:06 ` Jeremy Katz
2005-02-03 18:49 ` Anthony Liguori
2005-02-03 19:32 ` Jan Kundrát
2005-02-03 14:28 Ian Pratt
2005-02-03 16:57 ` Jeremy Katz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4202CB48.2040704@diku.dk \
    --to=jacobg@diku.dk \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.