5 ms·

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in r

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon? I don't know enough about this issue to speak to the issue either way, but I would love to hear if this fix is possible/viable.

nine_k 9y ago
I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)
- djsumdog 9y ago
  For years, Intel and AMD processors have supported patching using microcode updates. Until we know the embargo is lifted and we know the full extent of this vulnerability, we won't know if that would be possible.
  - nine_k 9y ago
    The fact that the firmware interface is strictly non-public also does not help predicting things.
  - daenney 9y ago
    Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue a microcode update and the Linux kernel wouldn't be accepting this patch set as a mitigation for this issue (which is all this patch set is, it has no other benefit to the end user than fixing this bug).
    - zimmerfrei 9y ago
      It depends on how long it takes for Intel to go through all regression tests for all affected platforms. If it takes several months to complete, a countermeasure in the kernel update may still be the better stopgap. Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution for older generations.
      - dx034 9y ago
        They knew of the issue since June. Now that the patches are out it'll be hard to regain the performance. I doubt they are able to issue a microcode update within the following months. Otherwise large clients such as AWS would have implemented that instead.
    - rurban 9y ago
      I wouldn't be so sure about that. Linus and Gross might think that it could be microcode fixable, because they wanted it configurable. Opt-out. However in the current patchset it's mandatory. With a future os-specific microcode patch a config option would make more sense. They just need to find a 2nd C3 register to seperate user from kernel space or do the permission check before prefetches. Like AMD does. On Linux this check would be cheap, on Windows NT not.
- DSMan195276 9y ago
  Anything is possible, but I would think that if it was fixable at that level we wouldn't have OS developers going through all of this trouble. There is basically no upside to this patch-set at all for the end-user except for increased security, and there's pretty big down-sides in the form of fairly significant speed losses. Keep in mind, this is more-or-less just the 4GB/4GB patch set that floated around awhile back for 32-bit systems, and that patch was never merged precisely because of the big performance impact it imposed - and that change actually had some merit, this one has none besides security. I don't think Linus would be letting this go through (And especially be on by default) without a fuss unless there is really no other way to mitigate a fairly big security hole. That's just my opinion, but it seems pretty clear to me. It's possible he has not spoken to anybody at Intel about this, but I would personally think he has some connections to get some info on it.
nothrabannosir 9y ago
> … a sales INCREASE … Don’t forget to correct for the subtle loss in credibility, and subsequent immeasurably subtle dip in sales, amortised over… forever.
ac29 9y ago
Until more information is available, who knows. It might be fixable in microcode, it might be fixable in a new processor stepping, it might require a deeper rework that wont come out until the next generation of processors (or even the generation after that).
- cjbprime 9y ago
  Though if it were going to be fixed in microcode, it seems like this would have played out by Intel just having released new microcode already and encouraged people to update to it, rather than every OS vendor scrambling to rewrite large chunks of their memory management, you know?
  - rurban 9y ago
    Yes, but they might have focused more on Windows, which is not so easy to fix. Esp in microcode. The NT kernel fixes were already out for months, there the table layout is not as simple as in Linux, whilst Linux is still discussing it. For Linux microcode you just need to look at the first bit for a permission check. Not so with Windows.

nine_k 9y ago

I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)

djsumdog 9y ago
For years, Intel and AMD processors have supported patching using microcode updates. Until we know the embargo is lifted and we know the full extent of this vulnerability, we won't know if that would be possible.
- nine_k 9y ago
  The fact that the firmware interface is strictly non-public also does not help predicting things.
- daenney 9y ago
  Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue a microcode update and the Linux kernel wouldn't be accepting this patch set as a mitigation for this issue (which is all this patch set is, it has no other benefit to the end user than fixing this bug).
  - zimmerfrei 9y ago
    It depends on how long it takes for Intel to go through all regression tests for all affected platforms. If it takes several months to complete, a countermeasure in the kernel update may still be the better stopgap. Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution for older generations.
    - dx034 9y ago
      They knew of the issue since June. Now that the patches are out it'll be hard to regain the performance. I doubt they are able to issue a microcode update within the following months. Otherwise large clients such as AWS would have implemented that instead.
  - rurban 9y ago
    I wouldn't be so sure about that. Linus and Gross might think that it could be microcode fixable, because they wanted it configurable. Opt-out. However in the current patchset it's mandatory. With a future os-specific microcode patch a config option would make more sense. They just need to find a 2nd C3 register to seperate user from kernel space or do the permission check before prefetches. Like AMD does. On Linux this check would be cheap, on Windows NT not.
DSMan195276 9y ago
Anything is possible, but I would think that if it was fixable at that level we wouldn't have OS developers going through all of this trouble. There is basically no upside to this patch-set at all for the end-user except for increased security, and there's pretty big down-sides in the form of fairly significant speed losses. Keep in mind, this is more-or-less just the 4GB/4GB patch set that floated around awhile back for 32-bit systems, and that patch was never merged precisely because of the big performance impact it imposed - and that change actually had some merit, this one has none besides security. I don't think Linus would be letting this go through (And especially be on by default) without a fuss unless there is really no other way to mitigate a fairly big security hole. That's just my opinion, but it seems pretty clear to me. It's possible he has not spoken to anybody at Intel about this, but I would personally think he has some connections to get some info on it.

nothrabannosir 9y ago

> … a sales INCREASE … Don’t forget to correct for the subtle loss in credibility, and subsequent immeasurably subtle dip in sales, amortised over… forever.

ac29 9y ago

Until more information is available, who knows. It might be fixable in microcode, it might be fixable in a new processor stepping, it might require a deeper rework that wont come out until the next generation of processors (or even the generation after that).

cjbprime 9y ago
Though if it were going to be fixed in microcode, it seems like this would have played out by Intel just having released new microcode already and encouraged people to update to it, rather than every OS vendor scrambling to rewrite large chunks of their memory management, you know?
- rurban 9y ago
  Yes, but they might have focused more on Windows, which is not so easy to fix. Esp in microcode. The NT kernel fixes were already out for months, there the table layout is not as simple as in Linux, whilst Linux is still discussing it. For Linux microcode you just need to look at the first bit for a permission check. Not so with Windows.