Hacker News new | comments | show | ask | jobs | submit login

Serious question - should we considering speculative cpu execution to be A Bad Idea (tm) and move on from it (since these problems keep coming up), or is the thought that we more or less have been gaining performance on the back on incorrectly written software (which does not take these speculative execution edge cases into account), and the only forward is patching?

I guess a another question I have is can we win the performance back through fixes on the cpu or will speculative execution always be insecure and thus need patching in software?

Try as I might, I am not a CPU person.






Completely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve.

Speculation is not fundamentally incompatible with security. It's just that literally everyone in the industry never though that leaking information out of speculative context was possible -- and so there is no hardening anywhere. Now that it was proven possible, people are rushing to find all the ways this can be exploited. New CPUs currently being designed will fix all these, and then eventually we will have speculation without security issues.

Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it. The only real solution to that is to accept that branches cannot be used as a security boundary. This is mostly relevant to people implementing secure sandboxes and language runtimes. Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process. Any real security requires you to make use of the proper OS-provided isolation.


> Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process.

If this is true, it is unbelievably bad for the future of security and computing in general. People throwing around this assertion are, in my opinion, not appreciating how bad it is. We need to try a lot harder before we give up.

Here's why:

1. Finer-grained isolation makes security better, because it allows us to apply the Principle of Least Authority to each component of the system, and protect components of a system from bugs in other components. To make meaningful gains in security going forward, we need to encourage more fine-grained isolation. If process-level isolation is the finest grain we'll ever have, we can't make these advances.

2. The scalability of edge computing requires finer-grained isolation than process isolation. The trend is towards pushing more and more code to run directly on devices or edge networks rather than centralized servers. That means that the places where code runs need to be able to handle orders of magnitude more tenants than before -- because everyone wants their code to run in every location. If we can't achieve high multi-tenancy securely -- by which I mean 10,000 or more independently isolated pieces of code running on the same machine -- then the only solution will be to limit these resources to big, trusted players. Small companies will but shut out from "the edge". That's bad.

Luckily, the "process isolation is the only isolation" claim is wrong. It's true that we need to evolve our approach to make sub-process isolation secure, but it's not impossible at all. In fact, it's possible to design a sandbox where you can trivially prove that code running inside it cannot observe side channels.

Here's how that works: Thank about Haskell, or another purely-functional language. An attacker provides you with a pure function to execute. Because it's a pure function, for some given set of inputs, it will always produce exactly the same output, no matter what machine you run it on, or what else is going on in the background. Therefore, the output cannot possibly incorporate observations from side channels, no matter what the code does internally.

So: It is possible to run attacker-provided code without exposing secrets from the process's memory space.

The question is, of course, how do we build a useful sandbox that relies on this property. There is a lot of work to be done there. Luckily, we don't really have to use a purely-functional language, we only need to use a deterministic language. It turns out that the world's most popular language, JavaScript, is actually highly deterministic, in large part due to its single-threaded nature.

We do need to remove access to timers, or find a way to make them not useful. We also need to prevent attackers from being able to time their code's execution remotely. Basically, we need to think carefully about the I/O surface while paying attention to timing. But sandboxing has always been about thinking carefully about the I/O surface, and we have a lot of control there. We just have a new aspect that we need to account for.

I think it's doable.


> Here's how that works: Thank about Haskell, or another purely-functional language. An attacker provides you with a pure function to execute. Because it's a pure function, for some given set of inputs, it will always produce exactly the same output, no matter what machine you run it on, or what else is going on in the background. Therefore, the output cannot possibly incorporate observations from side channels, no matter what the code does internally.

This is patently false. The attacker can do timing on his side and see how long it takes your service to return a response. If you let an attacker have any sort of output channel, you give him the power to use his stuff to find side channels, and there is nothing you can do to close it.


> The attacker can do timing on his side

Yes, I mentioned that in my comment:

> We also need to prevent attackers from being able to time their code's execution remotely.

I don't think it's impossible to mitigate.

First, not all use cases actually involve the attacker being able to directly invoke and then measure the timing of their code. Imagine, for example, that I'm using attacker-provided code to apply some image manipulation to a photo on my phone, then I post the photo online. The attacker doesn't have any way to know how long their code took to execute, and I can be confident that they haven't exfiltrated side channels through the image via steganography because their code was deterministic so couldn't have incorporated those side channels into its output.

