[OLPC Security] Securing the laptop: DoS

Sat Oct 7 23:17:05 EDT 2006

The wha?  How do you do that?  The system should keep track of a number
of things (I'm assuming neither that this is nor is not how cache works;
I don't really know.  These properties just make sense to me):

 - Individual files.  These are having data changed; data being changed
   in the same spot in the same file should be overwritten in memory
   until written back to disk.  You can even allocate space-- or decide
   where allocations go, but not actually write that to disk.

 - Files being deleted.  If you write to a file 300 times, then delete
   it, don't write those writes to disk.  If you create a file, delete
   it, create it again, delete it... only write the final set of files
   still alive back to disk in the end.

 - Meta-data.  If you update atime, size, etc, keep that information,
   update it each time in memory, sync it back when appropriate.

My thinking is that to beat this, you have to create a very big file or
a large set of files, and write over them in a bunch of different places
a lot, to scatter writes in different sectors so that the NAND has to
erase/program those sectors.  You won't fill the cache with dirty just
by writing to the same place a lot of times.

Essentially, if there's room for 60 megs of cache, you have to write 60
megs of data minus whatever else is legitimately cached and likely to
stay there through the attack.  While the system is writing cache back
to disk, the attacking program is probably going to be blocked by
write(), because the kernel has nowhere to put the extra data.

> Hell, use a PNG so that the system can't tell the difference.

PNG??  Image?  Can't tell the difference between what and what?

> And if you buffer writes to RAM, you lose a lot of reliability. What
> happens if the machine is turned off before the buffers flush?
> 

This is a time shifting issue, not a reliability issue.  Let's follow
the below flow:

  0:00		Cache is written back to flash.

  0:02		3 files are created, they fit in cache.

  0:05		Cache is written back to flash.

 - {A failure between 0:02 and 0:05} is identical to {a failure
   immediately after 0:00}.

 - If the files are written back to disk immediately at 0:02, then {a
   failure immediately before 0:02} will leave the machine in the exact
   same state as {a failure immediately before 0:05 when the files are
   being stored in cache to be flushed at 5 minute intervals} would.

What you trade off is the effective time the system went down; instead
of being a real concept, system failure is a discrete event that only
occurs on 5 minute barriers.

What is important is that the system not go down and leave the disk in
an inconsistent state which is dangerous to use.  The journal in JFFS2
handles this; if the system goes down at any time during any operation,
it will play back the journal so the device is safe to use.

Now, what you CAN do is add an interface to Sugar to force a flush, in
case for example the student saved a file and wanted it to really write.
 The child could click this button and the data would be written back to
flash immediately via calling 'sync'.

This approach has two considerations.  First, it is probably less
effective for a malware to call 'sync' or flush functions after every
write than it is to just blast the disk.  Second, if you want to prevent
the malware from calling sync, you have to use MAC policies (SELinux,
GrSecurity, LIDS, RSBAC...) to restrict access to sync(), file flush
commands, and the 'sync' program.

It comes down to just how paranoid you are, and where your priorities
are.  If a child loses data, well tough, it happens.  If a child has his
NAND destroyed by malware, we have a problem.  The NAND is not on a
reiser that just lets you pop a card out the side and slip a new one in
(technically feasible?), so repairing that kind of damage is a
desoldering job.  (Maybe just move to the SD slot on the side for
booting in such cases)

Even IF you could replace the NAND, what about the malware?  Can't it
just destroy it again?  Sure it won't PERMENANTLY brick the whole
machine, but being trashed every 5 minutes when there's a nasty
high-speed spreading resident malware (think CodeRed, which only existed
in memory, and came back via reinfection) you need a better solution.

Personally my priority lies more in saving the hardware than the data.
The data shouldn't be threatened by buffering unless the system is
actually under attack (power sucking...) or the child gets too tired to
yank that ripcord (come on guys, foot pedal, a plunger with a spring
that resets it just rock your foot on top of it!)

> 
> John Moser wrote:
>> ! The onboard NAND flash has a limited number of writes per sector
>>   before it will start to wear out. JFFS2 tries its best to mitigate
>>   repeated writes to a file by distributing the writes evenly over the
>>   whole flash chip.
>>   * Opening a file and running a {modify, fsync} endless loop on it
>>     should be able to kill the flash chip in minutes
>>
>>
>> ^^^ This is probably the easiest to handle.  Just buffer and delay
>> writes for a good 30-45 seconds, merging the changes in memory and then
>> snapshotting and writing back to disk.  This will take some amount of
>> code to get done, but doesn't such code already exist anyway?
>> (laptop mode...)
>>
>>   
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRShtrws1xW0HCTEFAQIdbw/+PnGUkBKyfEY7wiiOC+emOiGHlZgThsxg
gATNPrV5UD8iGUCzDmFDbaz5wEm5Ozy2HakcWw0BcftyAokXFcH2ZT6IzLcqoGyE
0kuuLZ6RqIA5dHnONb+8OfHEbt8gviVrsMhaNhDaUygN8ygSr35hnBt40YONz9bZ
orr3PGfGiTuMSIcW7/8s2Vo9ASjBCVchiuDEwQKeYnCo5qTg8Ooecp2P+8m0A60h
X6mB2AGqJY9cIs7f/2wNyj8Aghk1V38Loz8nV0+Z7M+7X1UvyrlQpX82EtNoshvN
zlnDBHGa8fkCt80GFAIQ1edGCSHqMKsvcSMPdKEx8PvXxTTZxmrcf61Yr0SWGwJ2
Q5MiGtEH88A319OELI/Hp1gkkjb+FrOIJEMyKCNKrbGNAk3/xeP7es8yoTtaQJql
mhA6SdIcFgxAtS5vNGifH3eZE0NhoavJuqS96E3ueqpMfwjTowMoiN3a/O59rH4v
JAh79a1AXEUufHn6QXe9DXtGzTeOL7O+ZPumDWJm8SGrv2zkXoUKRFU9L4OdhKsy
M/XYUfHlTRi5R2b2EmKfQXUQFJor2IMWGNEEcXjeytZYA5u26ZLjDLx9rqZJUfiA
H5qeErMgQ/ikrDr0hk8ffoqcenzqOLVMRIOzpkOw8tsoFjZUCO21RLn0Oya8NmQy
PCsnEn3g3kY=
=Gulh
-----END PGP SIGNATURE-----