Memory Management during Program Loading

Memory Management during Program Loading

[Sreeni]

Hello,

I have a query regarding memory management using Linux kernel.

In our system we have a secure physical memory starting and ending at 	
predefined addresses. We want to execute certain programs, which have 	
to be running secure in those address spaces only. 

Is it possible to force the loader to load the "particular" program 
(both the code and data segment) at that pre-defined secure physical 	
memory, without any major kernel changes?

Thanks,

Sreeni

(sreeni@nec-labs.com)

Re: Memory Management during Program Loading

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Tue, 28 Jun 2005 13:49:46 EDT, Sreeni said:
> In our system we have a secure physical memory starting and ending at	
> predefined addresses. We want to execute certain programs, which have	
> to be running secure in those address spaces only.

Can you explain how this memory is "secure", and how you expect a kernel that's
running *outside* this secure space to load a program into it?

> Is it possible to force the loader to load the "particular" program 
> (both the code and data segment) at that pre-defined secure physical 	
> memory, without any major kernel changes?

It's more complicated than that - not only do you need to worry about running
the program in that space, you also need to worry about things like malloc()
space for the program, I/O buffers, and so on.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Memory Management during Program Loading

[Sreeni]

Thanks you Valdis for your reply.

We have a "Bus Monitor hardware" which monitors and polices the bus at
the specified physical address.

Basically we need to run "secure" program under the supervision of the
Bus monitor hardware.

Kernel can see the "secure" memory region, and kernel is reponsible for enabling
the "Bus monitor Hardware". 

Thanks,
Sreeni

On 6/28/05, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Tue, 28 Jun 2005 13:49:46 EDT, Sreeni said:
> > In our system we have a secure physical memory starting and ending at
> > predefined addresses. We want to execute certain programs, which have
> > to be running secure in those address spaces only.
> 
> Can you explain how this memory is "secure", and how you expect a kernel that's
> running *outside* this secure space to load a program into it?
> 
> > Is it possible to force the loader to load the "particular" program
> > (both the code and data segment) at that pre-defined secure physical
> > memory, without any major kernel changes?
> 
> It's more complicated than that - not only do you need to worry about running
> the program in that space, you also need to worry about things like malloc()
> space for the program, I/O buffers, and so on.....
> 
> 
> 


-- 
~Sreeni
       -iDream

Re: Memory Management during Program Loading

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Memory Management during Program Loading

[Sreeni]

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

Re: Memory Management during Program Loading

[Sreeni]

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