Re: Memory Management during Program Loading

[Sreeni <sreeni.pulichi@gmail.com>]

Hello,

 We need the code in the physical memory area which the bus analyzer can see.
 Basically we need to get the right "code" and "data" segment into that
 bus analyzer/monitor activated physical area.
 
 thanks,
 
 Sreeni
 
> >>>>
> 
> 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).....
> 
> >>>
> 
> On 6/28/05, Sreeni <sreeni.pulichi@gmail.com> wrote:
> > 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
> >
> 
> 
> --
> ~Sreeni
>       -iDream
> 


-- 
~Sreeni
       -iDream