Second, I don't think the space of timer noise techniques has been adequately explored. Timer noise is one of the main defenses browsers have deployed against spectre, and pragmatically speaking it has been reasonable effective. Yes, in theory there are lots of statistical techniques an attacker might use to get around it, but it certainly increases the cost of attack. We need to figure out how to push the cost of an attack out-of-reach, even if we can't make it completely impossible.


Deterministic code cannot receive a side channel. It may, as you point out, be able to transmit on a side channel. It might even be able to "reflect" one side channel into another one. But these risks seem both less severe and more easily mitigated. At least, the history of attacks of the latter types is not very impressive.

If the attacker can do timing on their side in a pure function, then by definition the time the response takes is one of the function inputs.

Haskell functions are only pure in an abstract sense that ignores micro-architectural side-effects and the resulting timing changes. All of the recent speculative side-channel attacks are the result of the abstraction layer exposed by modern processors leaking. You can't fix this by putting more abstraction layers with neat theoretical properties on top.

You can't be guaranteed to prevent the attacker form writing information to those side channels but you can guarantee that the attacker can't read from those side channels because reading from them requires doing timing analysis and timing analysis requires IO - which we've stipulated hasn't been passed to the attacking function.

> 2. The scalability of edge computing requires finer-grained isolation than process isolation.

Why? Browsers are moving to one process per security domain anyway. Workers spawn their own threads too. You have to make your processes more lightweight and optimize memory-sharing, but that's exactly what's happening.

There's also some vodoo one might be able to do on linux with the clone syscall which lets you spawn a new process which still shares the same memory as the parent.


> Browsers are moving to one process per security domain anyway.

At a significant cost in RAM usage and some CPU overhead too. But browsers have the advantage that they are sitting on desktops and laptops that are massively underutilized, and the number of security domains you might typically have open at once is in the 10's or 100's, not 10,000's.

But that's not what I was talking about with "edge computing". I'm the architect of Cloudflare Workers, an edge compute platform. We have 151 locations today and are pushing towards thousands in the coming years, and every one of our customers wants their code to run in every location. As we push to more and more locations, the available resources in each location decrease, but the number of customers will only increase.

At our scale, unlike browsers, one-process-per-customer just isn't going to scale. Context switching is too expensive, RAM usage per process is too high, etc. So we need other ways to mitigate attacks.

> There's also some vodoo one might be able to do on linux with the clone syscall which lets you spawn a new process which still shares the same memory as the parent.

It's not really voodoo. Linux has no distinction between processes and threads. Everything is a process. But two processes can share the same memory space. Usually, developers call these "threads", and use "process" to mean "the set of threads sharing a memory space".

In any case, if it's the same memory space, then it's susceptible to Spectre attacks.


There are limits to Site Isolation. For example, due to document.domain, subdomains of a domain cannot generally be protected from one another.

kentonv is correct that giving up on intra-process security entirely is an ominous sign.


What we need is the equivalent of inter process isolation for intraprocess sandboxes, i.e. an hardware solution (hopefully this time not affected by Meltdown).

And we might already have it. Thanks to virtualization hardware, it should be possible for a process to own and handle its own private page table mapping completely from userspace [1].

Switching from the sandboxed code to the sandboxing code might be more expensive than a plain function call, but still way faster than IPC.

