Hacker News Reader

Comment by baybal2 | Hacker News Reader

Again, I reiterate: it's not humanly possible to make performant, general purpose CPU that is 100% safe from instruction level attacks.

Untrusted code execution must go, that's the only way.

The genie is out of the bottle now. There will be more and more practical instruction level attacks with each year now.

View on HN

> Untrusted code execution must go, that's the only way.

This is how you get corporate rule over what can and can't run on machines you own.

Safer architectures can be developed, without handing over control to a third party.

I don't believe that even a complete comparch-101 in-order, non-pipelined, architecture without branch prediction, and register renaming can be made safe enough.

But yes, the industry made an extremely risky bet a decade ago with both virtualisation, and running unsafe Javascript with JIT.

It will take many billions for the industry to do a U-turn, and switch back to dedicated servers as a golden standard, and putting a leash on ambitions of browser makers.

> I don't believe that even a complete comparch-101 in-order, non-pipelined, architecture without branch prediction, and register renaming can be made safe enough.

Disagree. You do have to put a lot of work into the process. Formal spec as well as a formal method/simulation. There are certainly a lot of fun things to consider in that, but I don't think it's completely unfeasible.

As an aside, one of the things that intrigues me about RISC-V is things such as a formal instruction set spec being openly published [1]. You could apply all sorts of tooling to that before actually creating silicon.

> But yes, the industry made an extremely risky bet a decade ago with both virtualisation, and running unsafe Javascript with JIT.

Focusing so much on Jitting JS was as bad idea then just like it was now. The entire world of the web is artificially propped up and will probably die the way it should have died when it started: with people frustrated by constant security vulnerabilities enabled by a group of ad companies who don't care about anything but money.

> It will take many billions for the industry to do a U-turn, and switch back to dedicated servers as a golden standard, and putting a leash on ambitions of browser makers.

WRT Dedicated servers, if anything the industry needs that push now anyway. I've yet to see a 'Real' cost projection on a SaaS 'rewrite'; i.e. if the current thing has been in use 5 years longer than it should have, your cost models should go out 5 years longer than you intend your new solution to exist.

Which would be ironic; my pain is in the beancounting side (usually what an org really cares about) yet security will be the more likely scenario.

I think the cat is out of the bag for the browser market though. Users have on the whole gotten 're-enclosed' thanks to modern laptops tending towards small eMMC or SSD sizes.

But FFS, this sort of thing is the reason WASM scares the daylights out of me.

[1] https://github.com/mrLSD/riscv-fs

Can't edit, but obviously the web won't die. But it is going to change a bit over the next few years still; the privacy changes are likely to be a big catalyst for a lot of change...

Any idea if the fundamental incompatibility between GDPR and "cloud" is ever going to come home to roost? (You know, how personal data is supposed to be deleted on request, but the whole idea of "deletion" is pretty hard to properly execute in practice without physically destroying the storage, especially for transistor-based storage like SSDs!)

> especially for transistor-based storage like SSDs!

It's actually much easier to render deleted data unrecoverable on a flash based SSD than a hard drive, if you're willing to use only SSDs that eschew a few very common performance optimizations. So that fits right in with the theme.

Is simply unlinking a file in the FS not sufficient for GDPR compliance?

It's supposed to be erased, not put in a pile of “things to write over at a later date”.

This is how you get corporate rule over what can and can't run on machines you own.

He isn't necessarily talking about the "untrusted by corporates" situation, maybe just "untrusted by the user".

(Personal pet peeve about "trusted" and "untrusted" --- never neglecting to mention the by who!?)

Every consumer-facing trusted computing platform only allows keys from corporate entities, and usually only software signed with approved keys from said entities are allowed to run.

I can't get behind trusted computing until there is a strong movement and culture behind allowing user freedom on trusted computing platforms. As it stands, that isn't the case at all. Just look at the iPhone and Notarization on the Mac.

>Untrusted code execution must go, that's the only way.

Ironically, you have to enable third party javascript to even view the page.

The page is perfectly readable with no JS at all.

Not "perfectly" at all. The abstract is readable as is the click to the PDF, which is readable. The FAQ list below doesn't open, and the icons which drive the open/close actions appear as "tofu" characters.

However, the data is in all in the document source; the JS just plays with the visibility. I.e. there are no dynamic tricks to populate that.

I don’t think so. Side channel attacks became recently more mainstream and people start designing stuff with it in mind.

What you see here is yet another attack on a relatively unused Intel-only x86 extension.

The bigger problem is that Unixes and Windows are pretty bad at sandboxing syscalls by default.

I do remember there 100% were academic papers throwing barbs into Pentium 3 branch predictor security back in nineties. They just went unnoticed for there being no Google logo on the paper.

People in hardware engineering community knew of their existence long ago. It was just them not being practically exploitable that kept them from headlines.

But now we have a multibillion buck virtualised hosting industry, and JS with JIT in every browser — a million buck incentive for black hats to poke into architectural vulnurabilities

> back in nineties. They just went unnoticed for there being no Google logo on the paper.

Google wasn't nearly as big a deal back in the 90's (hell, they were only really around the last couple years of the decade) so that's a weird association to make.

You can avoid instruction-level attacks by putting untrusted code on an isolated core with an isolated memory module, right? That seems more likely to me than everyone disabling javascript.

Maybe with the recent influx of larger core count systems, this isn't entirely unreasonable in the future.

> You can avoid instruction-level attacks by putting untrusted code on an isolated core with an isolated memory module, right?

No, unfortunately. Side channels will work even across numa domains, and cores with own memory.

Side channel free hardware is extremely hard to do even in simplest ISAs specially made for that. Look at how credit card industry keeps struggling making safe smartcards.

Any sufficiently powerful side channel that works across a network goes beyond "running untrusted code", though. It's a whole different level of problem to solve.

And we should be able to eliminate anything weaker.

These CPU vulns have all been related to performance optimizations. Do you have any reason behind your claim that a CPU without such optimizations would be vulnerable?

It's harder to believe that there is _no way to leak information_ than the opposite. There is always a side channel, right? Timing is the most trivial one.

When every instruction takes the same amount of time (no speculative execution or cache sharing), then no, there is no timing attack. There isn't any reason to support the claim that all CPUs are fundamentally vulnerable to these types of attacks.

Then it should be written on the product packaging. Big letters.

Reply on news.ycombinator.com