|
Have any mobo manufacturers gone the extra mile in patching in support for older models? I was going to upgrade to ASUS next time, but if ASRock have done a better job of this, I may just go with them in the future.
|
#
?
Jan 10, 2018 12:40
|
|
|
|
| # ? Apr 29, 2024 09:00 |
|
|
ufarn posted:Have any mobo manufacturers gone the extra mile in patching in support for older models? I was going to upgrade to ASUS next time, but if ASRock have done a better job of this, I may just go with them in the future. ASUS will patch back to Skylake or Broadwell, I forgot. ASRock has no comment. MSI made a vague statement that said "Older chipsets may need more time to wait, as it's up to Intel to release required resources. No ETA given." No one wants to make promises because they need Intel to make code and code is only available as far back as Haswell for now. It should be noted it's not really clear if you self-built your computer whether or not your motherboard manufacturer actually needs to do anything, or if Intel will simply be releasing tools themselves. They're not eager to begin committing to putting out fires until Intel tells them whether or not they have to, but Intel is going to want pre-built partners like HP, Dell, etc to distribute the patch through their points of customer contact because a generic Intel alert won't get grandma's attention quite like "Hello CYNTHIA, we here at Dell ask if you could point your INSPIRON 6120 to our site at..." As a pretty big laptop manufacturer, it may simply be that Asus is jumping to the call sooner than everyone else because, whether Intel handles it for self-built or not, they're going to be asked to do something.
|
|
#
?
Jan 10, 2018 13:26
|
|
|
So I'm asking more out of curiosity than fear, but I have a bunch of friends/family that are running Xeon chips on ye olde core2duo boards (asus p5q and the like). I thought I'd head someone mention Xeon earlier, just wondering if they're more at risk or anything? Also I realise it's very unlikely that any of these old boards will get a bios or microcode update however since getting these old Xeon to run in there boards requires editing the microcode of the bios to include the Xeon chips, I'm assuming *if* these old boards were to get a patch it would make all these old Xeon units unusable till I edited the new bios, correct?
|
|
#
?
Jan 10, 2018 13:31
|
|
|
Craptacular! posted:ASUS will patch back to Skylake. ASRock has no comment. MSI made a vague statement that said "Older chipsets may need more time to wait, as it's up to Intel to release required resources. No ETA given." Dell isn't going very far back at all. You can check out what they will patch (and what they won't) here: http://www.dell.com/support/meltdown-spectre Captain Hair posted:So I'm asking more out of curiosity than fear, but I have a bunch of friends/family that are running Xeon chips on ye olde core2duo boards (asus p5q and the like). If you edited the BIOS to include actual microcode, and not just the basic CPU ID support, you could edit the BIOS again with the updated microcode and flash it yourself. This depends on Intel producing a microcode update for a CPU that old and it being available publicly in a format you can incorporate into whatever BIOS you have available. EoRaptor fucked around with this message at 13:36 on Jan 10, 2018 |
|
#
?
Jan 10, 2018 13:31
|
|
|
Intel's CEO has promised patches for all processors introduced in the past five years to be released till the end of January. This means anything pre-Haswell is out.
Fame Douglas fucked around with this message at 13:34 on Jan 10, 2018 |
|
#
?
Jan 10, 2018 13:32
|
|
|
EoRaptor posted:
Ah cool, thanks for the informative answer  I'm pretty sure it only required editing the CPU ID table, so it probably wouldn't change anything anyway even if there was a patch for it. Was just curious really.
|
|
#
?
Jan 10, 2018 13:43
|
|
|
How long will it take for hardware-level fixes to come to market in the desktop CPUs themselves? Is Ice Lake likely to be the first architecture not to be vulnerable to Meltdown and Spectre?
|
|
#
?
Jan 10, 2018 13:43
|
|
|
How can they make a spectre proof hardware design?
|
|
#
?
Jan 10, 2018 14:00
|
|
|
GRINDCORE MEGGIDO posted:How can they make a spectre proof hardware design? It might require coordinated software support but I think you could do it with extra hardware checks, similar to how AMD chips aren't affected by Meltdown.
|
|
#
?
Jan 10, 2018 14:34
|
|
|
GRINDCORE MEGGIDO posted:How can they make a spectre proof hardware design? Hash the BTB. On protection level modification, change the hash algorithm randomly. Maybe. e: was thinking about a different thingy. (The BTB attacks on trustzone from C3) karoshi fucked around with this message at 21:14 on Jan 10, 2018 |
|
#
?
Jan 10, 2018 14:56
|
|
|
How dangerous is Spectre? I have hardware that will almost certainly never receive microcode updates. How much should I worry about running JavaScript with it? Also, aren't ARM processors affected by Spectre too? Or did I imagine that? Any word on the Android situation?
|
|
#
?
Jan 10, 2018 20:52
|
|
|
Raspberry Jam It In Me posted:How dangerous is Spectre? I have hardware that will almost certainly never receive microcode updates. How much should I worry about running JavaScript with it? Android is insecure by design.
|
|
#
?
Jan 10, 2018 20:54
|
|
|
Raspberry Jam It In Me posted:How dangerous is Spectre? I have hardware that will almost certainly never receive microcode updates. How much should I worry about running JavaScript with it? Spectre allows reading of private data in a process that something like javascript shouldn't be able to touch. Browser developers are mitigating it by doing per-process isolation for each tab to isolate which increases memory overhead but works. Spectre is considerably lower-risk for normal day to day usage compared to Meltdown but you're playing wack-a-mole trying to keep each individual program from being vulnerable to it.
|
|
#
?
Jan 10, 2018 21:01
|
|
|
GRINDCORE MEGGIDO posted:How can they make a spectre proof hardware design? Physically split the TLB cache in two, with one that can be used as current, and the other that is a shadow of the current that can only be used by the CPU when it is speculating. The shadow cannot be read or written by any normal process, and only gets pushed up to the main cache if speculation succeeds. Take advantage of transactional memory support keep overhead low.
|
|
#
?
Jan 10, 2018 21:14
|
|
|
EoRaptor posted:The shadow cannot be read or written by any normal process, and only gets pushed up to the main cache if speculation succeeds. This is an especially expensive approach, silicon-wise, but a ton of approaches exist striking different trade-offs. This is certainly a solvable problem. All they have to do is make sure that cache cannot be used as a side-channel from a speculative execution.
|
|
#
?
Jan 10, 2018 21:23
|
|
|
BangersInMyKnickers posted:Spectre allows reading of private data in a process that something like javascript shouldn't be able to touch. Browser developers are mitigating it by doing per-process isolation for each tab to isolate which increases memory overhead but works. Spectre is considerably lower-risk for normal day to day usage compared to Meltdown but you're playing wack-a-mole trying to keep each individual program from being vulnerable to it. So, you are saying that there is zero risk from browsing alone, as long as I use an up to date browser?
|
|
#
?
Jan 10, 2018 21:23
|
|
|
There's always risk. Your system is always vulnerable to hacks and exploits. This is just one more. If you are this worried, you shouldn't have any personal information on your computer ever, patched or not.
|
|
#
?
Jan 10, 2018 21:26
|
|
|
Yeah nobody can promise you zero risk. What we can say is that the patches which have been released mitigate the known exploits, so you should patch and move on with your life just like with most every announced exploit.
|
|
#
?
Jan 10, 2018 21:27
|
|
|
No one is trying to steal your muffin recipe, nana
|
|
#
?
Jan 10, 2018 21:52
|
|
|
They are trying to steal her social security checks though
|
|
#
?
Jan 10, 2018 22:03
|
|
|
Lockback posted:No one is trying to steal your muffin recipe, nana I keep my serial murder plans and trophies on that computer, this is serious business. In many parts of the world you can go to prison for a single murder alone. But seriously, thanks for the answers. Glad I can forget about this poo poo for now.
|
|
#
?
Jan 10, 2018 22:22
|
|
|
Raspberry Pis aren't vulnerable. Checkmate, Intailures.
|
|
#
?
Jan 10, 2018 22:24
|
|
|
Release dates are out for HP BIOS updates. Mid-february 
|
|
#
?
Jan 10, 2018 23:41
|
|
|
Kerbtree posted:Release dates are out for HP BIOS updates. The listing of ENVY h8-XXXX desktops is possibly good news for self-built Ivy owners, since that would presumably include the ENVY h8-1455 which shipped with a 3770K. Until this it seems that Intel was content to give us the "EOL, get bent" reaction.
|
|
#
?
Jan 10, 2018 23:52
|
|
|
Rexxed posted:Raspberry Pis aren't vulnerable. Checkmate, Intailures. OK but what about the regular SNES Classics?
|
|
#
?
Jan 10, 2018 23:55
|
|
|
canyoneer posted:OK but what about the regular SNES Classics? https://www.youtube.com/watch?v=xmTn5bVaOH4
|
|
#
?
Jan 11, 2018 02:58
|
|
|
Henrik Zetterberg posted:BIOS/microcode patch I thought it was a microcode update and the mobo vendor would not be needed for it to update. Kinda like how Intel makes drivers for their onboard nics.
|
|
#
?
Jan 11, 2018 07:17
|
|
|
canyoneer posted:OK but what about the regular SNES Classics? https://www.youtube.com/watch?v=OPcV9uIY5i4 You can execute arbitrary code in Super Mario World.
|
|
#
?
Jan 11, 2018 11:10
|
|
|
Mr Shiny Pants posted:I thought it was a microcode update and the mobo vendor would not be needed for it to update. Kinda like how Intel makes drivers for their onboard nics. The Microcode is saved on the BIOS chip and loaded into the CPU at startup.
|
|
#
?
Jan 11, 2018 11:31
|
|
|
Fame Douglas posted:The Microcode is saved on the BIOS chip and loaded into the CPU at startup. Ah, I see. That makes sense. I thought it was like flashing your CPU.
|
|
#
?
Jan 11, 2018 13:08
|
|
|
The os can also update the microcode each time it boots, though.
|
|
#
?
Jan 11, 2018 15:20
|
|
|
mystes posted:The os can also update the microcode each time it boots, though.
|
|
#
?
Jan 11, 2018 16:22
|
|
|
mystes posted:The os can also update the microcode each time it boots, though. yeah thats what i want from windows, the os that cant even patch itself without loving something up half the time
|
|
#
?
Jan 11, 2018 16:41
|
|
|
Because updating a system with tons of files live and sending a signed closed microcode package to the CPU via specific means, both that Intel supplied, is so much of the same.
|
|
#
?
Jan 11, 2018 16:44
|
|
|
Combat Pretzel posted:Yea, we should keep repeating this one, so that it gets ignored some more. Why would we repeat this as long as we don't know whether Microsoft will even release a microcode update? So far, the only fix is a Bios update. That's what we should repeat, not the hope for a better future that may or may not come. Combat Pretzel posted:Because updating a system with tons of files live and sending a signed closed microcode package to the CPU via specific means, both that Intel supplied, is so much of the same. lol if you think there aren't tons of weird edge-cases and incompatibilities with patching the microcode through the OS. https://wiki.debian.org/Microcode#Updating_CPU_microcode_within_Debian_.28Intel_or_AMD.29 Fame Douglas fucked around with this message at 16:54 on Jan 11, 2018 |
|
#
?
Jan 11, 2018 16:51
|
|
|
Fame Douglas posted:Why would we repeat this as long as we don't know whether Microsoft will even release a microcode update? Because the vast majority of motherboards will never get a BIOS update at all, and both Intel and Microsoft have stated that this is going to be the way forward for most systems with "older" (more than 2 years) motherboards as a result.
|
|
#
?
Jan 11, 2018 17:01
|
|
|
Fame Douglas posted:Why would we repeat this as long as we don't know whether Microsoft will even release a microcode update? So far, the only fix is a Bios update. That's what we should repeat, not the hope for a better future that may or may not come. 99% of consumers will never update their BIOS.
|
|
#
?
Jan 11, 2018 17:08
|
|
|
I'm actually kinda surprised how everyone kinda drags their feet on the updates, especially considering how long this has apparently been known. It is true though, every OS can do microcode updates and these updates are only valid until your computer is rebooted, where they will have to be loaded into the CPU again. The BIOS/Firmware can do that, or the OS. Haswell/early Broadwell for example got microcode updates before to deal with CPU (in)stability (google TXS extensions which had to be disabled via microcode) my AMD APU I'm typing this on had a pretty serious security flaw which also got patched via microcode a year or so ago. This stuff happens all the time. Modern CPUs are complicated beasts. A BIOS update isn't necessary if the OS provides the microcode update. There is absolutely no downside to have the OS providing it.
|
|
#
?
Jan 11, 2018 17:13
|
|
|
DigitalFoundry has a video on gaming performance after these patches: Seems pretty noticeable at times, especially with games like The Witcher 3. https://www.youtube.com/watch?v=LC1WuKdPVCQ Intel has some PR benchmarks up as well that show a decrease in performance of around 5-10% for office workloads: https://newsroom.intel.com/editorials/intel-security-issue-update-initial-performance-data-results-client-systems/ Fame Douglas fucked around with this message at 17:40 on Jan 11, 2018 |
|
#
?
Jan 11, 2018 17:37
|
|
|
|
| # ? Apr 29, 2024 09:00 |
|
|
Fame Douglas posted:lol if you think there aren't tons of weird edge-cases and incompatibilities with patching the microcode through the OS. https://wiki.debian.org/Microcode#Updating_CPU_microcode_within_Debian_.28Intel_or_AMD.29 I'm not sure why you think that link proves that. BIOS or OS, each will be doing exactly the same thing to update the microcode. There's nothing magic the BIOS does and the OS doesn't to make that happen, it just does it earlier.
|
|
#
?
Jan 11, 2018 17:40
|
|