[1] For example, libDune (https://github.com/ramonza/dune), which admittedly seems a dead project. Also it requires OS support.


On JavaScript being a secure sub-process sandbox, as my manager told me months before Spectre, "Pwn2Own says otherwise." Much to my disappointment.

JavaScript is the most secure we have. The fact that it is subject to Pwn2Own is part of why. Other sandboxes have not received anywhere near the scrutiny, and surely have many more bugs that simply haven't been found.

Process, container, and VM isolation all have lots of bugs too.


Do you think it's likely, though, that a language-based sandbox is more secure than a process-based sandbox? Every major browser developer has now embraced process-based sandboxing in addition to the JavaScript sandbox they already had. Believe me, I want sub-process sandboxing to be viable. But now, post-Spectre, I think it's hopeless.

The combination of language-based sandboxing and process-based sandboxing is, of course, more secure than either on its own. More layers can only help. You could go a step further and run the process sandbox inside a VM. And run that VM on a dedicated machine. Each layer helps -- but each layer is more expensive, and at some point the cost is too high.

But process-based sandboxing does not replace language-based sandboxing. Operating systems (e.g. Linux) have bugs all the time that allow processes to escalate privileges. It's also not at all clear that process-based sandboxing is enough to defend against spectre, either. But it's much harder to design an attack than can break both layers, than to design one that breaks one or the other.

Certainly, if process-based sandboxing does not add too much overhead for your use case, then you absolutely should use it in addition to language-based sandboxing. But there are plenty of use cases where processes are too much overhead and we really need language-based sandboxing to make progress.


"If this is true, it is unbelievably bad for the future of security and computing in general. People throwing around this assertion are, in my opinion, not appreciating how bad it is. We need to try a lot harder before we give up."

It's true, though. It's been known since the early 1990's when they wrote about all the timing channels and such in VAX CPU's. The good news is there's both architectures and tooling that can do anything from eliminating to reducing these issues. You just have to design the processors for them. Otherwise, you're constantly playing a cat and mouse game trying to dodge the issues of running code needing separation on a machine designed for pervasive sharing.

One thing I came up with was just going back to physical separation with a lot of tiny, SBC-like computers with multicore chips. Kind of like what they use for energy-efficient clusters like BlueGene. One can do some separation at a physical level with better, software-level separation from there. The stuff that truly can't mix gets the physical separation. The rest software using things like separation kernels with time/space partitioning. At least one of the commercial vendors reported being immune to CPU weaknesses due to how separation and scheduling work. Whether true or not, the stronger methods of separation kernels make more senses now given they'll plug some links. The other method I came up was invented before with a patent. (sighs)

"Because it's a pure function, for some given set of inputs, it will always produce exactly the same output, no matter what machine you run it on"

That's not true btw. It gets converted into whatever the internal representation is running through circuits done on that process node. These create analog properties that might be manipulated by the attackers to bypass security. I warned people about that when I was new on HN like I did on Schneier's blog. I learned from a hardware guru who specialized in detecting or building that stuff mainly over counterfeiting not backdoors. We're seeing numerous attacks now that use software to create hardware effects at analog level. There's ways to mitigate stuff like that but I have no confidence they'll work with complex, highly-optimized hardware with a billion transistors worth of attack surface to consider.

So, as Brian Snow advocated in "We Need Assurance," you have to reverse the thinking to start with a machine designed to enforce separation from ground up in its operations. Then, OS/software architecture on top of that. Good news is CompSci has lots of stuff like that. Someone with money just has to put it together. More attacks will be found but most will be blocked. We can iterate the good stuff over time as problems are found addressing as many root causes as possible.


Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it.

Is it not a feasible fix for Spectre-v1 to have loaded cachelines wait in a staging area, and not actually update the cache hierarchy until the load instruction is retired?


Loading those cache lines might invalidate an exclusively held cache line on another core. When that core tries to write to that cache line, it can observe a slower write.

Is it theoretically possible? Maybe. Is it practical? Almost certainly not.

Keep in mind that it's not just the L1 cache you potentially need to worry about, but also all the higher level caches, which are really like remote nodes in a distributed system. Even the last level cache would have to be aware of the current speculation state of all threads in the system, which seems like it would be really expensive.

What's perhaps even worse, you wouldn't be able to hit on speculatively loaded cache lines until they have "committed" (because the resulting change in external bandwidth utilization may be observable from another thread), which would probably kill a lot of the benefits of the cache in the first place.


Yes, you can buffer up and kill any misspeculated updates. You have to do this for ALL shared structures, not just data caches. Annoying, but not impossible.

The scarier part is managing bandwidth contention to shared structures.


I know the Arm A-53 isn't cutting edge fast, but hardly one tenth. Seeing as the A-53 is unaffected by both Meltdown and Spectre, my assumption was that it didn't use speculative execution.

Basically every CPU with a pipeline -- even simple, in-order cores -- speculate by way of branch prediction. I think with the Cortex A53 the pipeline is short enough and the branch predictor simple enough that you can't build a useful spectre attack. It's also common in simpler in-order cores to speculate a little bit around memory accesses.

There are architectural choices for pipelined systems you can make that don't specex, but it requires compiler level optimization to take advantage of them, so it's a chicken and egg problem to get adoption

Been there, done that, didn't work. VLIW has been tried a dozen times and failed every time.

I think you're being too dismissive here. First of all, VLIW has been hugely successful in DSP cores. Your phone probably has a few in it. Second, Itanium wasn't great but it wasn't terrible either. And the Transmeta/NVidia lineage have also been not terrible. There isn't any reason to choose them over a conventional OoO processor absent security concerns but if they really do help with security concerns then these approaches bear careful investigation.

machine learning has been tried a dozen times and failed every time.

Other developments catch up, like compiler technology. Not directly related to branch prediction, but: We are much better at polyhedral optimization than the last time people tried VLIW, for example.

Besides, the last major VLIW push (itanium) DID have SpecEx AND Branch Prediction, and did NOT have delay slots.


Shrug. To paraphrase, your argument for "this can be done" is "THIS time will be different I swear!".

What will actually happen, of course, is that everyone will put a ASID/PCID as a tag word into all the relevant caches, they'll stop being probe-able from other contexts, and we'll all keep our deep pipelines and speculation and the cache crisis of 2018 will be just a story we tell our grandkids.

Much cheaper than a paradigm shift based on long-since tried and rejected technology.


you are fundamentally misunderstanding my argument: sometimes it is different. When it is different, it's usually because associated technologies has changed. For ML, it was GPUs and large amounts of data harvestable from the internet (arguably the second one more than the first). The evolutionary development in compilers is a strong argument that it MIGHT happen to end SpecEx. If it doesn't it's probably mostly due to technical debt and engineering inertia, difficulty convincing end users to adopt. There are definitely cases where non specex (vliw or otherwise) can outperform, I have seen it with my own eyes.

> If it doesn't it's probably mostly due to technical debt and engineering inertia

You jumped straight from "absence of proof must be proof of the opposite" into as bald a no true scotsmanism as I've seen recently. It's like fallacy central here.


An argument of the form "many X failed, but a new X might not" is not a form of no true scotsman. It would only be no true scotsman if the claim was "X always wins, and Itanium wasn't X"

But anyway I think they're making a fair argument. If something takes an enormous technical effort to switch to, and is similar in performance, nobody is going to put in that effort.

This is emphatically not evidence that the idea "doesn't work".

I believe if you could retroactively wipe out the last decade of improvement on x86 and Arm, and redirect all of that development effort to VLIW, the resulting chips and software would perform just fine by current standards.


Thought it was effected by spectre - meltdown was the exploit that only effected a subset of the market. Meltdown is specifically due to load speculation happening prior to verifying access permissions.

Spectre is more generally due to load speculation modifying the cache while inside a branch speculation context. Basically it effected every high performance cpu in some way. Note that saying there’s a protected/safe branch instruction is only effective if the default branch code gen uses it, so I’m not including such mitigation’s when saying “not effected”. I believe that to be a justifiable decision.

Essentially the only cpus that weren’t effected were those with very little, if any, out of order execution. None of them are considered to have competitive performance.


In this context, getting "affect" and "effect" straight is important.

details :)

