12 ms·

Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should prob

Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. 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.

marssaxman 3y ago
> For JavaScript it’s a bit harder. "We should probably just stop doing it" works for me.
- throwaway892238 3y ago
  Agreed. Browsers are now nothing but an application platform of APIs (https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API). For some reason they still retain the vestigial HTML, CSS and JS, but really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API. Then we can finally ship apps to users without the shackles of how a browser wants to interpret and render some markup. 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.
  - sidewndr46 3y ago
    If someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS
    - yvdriess 3y ago
      And so closing the great circle of UI framework technologies.
    - throwaway12245 3y ago
      WASM has support for SDL for a long time: https://www.jamesfmackenzie.com/2019/12/01/webassembly-graphics-with-sdl/ https://www.jamesfmackenzie.com/2019/12/01/webassembly-graph...
    - tomsmeding 3y ago
      If so, all people relying on (often limited even with html that contains text) accessibility features will have to sit in a corner and cry.
      - wg0 3y ago
        I think that should be addressable.
        Terr_ 3y ago
        Why do I get the feeling some company will address the issue by offering them a comfy chair and a free box of tissues?
    - t0astbread 3y ago
      If tri-state logic becomes viable it's game over for binary!
    - wg0 3y ago
      IF GTK/Qt etc can render to canvas using WebGPU while compiled to assembly, I think game is almost over than too IF there's a way to lazy load application modules. 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.
      - slondr 3y ago
  - xigency 3y ago
    I do think there’s never been a better time to reinvent the web, including basic technologies like HTML and JavaScript. For example, picking up more elements of semantic web and distributed systems and leveraging interconnected devices.
  - istjohn 3y ago
    The web started as a graph of hyperlinked documents, and that use case hasn't gone away. SPA's aren't the internet.
  - eternityforest 3y ago
    HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. 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.
    - throwaway892238 3y ago
      If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. 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.
      - r3trohack3r 3y ago
        > Native mobile apps thrive despite this magical web browser working 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/ 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.
  - macinjosh 3y ago
    > really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API 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?
    - ogoffart 3y ago
      The challenge with toolkits confined to <canvas> rendering is their inability to effectively utilize the browser's integration with the OS. Key components like font rendering, input methods (including standard key shortcuts and behavior within input fields), selection handling, image decoding, network stack, native-like scrolling, and accessibility features need to be recreated from scratch. A web toolkit must use the DOM for optimal performance. (and therefore lower to HTML)
  - polynomial 3y ago
    Presume you did not mean bytecode that calls ABI, but rather API? (ABI is a Web3 thing.)
    - efreak 3y ago
      > In computer software, an application binary interface ( ABI) is an interface between two binary program modules. Often, one of these modules is a library or operating system facility, and the other is a program that is being run by a user. https://en.wikipedia.org/wiki/Application_binary_interface https://en.wikipedia.org/wiki/Application_binary_interface
  - wryanzimmerman 3y ago
    But “regular old apps” don’t do all the same things. 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.
malfist 3y ago
This is an unreasonable position. Vulnerabilities can be fixed
- layer8 3y ago
  You are assuming that white hats discover them early enough before black hats.
- 2OEH8eoCRo0 3y ago
  The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.
  - dcow 3y ago
    Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute? 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?
    - rvnx 3y ago
      But wait, how is it even considered a processor bug ? 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.
      - deleted 3y ago
        [deleted]
      - duped 3y ago
        > But wait, how is it even considered a processor bug ? 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).
hyperman1 3y ago
I've wondered if we can't give a dedicated core to the browser. Of course, then web pages can steal from other web pages. Maybe task switching needs to erect much higher barriers between security contexts, a complete flush or so?
- Negitivefrags 3y ago
  It probably would be possible to add a new instruction that causes the processor to flush all state in exchange for sacrificing task switching speed. Of course it might still have bugs, but you could imagine that it would be easier to get right. 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.
  - zamadatix 3y ago
    Software can choose to invalidate all cache, fence access, and the like today. It may not be a single instruction but it's not far off. Usually something like "just don't JIT 3rd party JS to native code" is "secure enough" most don't want to go down that route though. For cloud (reputable) providers just don't allow more than 1 VM to be assigned to a core at the same time and flush everything between if they are time shared. The mitigations are the way to keep the most overall performance outside those who are most concerned with maximum security, so they are the most popular.
- bee_rider 3y ago
  I wish chips would come with a core devoted to running this kind of untrusted code; maybe they could take something like an old bonnell atom core, strip out the hyper threading, and run JavaScript on that. 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.
  - 3y ago
deleted 3y ago
[deleted]
paxys 3y ago
So one should never install software from more than one company on a computer?
- CanaryLayout 3y ago
  You install App X from Vendor Y on to vSystem Z. 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.
bee_rider 3y ago
It is sort of like the second law of thermodynamics (before statistical mechanics came around and cleared things up): sure, maybe not well founded in some analytical or philosophical sense, but experimentally bulletproof to the point where anyone who tries to sell you otherwise would be regarded very suspiciously. The idea that any two programs running on a computer can be prevented from snooping on each other.
kazinator 3y ago
> Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. 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.
bhk 3y ago
Once you "dedicate cores to specific VMs" you will find that chip designers can also screw that up, just like they can screw up protection within a core. So you might as well proclaim that "impossible to get right" preemptively.
- quickthrower2 3y ago
  They said physical processor. I took this to mean chip. Of course you can't trust chips on the same mother board (there could be a bug where they can read the same memory), so you need a network boundary. So different rack on the server, for each [boundary, however you define that...]
  - bhk 3y ago
    They said physical processor core, and elsewhere just core. That does not mean chip.
  - bhk 3y ago
    Regarding VM/core/chip/motherboard boundaries ... 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.
jl6 3y ago
There’s a marketing opportunity here to put multi-core back in the spotlight. Most workloads have reached the point of diminishing returns for adding more cores to a CPU, but if it turns out we need more cores just so we can run more concurrent processes (or browser tabs) securely, then here come the 128-core laptop chips…
- brundolf 3y ago
  Intel playing 4D chess to sell more new hardware
- dgb23 3y ago
  From a user’s perspective I often think that applications which run multiple processes, demand multiple threads and large chunks of memory are too entitled. 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.
hinkley 3y ago
This seems like a job for Arm or RISC-V or ??? 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.
accrual 3y ago
> Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. 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. [0] https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html https://www.mail-archive.com/source-changes@openbsd.org/msg9...
kristjank 3y ago
Do you really think that giving up on getting things done right is the way to progress computing? While AMD has it's own spectrum of problems and not-quite-there security features, most of their vulnyerabilities have been fixed in microcode shortly after disclosure. 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.
demindiro 3y ago
I've wondered for a while whether it would make sense to split the CPU into a "IOPU" and a "SPU" - 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.

marssaxman 3y ago

> For JavaScript it’s a bit harder. "We should probably just stop doing it" works for me.

throwaway892238 3y ago
Agreed. Browsers are now nothing but an application platform of APIs (https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API). For some reason they still retain the vestigial HTML, CSS and JS, but really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API. Then we can finally ship apps to users without the shackles of how a browser wants to interpret and render some markup. 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.
- sidewndr46 3y ago
  If someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS
  - yvdriess 3y ago
    And so closing the great circle of UI framework technologies.
  - throwaway12245 3y ago
    WASM has support for SDL for a long time: https://www.jamesfmackenzie.com/2019/12/01/webassembly-graphics-with-sdl/ https://www.jamesfmackenzie.com/2019/12/01/webassembly-graph...
  - tomsmeding 3y ago
    If so, all people relying on (often limited even with html that contains text) accessibility features will have to sit in a corner and cry.
    - wg0 3y ago
      I think that should be addressable.
      - Terr_ 3y ago
        Why do I get the feeling some company will address the issue by offering them a comfy chair and a free box of tissues?
  - t0astbread 3y ago
    If tri-state logic becomes viable it's game over for binary!
  - wg0 3y ago
    IF GTK/Qt etc can render to canvas using WebGPU while compiled to assembly, I think game is almost over than too IF there's a way to lazy load application modules. 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.
    - slondr 3y ago
- xigency 3y ago
  I do think there’s never been a better time to reinvent the web, including basic technologies like HTML and JavaScript. For example, picking up more elements of semantic web and distributed systems and leveraging interconnected devices.
- istjohn 3y ago
  The web started as a graph of hyperlinked documents, and that use case hasn't gone away. SPA's aren't the internet.
- eternityforest 3y ago
  HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. 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.
  - throwaway892238 3y ago
    If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. 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.
    - r3trohack3r 3y ago
      > Native mobile apps thrive despite this magical web browser working 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/ 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.
- macinjosh 3y ago
  > really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API 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?
  - ogoffart 3y ago
    The challenge with toolkits confined to <canvas> rendering is their inability to effectively utilize the browser's integration with the OS. Key components like font rendering, input methods (including standard key shortcuts and behavior within input fields), selection handling, image decoding, network stack, native-like scrolling, and accessibility features need to be recreated from scratch. A web toolkit must use the DOM for optimal performance. (and therefore lower to HTML)
- polynomial 3y ago
  Presume you did not mean bytecode that calls ABI, but rather API? (ABI is a Web3 thing.)
  - efreak 3y ago
    > In computer software, an application binary interface ( ABI) is an interface between two binary program modules. Often, one of these modules is a library or operating system facility, and the other is a program that is being run by a user. https://en.wikipedia.org/wiki/Application_binary_interface https://en.wikipedia.org/wiki/Application_binary_interface
- wryanzimmerman 3y ago
  But “regular old apps” don’t do all the same things. 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.

malfist 3y ago

This is an unreasonable position. Vulnerabilities can be fixed

layer8 3y ago
You are assuming that white hats discover them early enough before black hats.
2OEH8eoCRo0 3y ago
The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.
- dcow 3y ago
  Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute? 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?
  - rvnx 3y ago
    But wait, how is it even considered a processor bug ? 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.
    - deleted 3y ago
      [deleted]
    - duped 3y ago
      > But wait, how is it even considered a processor bug ? 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).

hyperman1 3y ago

I've wondered if we can't give a dedicated core to the browser. Of course, then web pages can steal from other web pages. Maybe task switching needs to erect much higher barriers between security contexts, a complete flush or so?

Negitivefrags 3y ago
It probably would be possible to add a new instruction that causes the processor to flush all state in exchange for sacrificing task switching speed. Of course it might still have bugs, but you could imagine that it would be easier to get right. 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.
- zamadatix 3y ago
  Software can choose to invalidate all cache, fence access, and the like today. It may not be a single instruction but it's not far off. Usually something like "just don't JIT 3rd party JS to native code" is "secure enough" most don't want to go down that route though. For cloud (reputable) providers just don't allow more than 1 VM to be assigned to a core at the same time and flush everything between if they are time shared. The mitigations are the way to keep the most overall performance outside those who are most concerned with maximum security, so they are the most popular.
bee_rider 3y ago
I wish chips would come with a core devoted to running this kind of untrusted code; maybe they could take something like an old bonnell atom core, strip out the hyper threading, and run JavaScript on that. 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.
- 3y ago

deleted 3y ago

[deleted]

paxys 3y ago

So one should never install software from more than one company on a computer?

CanaryLayout 3y ago
You install App X from Vendor Y on to vSystem Z. 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.

bee_rider 3y ago

It is sort of like the second law of thermodynamics (before statistical mechanics came around and cleared things up): sure, maybe not well founded in some analytical or philosophical sense, but experimentally bulletproof to the point where anyone who tries to sell you otherwise would be regarded very suspiciously. The idea that any two programs running on a computer can be prevented from snooping on each other.

kazinator 3y ago

> Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. 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.

bhk 3y ago

Once you "dedicate cores to specific VMs" you will find that chip designers can also screw that up, just like they can screw up protection within a core. So you might as well proclaim that "impossible to get right" preemptively.

quickthrower2 3y ago
They said physical processor. I took this to mean chip. Of course you can't trust chips on the same mother board (there could be a bug where they can read the same memory), so you need a network boundary. So different rack on the server, for each [boundary, however you define that...]
- bhk 3y ago
  They said physical processor core, and elsewhere just core. That does not mean chip.
- bhk 3y ago
  Regarding VM/core/chip/motherboard boundaries ... 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.

jl6 3y ago

There’s a marketing opportunity here to put multi-core back in the spotlight. Most workloads have reached the point of diminishing returns for adding more cores to a CPU, but if it turns out we need more cores just so we can run more concurrent processes (or browser tabs) securely, then here come the 128-core laptop chips…

brundolf 3y ago
Intel playing 4D chess to sell more new hardware
dgb23 3y ago
From a user’s perspective I often think that applications which run multiple processes, demand multiple threads and large chunks of memory are too entitled. 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.

hinkley 3y ago

This seems like a job for Arm or RISC-V or ??? 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.

accrual 3y ago

> Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. 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. [0] https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html https://www.mail-archive.com/source-changes@openbsd.org/msg9...

kristjank 3y ago

Do you really think that giving up on getting things done right is the way to progress computing? While AMD has it's own spectrum of problems and not-quite-there security features, most of their vulnyerabilities have been fixed in microcode shortly after disclosure. 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.

demindiro 3y ago

I've wondered for a while whether it would make sense to split the CPU into a "IOPU" and a "SPU" - 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.