public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sreeni <sreeni.pulichi@gmail.com>
To: "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory Management during Program Loading
Date: Tue, 28 Jun 2005 15:09:56 -0400	[thread overview]
Message-ID: <94e67edf05062812096ece6cf7@mail.gmail.com> (raw)
In-Reply-To: <200506281858.j5SIw2dr013640@turing-police.cc.vt.edu>

My main aim is to run a particular application in a known and fixed
physical memory location. When kernel loads this binary, is there a
way to force it to load at that fixed memory location. For example I
always wanna run a program "hello_world.bin" from physical address
location 0x007F_0000 to 0x007F_FFFF. I want my data, stack etc to be
in this location only.

The word "secure" is our internal terminology which seems to be bit confusing.

Thanks
Sreeni

On 6/28/05, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Tue, 28 Jun 2005 14:12:43 EDT, Sreeni said:
> 
> > We have a "Bus Monitor hardware" which monitors and polices the bus at
> > the specified physical address.
> 
> What does this hardware do, exactly, in addition to the usual memory-protection
> capabilities of the main processor?  I suspect the answer to your query will
> depend largely on what your monitor does, exactly, and what capabilities
> it has, and what threat model you're trying to secure against....
> 
> > Basically we need to run "secure" program under the supervision of the
> > Bus monitor hardware.
> 
> Is there an actual "threat model" here, as in "the attacker might try XYZ,
> and this monitor is a defense because it does ABC, rendering XYZ ineffective"?
> 
> I'm unclear on how the monitor can provide any *real* security when it quite
> likely does *not* have access to the entire state of the system (in particular,
> if there's a security-critical value that's still in a CPU register or L1
> cache line...)
> 
> > Kernel can see the "secure" memory region, and kernel is reponsible for enabling
> > the "Bus monitor Hardware".
> 
> The problem is that you're using an unsecured kernel to initially load the secure
> memory region - so an attacker is free to load broken code into the secure
> area.  The usual "trusted system" solution for this is to ensure that the kernel
> *also* runs inside the tamper-proof evironment....
> 
> Or is the *real* question here "We have a bus analyzer that can't see all of
> the physical memory, so we need the code we're interested in to be in the
> part of physical memory it can see"?  If that's the case, totally different
> answers will probably apply (as we don't have to do things in a "secure" manner,
> we just need to get the right pages in the right frames before the analyzer is
> turned on).....
> 
> 
> 


-- 
~Sreeni
       -iDream

  reply	other threads:[~2005-06-28 19:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-28 17:49 Memory Management during Program Loading Sreeni
2005-06-28 18:00 ` Valdis.Kletnieks
2005-06-28 18:12   ` Sreeni
2005-06-28 18:58     ` Valdis.Kletnieks
2005-06-28 19:09       ` Sreeni [this message]
     [not found]         ` <94e67edf050628122441f6178@mail.gmail.com>
2005-06-28 20:13           ` Sreeni

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=94e67edf05062812096ece6cf7@mail.gmail.com \
    --to=sreeni.pulichi@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox