The way Spectre mitigations are shaping up, it's going to require modification
of every program that deals with sensitive data, inserting serialization
instructions in the right places. Or programs can be compiled with
all branch prediction disabled, with more of a speed hit.

Either way, that's going to be piecemeal and error-prone.
We'll be stuck with a new class of vulnerabilities for a long time. Perhaps
good news for the security industry, but it's going to become as tediously
bad as buffer overflows for the rest of us.

Also, so far the mitigations being developed for Spectre only cover branching,
but the Spectre paper also suggests the attack can be used in the absence of
branches to eg determine the contents of registers, as long as the attacker
knows the address of suitable instructions to leverage.

So I wonder if a broader mitigation can be developed, if only to provide
some defense in depth from Spectre.

The algorithm that tracks and matches jump histories appears to use only
the low bits of the virtual address (which are further reduced by simple hash
function). As a result, an adversary does not need to be able to even execute
code at any of the memory addresses containing the victim’s branch instruction.
ASLR can also be compensated, since upper bits are ignored and bits 15..0 do
not appear to be randomized with ASLR in Win32 or Win64.

I think ASLR on Linux also doesn't currently randomize those bits of the address;
cat /proc/self/maps shows the lower 3 bytes always 0.
But, could it be made to randomize more of the address, and so guard
against Spectre?

(Then we'd only have to get all binaries built PIE, which is easily audited for
and distributions are well on their way toward already. Indeed, most
executables on my laptop are already built PIE, with the notable exception
of /bin/bash and all haskell programs.)

I don't have an answer to this question, but am very curious about thoughts
from anyone who knows about ASLR and low level CPU details. I have not been
able to find any discussion of it aside from the above part of the Spectre
paper.

I wanted to use 1-wire temperature sensors (DS18B20) with
my Cubietruck board, running Debian. The
only page I could find documenting this
is for the sunxi kernel, not the mainline kernel Debian uses.
After a couple of hours of research I got it working, so here goes.

wiring

First you need to pick a GPIO pin to use for the 1-wire signal. The
Cubietruck's GPIO pins are
documented here,
and I chose to use pin PG8. Other pins should work as well, although
I originally tried to use PB17 and could not get it to work for an unknown
reason. I also tried to use PB18 but there was a conflict with something
else trying to use that same pin. To find a free pin,
cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins and look for
a line like: "pin 200 (PG8): (MUX UNCLAIMED) (GPIO UNCLAIMED)"

Now wire the DS18B20 sensor up. With its flat side facing you,
the left pin goes to ground,
the center pin to PG8 (or whatever GPIO pin you selected), and the
right pin goes to 3.3V. Don't forget to connect the necessary
4.7K ohm resistor between the center and right pins.

You can find plenty of videos showing how to wire up the DS18B20 on
youtube, which typically also involve a quick config change to a Raspberry
Pi running Raspbian to get it to see the sensor. With Debian it's
unfortunately quite a lot more complicated, and so this blog post got kind
of long.

configuration

We need to get the kernel to enable the GPIO pin. This seems like a really
easy thing, but this is where it gets really annoying and painful.

You have to edit the Cubietruck's device tree. So apt-get source linux
and in there edit arch/arm/boot/dts/sun7i-a20-cubietruck.dts

Note that if you used a different pin than PG8 you'll need to change
that. The "pio 6 8" means letter G, pin 8. The 6 is because G is the 7th
letter of the alphabet. I don't know where this is documented; I reverse
engineered it from another example. Why this can't be hex, or octal, or
symbolic names or anything sane, I don't know.

Now you'll need to compile the dts file into a dtb file. One way is to
configure the kernel and use its Makefile; I avoided that by
first sudo apt-get install device-tree-compiler and then running,
in the top of the linux source tree:

And if you picked a GPIO pin that works and got the sensor wired up
correctly, in /sys/bus/w1/devices/ there should be a subdirectory for the
sensor, using its unique ID. Here I have two sensors connected, which
1-wire makes easy to do, just hang them all off the same wire.. er wires.

So, it's 15.37 Celsius in my house.
I need to go feed the fire, this took too long to get set up.

future work

Are you done at this point? I fear not entirely, because what
happens when there's a kernel upgrade? If the device tree has changed
in some way in the new kernel, you might need to update the modified device
tree file. Or it might not boot properly or not work in some way.

With Raspbian, you don't need to modify the device tree. Instead it has
support for device tree overlay files, which add some entries to the
main device tree. The distribution includes a bunch of useful overlays,
including one that enables GPIO pins. The Raspberry Pi's
bootloader takes care of merging the main device tree and the selected
overlays.

There are u-boot patches to do such merging, or the merging could be done
before reboot (by flash-kernel perhaps), but apparently Debian's
device tree files are built without phandle based referencing needed for
that to work. (See http://elektranox.org/2017/05/0020-dt-overlays/)

There's also a kernel patch to let overlays be loaded on the fly using
configfs. It seems to have been around for several years without
being merged, for whatever reason, but would avoid this problem nicely if
it ever did get merged.