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@xxxxxx <Valdis.Kletnieks@xxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/