All CPUs speculate to some extent (branch prediction has been on everything for basically 30 years now). Intel CPUs got hit first because they're the first ones to speculate so deeply that you can discriminate cache behavior like this. The caches and pipelines just aren't big enough elsewhere, but the techniques are all the same.

Nope, Intel got hit because they did it wrong, and the others did it right. If you speculate you need two status registers. One for the good and one for the bad case. Same for meltdown: you need one for the kernel and one for user space. Intel didn't care, others do.

But Intel got the government ("legal") backdoors in. Priorities.


What are you talking about?

Meltdown was caused by Intel not checking privileges correctly in a speculated context, choosing to defer such checks as long as possible. This allowed the worst and easiest to use exploit, making it possible to read from any mapped location in memory. Most other CPUs did things right even in speculated contexts.

(Intel wasn't quite alone in this, though -- at least one ARM core also had this issue.)


It's affected by spectre, but not meltdown.


I wonder why do we have to rely on CPU to parallelize code. Surely compiler could do better job and CPU should just offer transistors without any smart logic. It's not backwards-compatible and I'm aware about Itanium fiasco, but I'm not compelled that it's a wrong way.

As someone who works in compilers: no, it's not possible to make the compiler do a better job. There's a reason why VLIW architectures keep getting proposed and keep dying.

The instruction-level parallelism that a CPU can extract is primarily a dynamic kind of parallelism. You can, say, have a branch that's true 1000 times, then false 1000 times, then true 1000 times, then false 1000 times, etc.--as a compiler, telling the hardware to predict true or false is going to guarantee a 50% hit rate, but the stupid simple dynamic branch predictor will get 99% on that branch.


Well, there are middle grounds, such as EDGE architectures, that get you somewhere in the middle of a VLIW and CISC machine, where everything is not so rigid. The trick isn't that the compiler must do better in scheduling things perfectly against unknown, dynamic information -- but must emit the information it already knows, and they currently throw away. This is how TRIPS worked, where the compiler placed instructions statically like a VLIW machine (it was a grid-like architecture, so this is obviously important), but the CPU issued instructions dynamically at the basic block level, like a OoO CISC machine. The secret is you encode the dataflow dependencies inside basic blocks, more or less -- so the CPU does not have to rediscover them.

I worked on compilers too, and I think there is definitely still work to be explored here. Really, complicated OoO speculative processors are simply recovering a lot of the information the compiler already calculated! You take this code that is in no way suited for a CPU, and you do a ton of dataflow and high-level analysis on it (that you can only know from the source). You build this graph and optimized based on these facts. And then, you throw away the dataflow graph when you lower things. All this, after painfully calculating it on the assumed basis of "Yes, the CPU will like this code" -- only for the CPU to perform that whole process over again, say "Yes, I do, in fact, like this code" -- so it can execute efficiently without stalls anyway. There's clearly a mismatch here.

I mean, don't get me wrong -- this all seems like a perfectly fine and acceptable engineering tradeoff, but just disappointing from a computer science perspective, to me, at least, that this is not unified :) Of course, VLIW vs CISC etc is one of the classic debates...

Interestingly, Aaron Smith from Microsoft Research (and one of the original members of the TRIPS project) actually demonstrated and talked about their work on newer EDGE processor designs at MSR, and even demonstrated Windows running on an EDGE processor, this past week or so at ISCA2018 (complete with a working Visual Studio target, using an LLVM-based toolchain!) Their design is quite different from TRIPS it seems. I'm hoping the talks/work becomes public eventually, but that might just be a dream.


I should clarify that the idea that is wrong is that just exposing the hardware bits to the compiler and expecting the compiler to do better. There is certainly more scope for the compiler and the hardware to work together to make the results better, but exposing current hardware mechanisms is not the means to do to that. Of course, try getting architecture and compiler people actually talking to each other. :-)

