OSDev.org

XenOS wrote:I was just pointed to an interesting article that I would like to share:

Intel in 1995 wrote:A secure operating system would set the TSD flag during system initialization to disable user access to the time stamp counter. An operating system that disables user access to the timestamp counter should emulate the instruction through a user-accessible programming interface.

OSwhatever wrote:Is there a good reason cache flush instructions should be available to user space at all?

Brendan wrote:Note that there is no actual security problem with CLFLUSH itself. There's a security problem caused by dodgy RAM chips ("rowhammer") where even good/non-malicious software can cause unintended RAM corruption; and there's a problem with "too precise timing" that leads to all kinds of timing side-channels (including data caches, and instruction caches, and TLBs, and shared resources in "attacker and victim sharing core" SMT cases, and ....).

azblue wrote:There are a couple questions I have arising from the OP and some of the comments:

1. Does this mean we shouldn't bother with ASLR? (Isn't it almost "security through obscurity" anyway?)

azblue wrote:2. Regarding timing attacks, how precise can timing be before it becomes a security concern? This is something I've wondered for quite a while.

    do {
        last_tsc = rdtsc();
    } while(last_tsc % uncertainty != 0);
    return last_tsc/uncertainty;

Brendan wrote:I'd expect that an "uncertainty value" of a few hundred cycles would be enough to make half of the attacks (those that rely on cache timing or "shared resource in SMT timing") go from "vaguely plausible" to "impractical". I'd also be tempted to make the amount of uncertainty proportional to how often software asks for the time (e.g. 200 cycles of uncertainty if you ask for the TSC infrequently, and 999999 cycles of uncertainty if you ask for TSC millions of times per second).

Korona wrote:

Brendan wrote:I'd expect that an "uncertainty value" of a few hundred cycles would be enough to make half of the attacks (those that rely on cache timing or "shared resource in SMT timing") go from "vaguely plausible" to "impractical". I'd also be tempted to make the amount of uncertainty proportional to how often software asks for the time (e.g. 200 cycles of uncertainty if you ask for the TSC infrequently, and 999999 cycles of uncertainty if you ask for TSC millions of times per second).

Note that there are programs that legitimately ask for TSC 10s - 100s of thousands times per second. The overhead of a syscall would totally kill those applications.

azblue wrote:There are a couple questions I have arising from the OP and some of the comments:

1. Does this mean we shouldn't bother with ASLR? (Isn't it almost "security through obscurity" anyway?)

2. Regarding timing attacks, how precise can timing be before it becomes a security concern? This is something I've wondered for quite a while.

Brendan wrote:Which applications, and why?

Korona wrote:

Brendan wrote:Which applications, and why?

For example if you're polling (IRQs do not make sense at high I/O rates) a low-latency link (e.g. Infiniband) and want to keep track of RTT or wait times. I'm sure there are more examples in real-time applications, this is just one I know of.

EDIT: Another example would be performance measurements in HPC applications like SAT or ILP solvers or physics/weather/fluid/whatever simulation.

Brendan wrote:That doesn't really sound like enough to matter; given that NIC drivers are drivers (which tend to be "more trusted" and could or would be exempt) and the rest don't need precision at all (e.g. benchmark how much work they can do in a 5 day period and you can use a sundial instead ).