The Underpinnings

1. The answer to the question need to be something you'll remember or could easily find out.
   
2. The answer can't be something anyone else would know or could easily find out.

I recently found some SCADA boxes and got my adventuring companion to take a few pictures of them with her iphone. (Didn't have a camera on me.) I thought a few of you might be interested in the security you might find at these outlying sites.

The particular site we ended up seeing was the Black Mountain site which mostly contains cell antennas. It's easily accessible—you just climb the mountain—but it's remote enough where it's not closely monitored. Certainly if you snuck up there at night you could probably do anything you wanted. I didn't see any cameras either. The site looks like this:


The SCADA systems are nicely labeled:



And are protected with only the finest and most cutting edge security solutions available for under $20 at your local home depot:

(For those of you who don't like picking locks, a pair of metal cutters would do the trick equally well.)

The SCADA boxes aren't even located within any of the locked cages, but to get inside those isn't hard either. This was the typical lock configuration. Talk about the weakest link:


I was perplexed for some time on why they set things up this way and finally realized that they've got a bunch of different organizations using these sites and no common key distribution, so each organization just puts their own lock on the chain and that way each org's field maintenance people can get in without having to coordinate with the others.

I found it slightly amusing that I could throw a lock on there between the two links before their sets of locks and mess up their entire system. One wonders how long it would take before each organization to have their access restored to the site as they'd have to cut the chain and then redeploy each org's locks on there. It doesn't seem like they talk to each other all that well. Of course they could try cutting the lock, but I'm sure you could put a lock on there that would make them opt to cut the chain instead.

You'd think there'd be enough crazy "oh no cell phone towers are killing our children and making my back ache" people out there that you'd get a few who'd want to lock repair people out of these facilities, but I guess this type of attack just isn't that common...

Anyway. I didn't try hooking into any of the SCADA systems. (I didn't have a laptop with me either, this was a spur of the moment hey what's that on that mountain there, let's go climb it and see type of thing. Usually I'd have a small amount of equipment hanging around in my car, but she drove so I didn't have access to that.) So, I can't say for sure how easy it would be to enter their network here, but if you were looking for a place, this is one of many.

We probably have a few on campus too in the facilities complex if anyone wants to take a look.

$ wget http://websvn.kde.org/*checkout*/trunk/KDE/kdesdk/cmake/scripts/gencmake
$ chmod +x gencmake
$ mv gencmake ~/bin
$ cd ~/projects/projectname
$ gencmake

[  118.830022] ------------[ cut here ]------------
[  118.830026] WARNING: at drivers/gpu/drm/i915/i915_gem.c:2470 i915_gem_idle+0x179/0x341()
[  118.830028] Modules linked in:
[  118.830032] Pid: 5377, comm: X Not tainted 2.6.28.2-DJC-AES #5
[  118.830034] Call Trace:
[  118.830041]  [] warn_on_slowpath+0x51/0x6d
[  118.830046]  [] lapic_resume+0x171/0x1fc
[  118.830051]  [] _spin_lock_irqsave+0x23/0x2a
[  118.830056]  [] lock_timer_base+0x26/0x4b
[  118.830060]  [] try_to_del_timer_sync+0x46/0x4f
[  118.830064]  [] i915_gem_retire_requests+0xf2/0x114
[  118.830068]  [] i915_gem_idle+0x179/0x341
[  118.830071]  [] i915_gem_leavevt_ioctl+0x0/0x35
[  118.830075]  [] i915_gem_leavevt_ioctl+0x14/0x35
[  118.830079]  [] i915_gem_leavevt_ioctl+0x0/0x35
[  118.830083]  [] drm_ioctl+0x1d2/0x260
[  118.830087]  [] vfs_ioctl+0x55/0x6b
[  118.830090]  [] do_vfs_ioctl+0x373/0x3ae
[  118.830095]  [] vfs_write+0xcd/0x102
[  118.830098]  [] sys_ioctl+0x51/0x70
[  118.830102]  [] system_call_fastpath+0x16/0x1b
[  118.830105] ---[ end trace 3a06ac7332c964b0 ]---
[  118.873541] mtrr: no MTRR for 80000000,10000000 found

aes ~ # gunzip -c /proc/config.gz | grep -i drm
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set

aes ~ # gunzip -c /proc/config.gz | grep -i mtrr
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

aes ~ # xrandr -q
Screen 0: minimum 320 x 200, current 2624 x 900, maximum 2624 x 900
VGA connected 1024x768+1600+132 (normal left inverted right x axis y axis) 304mm x 228mm
   1024x768       60.0*+   75.1     75.0     70.1     60.0*
   832x624        74.6
   800x600        72.2     75.0     75.0     60.3     56.2
   640x480        75.0     72.8     72.8     75.0     75.0     66.7     60.0     59.9
   720x400        70.1
TMDS-1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 443mm x 249mm
   1600x900       60.0*+   60.0
   1360x765       60.0
   1280x800       60.0
   1152x864       75.0     75.0
   1280x720       60.0
   1024x768       75.1     75.0     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     72.8     75.0     66.7     60.0     59.9
   720x400        70.1

aes ~ # glxinfo | grep -v GL | grep -v extensions
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.4

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x22 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x69 32 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None

These are R&D Expenditures in CS and EE for FY2006 according to the NSF. I combined these because it doesn't actually make sense to do them separately. You just get whacky results if you do that, like lists that don't include Berkeley or U Washington or a list that shows CMU and MIT doing terribly. Now I really don't particularly care if someone gets a bunch of data for materials synthesis for nanoelectronic fabrication techniques, there's a lot of other things within CS that I also don't particularly care about. It would be nice if I were to pull more specific funding numbers for say, specific NSF programs like Cybertrust ranked by institution, but I haven't gotten around to it.

What I did here is I grabbed everything that was over 10 million/yr in expenditures on each of the CS and EE lists and then combined them to create a composite index of combined EECS spending. (Which is why none of the programs below $20 million have a combined rank, because I didn't combine the full sets.) I also included a few different institutions I found interesting just for kicks including most of the UC system and a few ivies along with some more random ones. A few of them have comments about their YOY trends (which are present on the CS numbers only for this analysis) including departments that look like their funding generally is unstable and problematic or departments that are on upward or downward trends or appear to have just landed or lost one large grant.

Dollars in thousands:

University of Hawaii, Manoa seems to have come out of nowhere... I'm really surprised they're raking in as much money as they are. It would be interesting to see what grants are currently outstanding with them...

For those wondering why U Washington is so low... I would guess that it might have to do with proximity to a certain alternative computer science funding source around the Redmond area. Why bother with federal funds when you can just walk across town and ask for a check?

The fundamental principles of ISA design have remained the same for decades. The gigahertz wars of the 1990s adversely impacted ISA design. During this time, ISA design has been stagnant. Yet with the rise of multicore platforms, this is starting to change. We are seeing active research on dataflow architectures and ISAs which have been forgotten for years, if not decades. This makes today an exciting time to be an ISA designer. This project tried to re-capture some of the spirit of the original ISAs and create something rather different, whacky and perhaps a little fun.

• It's truly atrocious to try and program with
  
• Portions of it are completely unwise and infeasible to implement in hardware
  
• Some of it is just not well thought out

• Treat data like code and code like data. (Arguably I didn't go far enough with this and should have looked at making the data implicit and not via registers... not sure how this would have ended up working though...)
  
• MIMD on the instruction set level
  
• Bring loops into hardware
  
• Loops sometimes easily transparently decomposed onto multiple cores
  
• Modular instruction set designed to support heterogeneous manycore architectures
  
• Automatic core migration based on available capabilities and functional units
  
• Native and "fast" hardware synchronization primitives via wait/kill (which is arguably just a weird implementation of free/busy bits)
  
• Extremely small set of core instructions

ACS/Software Distribution started in large part about 20 years ago to support
the Sun Software consortium. Today I got word that Sun is no longer offering the
sunsolve software support contracts such as we have had. So 1/31/09 when our
current contract ends, will mark the end of an era.

The large movement to the free distributions of Solaris and tools such as MySQL,
and xVM Virtual box (http://www.sun.com/software/) seems to have marked the end to
the need for paid OS updates and such as we have historically provided.

The UC system agreement that currently ends 04/25/2009 (with probability of
renewal), is a baseline price schedule agreement for all Sun Hardware, Software,
and Data Storage from Sun and what was StorageTek (The separate StorageTek
agreement was merged with the sun Agreement). This does not include any specific
software or support activities, just the discount structure from their list
prices. But we do plan on keeping our discount agreement going system wide.

What replaced the sunsolve OS support? Sun now sells OS support priced by the
"Socket", (not the cpu core). The details on Solaris Subscriptions (pricing per
socket) are detailed at:

http://www.sun.com/service/subscriptions/prices.html

This support can be acquired for either purchased Solaris, or OpenSolaris, to get
access to non-public patches and such for Solaris 7 and later as I read it.

Other software service plans are detailed at:

http://www.sun.com/service/serviceplanssoftware/index.jsp

And software support information specifically specifically starts at:

http://www.sun.com/software/index.jsp