lgeek

I guess my definition of going nuts was a bit more conservative. Both x86-64 and ARM's AArch64 currently only use 48 bits for virtual addressing.

Still, even if you design for computers with 256GB (2^38) physical memory, you still have a virtual address space that's 2^9 times larger (assuming addresses with the MSB bit set are reserved for the kernel's memory space). This is opposed to 32 bit systems where the physical memory space is close to or larger than the virtual address space. E.g. high end smartphones sold in the last few years have 2GB RAM and only 3GB of virtual address space.

I don't know about this particular project, but the standard approach is to use a PID controller, which uses the derivative term to control overshooting and oscilations.

Yep, I think this is the correct answer for the general case. With structures close to or larger than a page and on 64 bit systems you can go nuts with overallocation because the virtual address space is much larger than the amount of physical memory.

Maybe it is more complicated as a concept, but the implementation is much more simple. They're using a MCU with integrated radio, it's almost free to add the RF source to the base system only using the avalanche diode.

A HV geiger tube and embedding a radiation source would be much more complicated / expensive to build, especially on small scale.

> ldd actually executes the program being probed;

It's insecure, but it's actually a bit more nuanced. What I'm describing applies to up-to-date glibc, it might have been even more insecure in the past.

ldd first calls the dynamic linker with --verify, i.e.:

    /lib/ld-linux.so.2 --verify $file

This is the system's dynamic linker, which should be considered safe. The --verify parameter tells the dynamic linker to check if the file is a valid dynamically linked file. Assuming that the file exists and it is an ELF file, the dynamic linker exits with status 1 if the file doesn't have a DYNAMIC segment, with 2 if the file doesn't have a INTERP segment or with 0 if it has both (the typical case). Execution is never passed to the file with this flag.

Depending on the exit status of the loader, ldd does different things:

* If it was 0, it calls try_trace "$file", meaning that the file is invoked directly. However, remember that for the status to be 0, the file must have an INTERP segment, meaning that the kernel will call the interpreter, typically the dynamic linker, i.e. /lib/ld-linux.so.2. A well behaved linker doesn't pass control to the file if LD_TRACE_LOADED_OBJECTS is set.

This is the insecure case. The interpreter can be set to any other application (it must be statically linked or it must dynamically link itself). However, if the attacker doesn't control the file system, there typically aren't any files which match this condition and either pass control to the application or do anything harmful when invoked with no arguments. The alternative is to set the interpreter field to be the file itself. The problem with that is the full path to the ELF file must be known by the attacker (or it must be known that the victim will call ldd from the directory in which the file resides). /proc/self/exe will not work because at the time the kernel reads the entry, it will still point to the executable of the calling process, usually bash in this case.