What are your thoughts on the Mill CPU team's claims re: their ISA allowing compilers feasibly to schedule operations statically?

They execute everything in order on a fairly short pipeline but they engage in speculative execution just like everyone else. Here's their talk on their branch predictor.

https://millcomputing.com/docs/prediction/

There's a lot less mischief you can get up to when you only execute a couple of instructions beyond a mispredicted branch rather than a hundred but mischief can't be theoretically ruled out entirely.


you can do this to some degree on most CPU's - moving loads away from their results being used - compilers, esp on RISC machines with lots of registers, do this today

VLIW machines allow you to provide hints about instruction level parallelism without all the superscalar on-the-fly analysis of instruction level data dependencies (so the hardware can do all that rescheduling on the fly).

I think that if interlock-free software scheduled CPUs allowed us to reach 20GHz clock speeds where complex superscalar machines were stuck at 3GHz we'd all be jumping ship - but they're not


Essentially the CPU is running a JIT branch optimization and speculative loads which cannot ever be matched by static optimization. The interesting part is that any JIT compiler that is so dynamic in performance will have these problems.

The solution might be to actually prevent some kind of security important code from being optimized in this way. Say, forcing full cache sync in-order execution for parts of code with no resource sharing between cores.


hmm ... I wonder if there are JiT compilers with smallish caches that are susceptible to these attacks (but over much larger time scales)

