[Arm-netbook] Good netbook based on Cortex-A9

[Gordan Bobic]

On 07/30/2012 03:58 PM, freebirds at fastmail.fm wrote:
> On Mon, Jul 30, 2012, at 07:11 AM, Gordan Bobic wrote:
>>>> Raspberry pis are preinstalled with Fedora.
>>
>> I thought they come bare without even the SD card.
>
> RS sells Raspberry Pi model B board: "Boots from SD card, running the
> Fedora version of Linux."
> http://uk.rs-online.com/web/generalDisplay.html?id=raspberrypi
>
> RS is also selling the Debian "squeeze" release on their website. The
> ordering number number is 763-1030.
>
>> But images of most Linux distros are available for download, including Fedora, RedSleeve, Debian, Ubuntu, etc.
>
> The tutorials I have read on installing Linux on many ARM and MIPS
> devices is much more complicated that simply dd image to SD card.

It depends on the device. On some devices you have to fiddle with the 
uboot variables. On others, they use a sufficiently advanced version of 
uboot that it looks for boot.scr on the boot device.

On some they don't use uboot at all and you have to use more obscure 
tools (e.g. nvflash to burn an aboot kernel image to the device on Tegra 
based machines, e.g. AC100).

I'm sure there are some that use even stranger and more exotic things.

But in general, it SHOULD be reasonably straightforward. The only real 
problem is coming up with kernels for various devices, especially ones 
that haven't been mainlined. And there are a LOT of such devices. The 
only practical way to do this is via the community effort. For example, 
for RedSleeve, all the wiki entries for how to get it running on various 
device have been contributed by the users.

>> I've yet to see any actual evidence that this is exploitable by 3rd
>> parties. I am reasonably sure that only the AP locations are being fed
>> back to the base by devices. But if all MAC addresses were being fed
>> back and used for location, then I guess you could (though not anywhere
>> nearly in realtime) query the _rough_ location of a device with known
>> MAC address by reporting back that you are near it, and see what the
>> database says your location is. I would be interested in seeing any
>> evidence that such a hack is actually exploitable. I rather doubt it.
>
> The three articles I cited yesterday clearly discuss that it is the MAC
> addresses of nearby wifi devices that are being transmitted. Not just
> the AP locations. The articles mention people being able to geolocation
> their own router by simply entering the MAC address of their router.
> Because of the publicity, Google ceased making this available to the
> public. Google, Microsoft, Apple and Skyhook have not ceased doing this
> nor ceased making geolocation tracking of MAC addresses available to the
> government and information brokers.

Most interesting. I would have expected that some kind of a mitigation 
would have been applied to this approach (e.g. having to transmit more 
than one MAC address or locator ID, but I can certainly see how this 
could be exploited.

Access to the said service from Google also isn't going to be blockable 
- with a bit of effort and a rooted device, you could easily reverse 
engineer the API details even if it is only accessed over SSL (create 
your own CA, upload it to the device, set up a transparent proxy on the 
AP, and effectively perform a man-in-the-middle attack on the SSL 
connection, and dump the contents. Pretty basic stuff as far as such 
attacks go. Ironically, having every Android device have to have a SSL 
certificate unique to it (like iPhones do) - something you could 
implement using one of the secure extensions you so hate - would make 
such an attack much harder. But the chances of having all Android 
devices have such a thing and having Google enforce device 
authentication via the said certificate are so close to 0 (at least any 
time soon).

Having said that, there is no way the device should be transmitting it's 
MAC address if it is disabled (in software, see rfkill command), or if 
your laptop has a hardware switch, with it flipped to the off position. 
If it does, that's really poor.

>> Also remember that with most wireless (and wired) device you can spoof
>> your MAC address (just pick one out of the air and use it for that
>> session, then generate a different one for the next session).
>
> MAC Changer requires a script to start up before wifi starts up. The
> question I asked yesterday was whether booting up and shutting down the
> computer enables wifi before the OS starts up and reenables wifi and
> bluetooth after OS shuts down. Meaning, after disabling wifi and
> bluetooth in Fedora's network manager, will the processor enable them
> when the computer is starting up before the OS starts and disables them?
> Will the processor reenable them after the OS shuts off but they
> processor hasn't shut down yet? This happened with my i86 MSI and Asus
> netbooks. The VIA 8650 netbook does not have a wifi/bluetooth light
> indicator on the netbook, so I cannot tell.

The nice thing about ARM and other embedded SoCs is that there is no 
BIOS. If you are lucky, you get uboot, and there is no way that will 
come with anything WiFi related built in.

Having said that, it is still plausible, especially on devices that 
don't come with a firmware blob, that the device might come up all on 
it's own, as soon as it powers up. This is something that can only 
really be established experimentally. So in a way, the "free software" 
view that binary firmware blobs are bad actually works against you in 
this case, because that firmware blob is in the hardware and potentially 
enabled the hardware to power up on it's own and be functional 
regardless of what the driver does. If the device requires a firmware 
blob to be loaded by the driver before it can even activate, then this 
is might be less likely to cause the sort of problem you are talking about.

So the only real way to establish this is to experiment. Whether the 
WiFi device is free software friendly or not doesn't really make much 
difference either way.

>> We discussed earlier this month how far bluetooth can be detected. Bluetooth can be detected much further.
>
>> But it doesn't matter considering you can generate yourself a new random MAC address every time you go to establish a connection.
>
> MAC Changer spoofs wifi, not bluetooth. I am not aware of a Linux
> package that can spoof bluetooth MAC.

I don't know enough about BT (I don't use it, and it's disabled on all 
of my devices) to comment on that, but to the best of my knowledge 
geolocation services like Google Maps and Skyhook only use WiFi, not 
bluetooth. I could be wrong, of course.

Gordan