* If the exit status was 1, ldd quits (because it's an invalid file).

* If the exit status was 2 (no INTERP segment), the dynamic loader is invoked directly, i.e.

    try_trace "$RTLD" "$file"

These two latter cases are safe.

A bug which can significantly simplify the attack would be a mismatch between the dynamic loader and the kernel, where the dynamic linker thinks that the ELF file has an INTERP filed and returns 0 for --verify and then the kernel doesn't find the INTERP field and passes control directly to the application. I've poked a bit around and as far as I can tell, there's no such bug in the latest kernel and glibc releases. In addition, the kernel aborts the loading process for any errors related to loading the interpreter.

This 30C3 talk[0] discusses potential security issues arising because of mismatches between the various ELF parsers.

[0] http://www.youtube.com/watch?v=1-tUo6RUzBU

The diagram showing the stack on program entry misses the auxiliary vector[0].

As a sidenote, I find stack diagrams more intuitive (for typical descending stacks) when the low address is drawn at the top. This way it looks like a real-world stack and if you need to represent some data or executable code in the same address space it will appear in natural order, from top to bottom.

[0] http://articles.manugarg.com/aboutelfauxiliaryvectors.html

What superscalar and out-of-order processors are exploiting is instruction level parallelism, while their technology seems to use thread level speculation.

> Without knowing the details on how they compiled the SPEC benchmark it's really hard to say. Who knows, maybe they cheated and ran parts of the benchmark parallel on their cpu and not on others

That's most likely the case, but I wouldn't consider it cheating. As long as from the software perspective only a single thread is running (and SPEC CPU 2000 and 2006 are single threaded), I think it's fair game. The whole point of their project is to expose parallelism without requiring the programmer / execution environment to explicitly support it.

I'm going to remain skeptical until they publish more details. The report[0] linked from their homepage seems to contain more/better information, but it's not much.

What seems pretty clear is that they use a proprietary ISA and have developed dynamic binary translators for ARM and x86 code. It's not clear if it's a VLIW architecture or if the ISA has any other properties required by the hardware.

From this report it sounds like they're essentially doing thread-level speculation in hardware.

Based on the linked article I would have been tempted to think they have reconfigurable pipelines, but based on the report I'm somewhat sure it was just a misunderstanding.

I generally think it's a bad sign when a company implements relatively well known concepts from research and then doesn't use the standard terminology and tries to pitch their creation as something 100% new and original. In any case, there's no need to rush a judgment, I guess they'll publish better technical information in time.

[0] http://www.softmachines.com/wp-content/uploads/2014/10/MPR-1...

Leaded solder has better wetting properties, it can be soldered at lower temperature and it's more reliable for joints exposed to any mechanical stress, including from vibrations and thermal stress. Any way you put it, it's superior to lead free solder and it's still widely available everywhere, including in the EU. No reason not to use it for stuff that isn't going to be sold.

No, I did not use libhybris. It boots the kernel I've patched and it uses a full Linaro filesystem on a micro SD. The Android FS is not even mounted when running GNU/Linux.

The SoC is RK3188 and it uses a proprietary bootloader to do some hardware initialization IIRC.

The device does have an UART port, which I've used.

Sorry, but that looks more like an artist's vision of a die shot than an actual die shot. The TRM is pretty clear that it's an A15: http://i.imgur.com/Fvh2KVT.png

I did a long weekend project a few months ago bringing up GNU/Linux on a low cost tablet. Here's a picture of it running XFCE: http://i.imgur.com/jmh8N0W.jpeg

If you at least have a kernel source for the SoC, it's doable. However, especially if you don't have the source for your specific device (because manufacturers play fast and loose with the GPL), you'll probably spend the first few days getting it working and then many, many weekends getting it to be usable. I did stop before I got to that point.

Here's some of the issues I ran into:

* The parallel RGB to MIPI bridge doesn't have complete publicly available documentation and it requires LCD-specific configuration. I've sniffed it from the Android kernel with a logic analyzer.

* The touchscreen controller doesn't have complete publicly available documentation and it requires device-specific configuration.

* The BMS doesn't have complete publicly available documentation and it requires device-specific configuration

I guess you can see a trend. :) If you have the time, you can RE this stuff with some basic soldering skills and a logic analyzer or scope.

But actually the issues which made me lose enthusiasm were the following:

* Rotating the framebuffer to landscape orientation in software is freaking slow. Android seems to be doing it using OpenGL ES, but I'm not aware of any GNU/Linux window manager capable of this. The display controller didn't support rotation and the only remaining alternative would have been too hacky for my taste, to use the image processing engine to maintain a rotated shadow copy.

* Limited capabilities: processing speed is mostly OK, but only 2 GB of RAM and the slow framebuffer are not great. There's almost no I/O, essentially you only have a USB OTG port. Tablets are not thermally designed to sustain high loads. Battery life will probably not be that great and it seems difficult to upgrade the battery.

Now, some of this stuff doesn't fully apply to Nexus 9. I expect Google to be better at providing a kernel source closer to that's running on the device and the hardware itself it much more capable, it even has OpenGL (non-ES) support. This still leaves quite a few issues. Chromebooks (used for running GNU/Linux, of course) might be worth looking into.

The companion core of the ARMv7 TK1 is a low power Cortex-A15, like the grandparent comment says. This is different from ARM's big.LITTLE which uses different microarchitectures for the two clusters, i.e. Cortex-A15 + Cortex-A7 or Cortex-A53 + Cortex-A57.

> If your device has full disk encryption using a strong password, physical access doesn't get you much in the way of accessing the data.

Well, even if assuming that all your software is bug free, someone with physical access can either replace the unencrypted boot image with a compromised one which gives him remote access or install a hardware keylogger and come back later for the disk and password.

In the hypothetical situation of a targeted attack and attacker with physical access, FDE only protects you if you never turn on your computer.

> why bother

I'm mostly working on software for ARM and since all the tools I need for work run well enough, why not? I still use x86 at home.

> which ARM machines have you been using as desktop replacements?

The ones I've used most were IMX53QSB, then ODROID-X2, ODROID-XU and I'm now switching to ODROID-XU3.

> What advantages do they have over x86 machines?

I was able to get rid of the x86 desktop while only using ARM hardware I would have used anyway. Also, the boards have a tiny footprint (you can tape several to the back of a monitor for example), they're very low power and can be passively cooled. They're very cheap too.

I've also used some RK3188-based mini PCs dongles for their portability. You can carry a reasonably fast GNU/Linux machine in your pocket and don't cost much more than Raspberry Pi, which I find way too slow.

I've been using ARM machines as a desktop replacement for a few years now. Native applications run just fine on fairly modest hardware. However, for web browsing, a quad core Cortex-A9 around that frequency and with a 32 bit DRAM interface just crosses in the usable (but somewhat laggy) category. Cortex-A15 with a 64 bit memory interface feels much closer to modern x86 machines.

