Dynaverse.net
Off Topic => Engineering => Topic started by: Nemesis on April 28, 2009, 05:50:34 am
-
Link to full article (http://www.windowsfordevices.com/news/NS7625324099.html)
Developers at Microsoft Research and the University of San Diego say massive power savings can result from embedding an ARM-based CPU into a network interface. The "Somniloquy" can handle file sharing and long downloads on its own, and only wakes a host PC when necessary.
Steve Ballmer must be in a chair throwing mood over the next part. ;)
According to the researchers, the Gumstix-based Somniloquy prototype runs an embedded Linux distribution, including a full TCP/IP stack, DHCP, configurable routing tables, a configurable firewall, SSH and serial port communication.
They note it could be made to use WinCE. Which makes me wonder why being Microsoft funded they didn't? Why not use embedded XP?
-
Link to full article ([url]http://www.windowsfordevices.com/news/NS7625324099.html[/url])
Developers at Microsoft Research and the University of San Diego say massive power savings can result from embedding an ARM-based CPU into a network interface. The "Somniloquy" can handle file sharing and long downloads on its own, and only wakes a host PC when necessary.
Steve Ballmer must be in a chair throwing mood over the next part. ;)
According to the researchers, the Gumstix-based Somniloquy prototype runs an embedded Linux distribution, including a full TCP/IP stack, DHCP, configurable routing tables, a configurable firewall, SSH and serial port communication.
They note it could be made to use WinCE. Which makes me wonder why being Microsoft funded they didn't? Why not use embedded XP?
I'd say because they couldn't cut a windows version down small anough to be embeded. WinCE is (IIRC) one of the smallest versions of windows out there. The others are to bloated.
-
I'd say because they couldn't cut a windows version down small anough to be embeded. WinCE is (IIRC) one of the smallest versions of windows out there. The others are to bloated.
Actually Microsoft does sell XP Embedded.
I didn't think of the processor when I originally posted, it isn't an x86 chip so XP embedded wouldn't have worked. The question of why they didn't use something from Microsoft is still up in the air. Microsoft workers get free Microsoft software so it shouldn't have been software costs.
It could have been time constraints, GPL'd components might have allowed them to prototype faster. Obviously I'm just guessing.
-
I'd say because they couldn't cut a windows version down small anough to be embeded. WinCE is (IIRC) one of the smallest versions of windows out there. The others are to bloated.
Actually Microsoft does sell XP Embedded.
I didn't think of the processor when I originally posted, it isn't an x86 chip so XP embedded wouldn't have worked. The question of why they didn't use something from Microsoft is still up in the air. Microsoft workers get free Microsoft software so it shouldn't have been software costs.
It could have been time constraints, GPL'd components might have allowed them to prototype faster. Obviously I'm just guessing.
That is a possiblity, they could cross compile it later after the demo program is out and running.
-
The security piece of this does not amuse me. You'll have to yank the freakin' plug out of the wall to get a hacked one of these offline.
-
The security piece of this does not amuse me. You'll have to yank the freakin' plug out of the wall to get a hacked one of these offline.
OH COME ON!! It's from MS do you think they would leave security holes in a project that could get hacked. .. .
:laugh: :laugh:
-
The security piece of this does not amuse me. You'll have to yank the freakin' plug out of the wall to get a hacked one of these offline.
From what I see it is powered from the USB port it is plugged into.
I would hope that it is treated more like a router which can be rebooted remotely. Even possibly reload the firmware like a router.
Ideally with less software (no Desktop Environment for example) it could be made to be more secure. One program only allowed to access the internet everything else blocked. Keep that one program on a very locked down account and the vulnerable surface should be very limited.
The SheevaPlug (link to prior topic (http://www.dynaverse.net/forum/index.php/topic,163385508.0.html)) would probably be better at the job and capable of more than this unit in any case. Much more general purpose.
-
The security piece of this does not amuse me. You'll have to yank the freakin' plug out of the wall to get a hacked one of these offline.
I was wondering the same thing: what does this pose as far as security goes?
-
The security piece of this does not amuse me. You'll have to yank the freakin' plug out of the wall to get a hacked one of these offline.
I was wondering the same thing: what does this pose as far as security goes?
Lets assume that what they say about a "production model" is accurate.
# When a host PC is powered up, the Somniloquy does nothing and is transparent to the host OS. In a production version, the Somniloquy's processor would be powered down in this mode, though the researchers say they were unable to implement power-down on the prototypes.
# When the host PC initiates sleep, the Somniloquy detects this and transfers network state to the secondary processor, including ARP table entries, IP address, DHCP lease details, and wireless SSID, thereafter becoming capable of "impersonating" the host.
Note how the on board OS and CPU are powered down when the Host computer is powered up. You would need to first violate its own security and upload a ARM compatible piece of malware to take control and download a x86 piece of malware. The x86 malware would then need to be accessed by the host system while the Somniloquy OS and network connection are inert (or change the firmware to make it stay active) and be capable of taking over that host system.
It seems to me that there would be too many stages to go through and most malware authors would take the simpler step of attacking the x86 machine directly not through a proxy.
Put the minimum amount of software on the system and lock each piece down to the lowest level of access it can have to still do its job. Build it into a router and have the router treat the SD card as a remote HD - accesible both by the download function and other computers. The router could have two different CPUs each with its own OS and memory, one controlling the router functions and the other the torrent (which could be turned off to conserve power when unused). They would need to control 1st the torrent then the router to finally be able to attack your system which would be using both a different processor architecture and a different OS. You could control the torrent software by reading and writing to a config file on the SD card that the torrent checks on a cycle. The router could even be set to force a restore to default if the torrent software tries to access anything but the torrent allowed resources (killing any torrent in process and ideally any malware).