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 <[email protected]> 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, [email protected] <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