Novena's 64 bit memory interface might actually make a big difference. From my tests, a 1080p 32 bit framebuffer uses up around 1/4 of the system memory bandwidth with a 32 bit DDR3 interface.

I also get the feeling that desktop browsers (chromium, firefox) aren't very well optimised for ARM.

I don't see FPGA acceleration being useful in mainstream computers soon. By the way, AFAIK the one in Novena is primarily intended for data acquisition, not acceleration.

FPGAs are generally good for accelerating data-parallel applications, but we already have had SIMD and GPGPU for a while. Both these technologies are only used by a small subset of the applications which could benefit from employing them. Why? I would say poor tools and abysmal programmer literacy. Automatic vectorization for SIMD sort of works, but it tends to miss lots of opportunities. Automatic acceleration with GPGPU is pretty much in the research phase. Manual development for SIMD and GPGPU takes skills that most developers don't seem to have at the moment and the trend towards high level, highly abstracted imperative languages isn't helping.

I guess at this point it might seem like I'm contradicting myself. The software side of things is lagging behind for GPGPU and SIMD, but these technologies are still mainstream. Why wouldn't the same happen for FPGA accelerators? My answer is cost. SIMD requires just a few small functional units and registers, a fairly small chip area in the processor compared to caches; the general purpose processor is itself a fairly small part of a SoC. GPGPU didn't require significant architectural changes from the shader model. FPGAs large enough to be useful, on the other hand, are expensive. Maybe economies of scale might make a smaller FPGA cheap enough to be included as an accelerator, but as far as I understand high transistor count / large area / low yield is unavoidable.

Plenty of exciting stuff going in research, but automatic use of accelerators would work much better by moving to a dataflow model of programming.

Personal prediction: non-monotonic same-ISA heterogeneous computing is going to be the next big thing, maybe in the form of reconfigurable pipelines. A bit more far fetched: phase-change materials for very aggressive short-term DVFS to lower latency on mobile.