> I think that if interlock-free software scheduled CPUs allowed us to reach 20GHz clock speeds where complex superscalar machines were stuck at 3GHz we'd all be jumping ship - but they're not

Additionally, realize that clock speeds are not a relevant performance metric. Maybe, perhaps, it's possible for a software scheduled CPU to run at 2*n GHz, but that's not interesting, if it's slower in real-world workloads than todays tech at n GHz. And for breadth-deployment in data centers we're mostly looking at throughput per Watt. CPUs with high clock speeds don't do well in that area because semiconductor physics.


right, that's why we don't have really high clock speeds - that's not the point here

VLIWs can make use of the same branch predictors that you see in out of order cores like an Intel Core or in order cores like an ARM A53. The big problem that VLIW faces is starting loads early so that they've finished by the time you need their contents. Itanium tried to do that but their mechanism really broke down in the face of possible memory exceptions and it didn't speed things up much. Mill has a cleverer way to speculate with loads which might work better but it's still entirely unable to speculatively load values across boundaries between codebases, like system calls. But of course speculatively loading across system calls is what's causing problems here. So it might be that the best thing is to accept the 80% performance solution in the same of security through keeping the hardware simple enough to understand.

A quote I once heard from a friend: "Don't turn your normal problem into a distributed systems problem."

Arguably, the reason for Spectre, etc., is that people have failed to realize that at the scale of modern intel CPUs, these problems already are distributed systems problems.

The compiler cannot compete with the CPU because the CPU has strictly more information. Any memory access can take between 4 and thousands of cycles of time to execute, and the compiler won't know how long any of them take. The CPU can reorder based on exact knowledge.

Using profile guided optimization can help a lot with this in practice, though it isn't perfect.

> everyone in the industry never though that leaking information out of speculative context was possible

Everyone overlooked it, or everyone had a good reason to think it was impossible? The information is there; it's a target that needs to be secured.


Thank you for your response!

I think Spectre is even less severe then Meltdown though.

We can't really get rid of speculative execution, but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure.

It's interesting that the future predicted by excellent (and entertaining) talk The Birth & Death of Javascript [1] will now never come to pass.

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...


> We can't really get rid of speculative execution

Why not?

> but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure.

If we accept that, then we also need to get rid of the idea that we can branch differently in trusted code based on details of "untrusted data".


Your last point is basically what Spectre v1 mitigations are all about, at least if you throw in the word "speculation" somehow. The rule is: don't speculate past branches that depend on untrusted data (though there are certain additional considerations about what the speculated code would actually do).

It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them is perfectly fine and extremely valuable for performance. That's why nobody wants to get rid of speculative execution.


It sounds like what we really need is a memory model that reflects this notion of trusted and untrusted data. The "evil bit", basically, but for real.

Speculative execution isn't an inherent security risk, but it typically entails a cache fill, which can, if not cleaned up or not isolated, can be used for a timing attack. That's the real issue here: that execution results in mutating a shared datastore, and facts about the likely contents of that datastore can be inferred from performing additional operations and self-measuring aspects of one's own performance.

In the larger sense, mixing various privilege levels on shared hardware is likely a bad idea, despite being fundamental to general-purpose computing. This is because it's fairly difficult to cloak intrinsic "physical" attributes of execution, like execution timing, cache timing, from other processes, and essentially impossible (and/or unreasonable) to cloak it from one's own process. It is both possible for a process to generate lots of side-effects (e.g. IO, cache fill), and for it or another process to try to figure out ways the shared state changes by observing its own execution.


Personally I wonder if it will ever be possible to have a platform totally free of side-channel attacks, whether or not it uses speculative execution.

No, probably not, but as with all security, electronic and otherwise, the goal is to make breaking the security cost more than whatever it's protecting is worth (for some arbitrary definitions of "cost" and "worth").

From what I understand, speculative execution is “worth it” in most non secure contexts. Furthermore, it seems like one could hypothetically implement speculative execution “correctly”, where speculation is still gated by the constraints of non speculated executions. Could this be a problem that proof software could solve? I still have hope.

maybe only on things that have huge targets on their backs?



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: