Re: Trusted process on an untrusted machine?

From: Mike Frantzen (frantzenat_private)
Date: Wed Jan 19 2000 - 13:00:36 PST

  • Next message: FreeBSD Security Officer: "FW: FreeBSD Security Advisory: FreeBSD-SA-00:01.make"

    > > Some of ways an attacker could bypass this protection:
    > >     Solution:  There should be a LOCK pin on most processors that locks the
    > >                memory bus. The kernel module can lock the bus and proceed to
    > >                zero out all memory not used by the good kernels page tables.
    > No. You can't assume you know about all memory. (And I think LOCK does
    > not work the way you imagine it). Rogue second cpu could be hiding in
    > videoram of PCI card, for example.
    
    You shouldn't need to know about all the memory.  Insert a TLB entry to map
    a page of virtual memory to the first page of physical memory.  Zero it out.
    Proceed to zero out every physical page of memory.  Who cares if there is a
    physical page there or not.  You only have 4gb to go through.  It may trash
    some device detection though.
    
    As to the rogue CPU running in the video card.  IIRC, the video ram is mapped
    right into the cpus address space so it should be zeroed with the rest of it.
    If the memory isn't in the address space, it would be a feat to get the
    processor to execute it.  I don't know if video cards can be told to copy
    video ram back into main memory though.  (I haven't done any demo coding since
    I was 16)
    
    If you can't lock the bus...  Well, thats where the kernel wars come in.
    Hehe, one kernel fighting to zero out memory and the other fighting to copy
    itself to a recently zero'd page.  That just sounds cool.
    
    > Remove heatsink from the cpu. Watch your "trusted" program do
    > single-bit errors from time to time. Have fun.
    
    Doh, I hadn't thought of that one ;)
    
    later,
    .mike
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:29:13 PDT