"We should probably just stop doing it" works for me.
The idea of security "sandboxes" is quaint, but have been defeated pretty much since their inception. And the only reason we have "frontend developers" rather than just "developers" is HTML/CSS/JS/DOM/etc is a byzantine relic we refuse to let go of. Just let us deliver regular-old apps to users and control how they're displayed in regular programming languages. Let users can find any app in any online marketplace based on open standards.
Think Autodesk products. Certain parts (wasm modules) only load when you hover over a menu while overall app loads within milliseconds because it just has the main window and such.
HTML is declarative. The machine understands it. I like things machines can understand and optimize. Things that you can write automated tools to work with because it's not a full turing machine. If you want to make a screen reader, you can. If you want to reflow for mobile in a better way, you can, because you know what's text and what's an image.
Just giving people a programming environment and the ability to draw some pixels, the browser has no idea what the intent is. There's nothing to optimize unless the individual sites do, and I doubt they have Google and Mozilla's budget.
We already have too many unnecessary powerful imperative systems out there.
For example, picking up more elements of semantic web and distributed systems and leveraging interconnected devices.
It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform.
I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular.
Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.
Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads in 2022, generating billions in revenue. That's not a mistake or accident; that's a market filling a need.
If we really want an application platform that works everywhere, then let's stop dicking around with these stupid document hypertext viewers and build a real app platform that works everywhere.
There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients.
Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/)
Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”)
I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.
For mobile apps you can use webview component which will use system browser. You don't need to ship the entire browser (actually you can't even do that on iOS).
But you're not allowed to for iOS: https://developer.apple.com/app-store/review/guidelines/#min...
There are still tons of things that don't need an app. Things that are inherently online and not accessed frequently work fine as sites.
The web doesn't limit what you can do that much, it limits how you can do it, which I think is a good thing. Less to break (Android API levels have the same effect) with fewer original lines of code. Less focus on clever and interesting code and more focus on UI and features (Although they try their best to reinvent the same js framework 1000 times).
A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions. The trend has been pretty strongly towards making the web very close to native apps, with all kinds of APIs.
Native apps fill a use case very well, that the web does not. That doesn't make the web obsolete.
Don't denigrate Mozilla for protecting users. There are a lot of privacy issues that can't be addressed by permissions models, Android serves as an example of that. Enumeration is not effective.
If Mozilla are standing in the way of invasive webpages, more power to them.
That is exactly what standardization means, by definition, both dictionary and colloquially.
This didn't work out that great with MSIE.
But it seems to have worked great for years for Chromebooks!
Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?
The whole point of properly developing web apps is that html/css indicates a certain level of semantic understanding which allows for different interpretation in different contexts.
If you build a web app well, you build it to be a good experience on a computer for a power user with a huge screen and a keyboard for shortcuts, good for a user on a tiny touch screen, good for a blind person who doesn’t use a screen, and good for robots to parse and index. It should even be good for someone on an iPad with a mouse or a pencil which interprets the whole concept of the mouse differently from the desktop user’s mouse.
The agreed-upon semantics of HTML and the separation of visual styling into CSS is what allows you to take a step beyond just building an app and add a layer of “say what you mean” such that human and non-human users can re-interpret it into their own devices, use cases, and specific needs.
Web frontends are at their best when you don’t expect to perfectly control the end user experience, but try to convey the semantic meaning as perfectly as you can so it can be interpreted into good experiences even in situations where the display is wildly different than originally intended.
Of course, it’s not doing much for the billions of devices that exist.
I would hope that we could find a software solution that web browsers can implement so that devices can be patched.
Either way, I would want such a solution to not compromise performance in the case where code is running in the same security context.
This is what I don’t like about existing mitigations. It’s making computers slower in many contexts where they don’t need to be.
If a script can’t run happily on a core like that, it should really be a program anyway, and I don’t want to run it.
Partitioning tabs according to trust would be ~fine, but laborious and error-prone.
Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?
You write data inside the registers, yes, other processes can read these registers.
It always been like this, and is absolutely normal.
It's the responsibility of the operating system to clear the registers if it is switching context.
These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).
In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT.
Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists.
If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration.
You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.
Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ
The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on.
Keeping the security context intact and separated is a gargantuan task.
To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.
It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads.
If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.
Responsible people tend to pick the small consequence now over the unknowable distribution of consequences later.
Not always the damage.
That's a highly optimistic position, to the point of being almost wishful thinking.
The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now.
Other similar ones to be published years into the future are also there today being likely exploited as we speak.
Running untrusted code on the same silicon as sensitive code (data), is unlikely to ever actually be truly safe.
We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.
This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior.
Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.
Yes. I did not mean to imply the real problem had a simple solution.
Even if we could say for sure that x86 has been disproportionately affected by speculative execution bugs (which already seems dubious), that could easily be due to a kind of selection bias. Presumably security researchers as a group more or less focus on the most popular and relevant ISAs/microarchitectures.
Vector is found to get untrusted code C to run in the user area on Z via exploit in X that Y has not acknowledged, so researchers publish a CVE with an example.
C starts trying to read memory from threads shared on same vCPU, revealing db connection string used by X, the nonce and salt for hashing.
Attacker now has the keys to the entire kingdom.
Yes. This has had its heyday: the era of the time-shared systems, from the 1960's, right into the 1990's (Unix systems with multiple users having "shell accounts", at universities and ISP's and such). These CPU attacks show us that secure time-shared systems where users run arbitrary machine code is no longer feasible.
There will still be time sharing where users trust each other, like workers on the same projects accessing a build machine and whatnot.
A number of vexing CPU security vulnerabilities have resulted from a general class of optimizations that share cache resources (memory, TLBs, branch prediction tables, etc.) across different domains, which enables cross-domain attacks.
There is a potential for vulnerabilities even when the domains are separated by a network boundary ... if those domains view the world through some shared cache at the network layer.
I know it’s a (not even) half baked thought. But there’s something to that. We never really think of “how many resources is this application allowed to demand?”
Software would be orders of magnitudes faster if there was some standard, sensible way of giving applications fixed resource buckets.
Sacrifice IPC/core to reduce gates per core, stuff more cores into a square centimeter, pin processes to cores or groups of cores, keep thread preemption cheap, but let thread migration take as long as it takes.
Arm already has asymmetric multiprocessing, which I feel like is halfway there. Or maybe a third. Fifteen years ago asynchrony primitives weren’t what they are today. I think there’s more flexibility to design a core around current or emerging primitives instead of the old ways. And then there are kernel primitives like io_uring meant to reduce system call overhead, amortizing over multiple calls. If you split the difference, you could afford to allow individual calls to get several times more expensive, while juggling five or ten at once for the cost of two.
I believe this is why OpenBSD disabled SMT by default in June of 2018. [0]
It can still be enabled with a simple 'sysctl', though.
We as an industry should stop excusing chipmakers from doing their jobs and reject broken products. It's brand loyalty all over again, like when Apple does something retarded like losing the headphone jack and the whole industry follows, breaking years of interoperability.
When the products/services we buy break, we should demand better, not lower our expectations.
- The IOPU would be responsible for directing other hardware on the system. It doesn't need to be very performant.
- The SPU would be optimized for scalar and branch-heavy code that needs to run fast.
The SPU could have minimal security, just enough so it can't read arbitrary memory when fetching from RAM. It would only run one program at a time, so speculation shouldn't be an issue.
At least on my system few programs need a lot of processing power (and even then only intermittently), so little task switching should occur on an SPU.
There are really only two common cases for this anyway. VMs and JavaScript.
For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers.
For JavaScript it’s a bit harder.
Either way, we need to not be giving up performance for the the normal case.