> Some people tested the claims (using a DSLR with the infrared filter removed

I don't know if the video is faked, but that is a horrible way to test the claims. Regular image sensors only detect near-IR and not the mid to far IR radiated by hot objects.

> I like that all processes run in CPU ring 0 and safety is ensured by the VM. It seems like this is more flexible

This approach has a few issues which make it impractical for use by a real general purpose OS:

* it moves all work related to safety either to the dynamic compiler (not so bad), when it can statically prove that the code is safe or onto the critical path if it cannot statically prove it safe (which generally causes significant slow-downs). For example a traditional OS will use VM to isolate application memory (where the performance impact comes from the occasional TLB miss), while this sort of approach might require boundary checks to be compiled before many memory instructions

* the problems mentioned above could be mostly avoided by requiring use of a language or bytecode format designed to allow the compiler to use static checks, but then all your applications have to use it (which is what Runtime.JS does)

* it potentially allows more complex interactions between the OS/VM and the application compared to traditional system calls, which is the sort of things that often enough creates hard-to-predict side effects

> allows for more easily provable safety guarantees.

I don't know about that, hardware is normally formally verified, while software normally isn't. While hardware bugs still exist, there are far fewer than in software.

Narishma's sibling comment is spot on: the microcontroller profile cores have a subset of the instructions available on application profile cores. Cortex-M0(+) and Cortex-M1 have a base set of instructions, while M3, M4 and M4F each add a new subset to that of the immediately inferior model. This is done to change the trade-off between speed, energy and cost.

If you keep switching between different Cortex-M cores and have difficulty keeping track of the available instructions, this wikipedia page[0] summarizes things in a nice short table.

[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Instruction_sets

What do you mean by 'versions of ARM assembler'?

Yes, it's pretty outdated. It looks like it was written for ARM7TDMI which is ARMv4T. It seems like a decent introduction to RISC assembly programming though. This sort of stuff can get you started, after which you can get up to speed by reading compiler output and the ARMv7 architecture reference manual.

Is there a good and more up-to-date introductive text?

Yes, and as jmpe said they have quite a few SoCs without NEON (I think basically everything apart from ARMADA 1500 plus). They seem to be targeting devices like smart TVs and STBs nowadays, so I guess it's not a big deal.

> architectures that don't support NEON (they often lack them in Marvell and Allwinner).

I'm probably nitpicking here, but:

* All Allwinner SoCs have NEON[0]

* Most current ARMv7 processors have NEON. Of the current ARM cores, only Cortex-A5 and Cortex-A9 don't have mandatory NEON support (it's optional). Cortex-A5 is intended for embedded applications. Of the existing Cortex-A9 processors, AFAIK the only somewhat popular one without NEON support is NVIDIA Tegra 2, which is retired. Out of the third party cores, all Qualcomm and Apple ones have NEON support.

[0] http://linux-sunxi.org/Allwinner_SoC_Family

I generally want an almost complete TRM too. In my experience there are many more SoCs with an available TRM than with complete support in the mainline kernel. By the way, there some WIP work for getting RK3188 support in mainline. It can boot but only a small part of the peripherals are supported.

You can never get a complete TRM for high performance ARM SoCs because they all license some IP for which they can't publish the documentation, usually for 3D accelerators and video decoders. You can find leaked Allwinner and Rockchip TRMs, at least for Allwinner A20 (the one used by Cubieboard for example) and RK3066 (which is quite similar to RK3188), so it's a compromise I've accepted in a few cases.

> Just ask the hard kernel / odroid guys - they have eight cores

Of which you can only use 4 at a time because Exynos 5410 is broken.

> at about the same price point.

69% more expensive.

On ARM SoCs you generally can't really talk about 'the GPU'. There are separate:

* 3D accelerator, which is what some people call the GPU, but it only does 3D acceleration (OpenGL ES in most cases) and on newer models it can also run OpenCL - not the case on this SoC which has a Mali-400. This is working with closed source drivers on GNU/Linux.

* a video decoder and sometimes a video encoder, Hantro G1[0] and Hantro H1[1] on this hardware. These are unsupported on GNU/Linux, possibly because Android uses its libstagefright[2] infrastructure and there's limited demand for GNU/Linux support.

* sometimes a 2D accelerator, which would mostly be used for blits, resizing and rotation nowadays. RK3188 actually has two different units with overlapping functionality and which work on GNU/Linux with open source drivers.

Even though the video decoder is unsupported on GNU/Linux, the ARM cores are fast enough to decode 720p and (with some frame loss) 1080p h264 video. I wrote an XV driver[3] for RK3188 which uses hardware support for colorspace conversion and video resizing together with a few other tricks.

[0] http://www.verisilicon.com/IPPortfolio_14_58_2_HantroG1.html

[1] http://www.verisilicon.com/IPPortfolio_14_82_2_HantroH1.html

[2] https://source.android.com/devices/media.html

[3] https://github.com/lgeek/xf86-video-fbturbo

I've been hacking Rockchip RK3188-based devices for a few months now. What caught my attention are the low cost Android PC-on-a-stick and tablets using this SoC. We're talking about $50-ish delivered for a PC-on-a-stick with 2GB of RAM, HDMI output and a WiFi+Bluetooth adapter and $150-$200 for a decently built tablet with similar specs, some even having high-DPI screens.

Radxa Rock (the article keeps talking about 'the Radxa' when that's the name of the company selling Radxa Rock, by the way) is similar to the various PC-on-a-stick, but in a development board form factor and with more I/Os and GPIO exposed.

Rockchip only provides support for Android and more recently Chrome OS, with GNU/Linux support being mostly community developed. The good news is that most hardware is working on GNU/Linux, with the exception of the video decoder and encoder (which is typical for most SoCs)and the NAND driver is closed source because it includes the flash translation layer which is treated as a trade secret by flash vendors. The bad news is that the kernel code developed by Rockchip is a bit crap and the community forks are quite fragmented because there's no central place to centralize various patches. Even so, it's generally straightforward to add support for a new board. We have a wiki[0] and an IRC channel - #linux-rockchip on Freenode if you're interested. The Radxa guys maintain their own fork so at least for their platform it's clear what to use.

I'd say it's a good choice for running Android or for hacking or for doing processing tasks (things like a building packages, running a low power webserver, continuous integration, etc) on GNU/Linux.

Some people in this thread ask/complain about platform-specific GNU/Linux distributions. There's Picuntu[1], but my view is that platform-specific distros are completely unnecessary and even a bit silly. On x86 you don't run Thinkpad-Ubuntu, you just run the generic Ubuntu. This is no different for ARM computers, you can use any generic distribution with a ARM port, with a kernel image compiled for your hardware and maybe one or two other drivers which need to be set up in userspace.

Compared to RPi, RK3188 (and other similar SoC) devices have a massive advantage since it's ARMv7 while RPi is ARMv6 which most distros don't support anymore. The difference in CPU performance compared to Raspberry can't be understated, it has 4 cores which are maybe 2 to 4 times faster for most workloads, about three times the memory bandwidth, four times the RAM, etc.

[0] http://linux-rockchip.info/ [1] http://home.g8.net/

I like Deviation[0]. It runs on commercial transmitters and the developer reverse engineered many communication protocols used by proprietary systems which are now supported (some require adding hardware to your transmitter).

[0] http://www.deviationtx.com/

Most RC transmitters are digital and use the 2.4 GHz spectrum. They do channel hopping, they do integrity checking (CRCs for the most part), have configurable channels and mixing. Some also do telemetry and support multiple profiles for the channel and mixing settings.