|
Craptacular! posted:Same thing with cloud providers and any other data-driven business where there's enough employees that you couldn't tell if someone in the hall works here everyday or is an NSA employee installing an exploit and giving the system's administrator a gag order under threat of treason and aiding terrorism. I mean I really have to point out that if you're actually this paranoid about this happening you should already assume AWS has installed the backdoors already without needing to patch the bios. There is no functional difference between your scenario and mine. Also traffic analysis (that does happen at all these places) will catch back doors. or are they gag ordered too? Sure, people will need to flash their bios. It's a vunerability. One that shouldn't have made a blip on anyone's radar except in this modern era of celebrity exploiting.
|
#
?
Mar 21, 2018 19:41
|
|
|
|
| # ? Apr 26, 2024 20:42 |
|
|
BangersInMyKnickers posted:The kind of changes in firmware these vulns allow shouldn't be permitted short of cracking the hardware open and attempting to re-flash by soldering on to the serial pins and even that should be protected by some mechanism. Requiring physical access to update the TPM is a decent idea, but IDK how that'd go over with anyone who runs a decent sized DC. These things are going to have issues because humans are dumb, so you have to be able to update them and a workflow of 'push BIOS update' is a lot cheaper than 'open every server, plug in a USB stick and wait' so I know which one will be more popular.
|
|
#
?
Mar 21, 2018 20:10
|
|
|
There's no problem with allowing software updates of TPM as long as you, y'know, actually check the signatures before you flash it. Otherwise, on top of the whole "trivial to backdoor" thing, you've just opened up another failure case where humans are dumb and now you have a processor that's permanently bricked because you've hosed up the processor's bootstrap code. edit: really this is an academic discussion anyway, because as long as the processor is physically capable of reflashing the PSP then if it's exploited it can do it, it's not sufficient to have things limited to an external source under normal operation because this isn't normal operation. To really make it secure the PSP would have to only be flashable from an external controller, which would add cost on every board for reduced functionality that nobody wants and some customers would actively dislike. You could build that functionality into the chipset... but oh wait that was broken too. Reactive countermeasures here won't help, there is really no problem with allowing the TPM to flash itself as long as it validates the signatures properly. That's the weakness here, not software BIOS flashing. Paul MaudDib fucked around with this message at 22:59 on Mar 21, 2018 |
|
#
?
Mar 21, 2018 20:14
|
|
|
Alpha Mayo posted:~~FOR IMMEDIATE RELEASE~~ shut up you colossal dipshit
|
|
#
?
Mar 21, 2018 22:47
|
|
|
mad about exploits
|
|
#
?
Mar 22, 2018 00:10
|
|
|
BangersInMyKnickers posted:shut up you colossal dipshit
|
|
#
?
Mar 22, 2018 09:09
|
|
|
i gave a crackhead the key to my house and they stole my TV. can't believe the lock on my door was exploited so bad
|
|
#
?
Mar 22, 2018 09:12
|
|
|
PC had a locked password protected BIOS with secure boot enabled. expoited the gently caress out of it and booted a linux liveCD anyway. Just used the 'password' to access the BIOS written on a sticky note nearby, then turned off secure boot  . BIOS vendors need to patch this massive vulnerabiltiy. cant believe how easy it was to run unsigned code when all i had was admin access at the metal.
|
|
#
?
Mar 22, 2018 09:21
|
|
|
lmao that there are still people doing the "root password lets you do root things!" after AMD confirmed that this is not intended behavior and will be patched out. Because AMD issues PSP patches for "root passwords letting you do root things", right? this one has been remarkable, you can literally click back through someone's history and see their claims of "fake news!" only a day or two before, and watch the abrupt turnaround to "real but not a big deal!", and then come down to earth with a "OK maybe a serious escalation exploit but CTS is pretty shady guys!" Paul MaudDib fucked around with this message at 09:31 on Mar 22, 2018 |
|
#
?
Mar 22, 2018 09:29
|
|
|
“When was the last time you saw a security advisory that was basically “if you replace the BIOS or the CPU microcode with an evil version, you might have a security problem”? Yeah,” he said in the same thread." -linus torvalds, a shameful man who doesn't "get" security
|
|
#
?
Mar 22, 2018 09:53
|
|
|
They're vulnerabilities and they need fixing but what is really funny are the idiots who act like this is almost on par with Meltdown/Spectre. "See, AMD has their huge crippling security issues too, nothing is secure, might as well keep your Intel things!" -a dumbass who keeps blowing everything out of proportion every time it gives him an opportunity to poo poo on AMD. And, oh yeah. STATE LEVEL ACTORS. orcane fucked around with this message at 10:12 on Mar 22, 2018 |
|
#
?
Mar 22, 2018 10:09
|
|
|
Alpha Mayo posted:“When was the last time you saw a security advisory that was basically “if you replace the BIOS or the CPU microcode with an evil version, you might have a security problem”? Yeah,” he said in the same thread." Now that I bother to look it up: November 2017. https://www.blackhat.com/docs/eu-17...t-Engine-wp.pdf Yeah, bypassing signature validation is actually considered an exploit. Again, lol if you think that's intended behavior, they sign it for a reason, dumbshit.
|
|
#
?
Mar 22, 2018 10:16
|
|
|
Lol. You are so loving retarded. You called this a "serious escalation exploit" when this involves no exploit allowing for escalation, considering root access at metal level is a prerequisite to even attempting it. You have no idea what you are talking about.. And your linked vulnerabilities were vulnerabilities because they worked in conjunction with vulnerabilities with AMT allowing for bypassing authorization. (USER WAS PUT ON PROBATION FOR THIS POST)
|
|
#
?
Mar 22, 2018 10:42
|
|
|
Bypassing authorization means unauthorized attackers had access, FYI. That is what is known as an "serious escalation vulnerability" you stupid man.
|
|
#
?
Mar 22, 2018 10:44
|
|
|
Paul MaudDib posted:Now that I bother to look it up: November 2017. Looks like you've caused a meltdown in this thread. Maybe he'll get so mad that his heart gives out, and then his spectre will haunt the thread forever.
|
|
#
?
Mar 22, 2018 11:41
|
|
|
Alpha Mayo posted:Lol. You are so loving retarded. You called this a "serious escalation exploit" when this involves no exploit allowing for escalation, considering root access at metal level is a prerequisite to even attempting it. chaining vulnerabilities exists, but context is key to defining the risk and there are very constrained privilege escalation issues mentioned. that the prereq is higher than a regular user doesn't stop these from being escalation issues to address
|
|
#
?
Mar 22, 2018 12:29
|
|
|
Do you guys freak the gently caress out like this every time an exploit on some vendor's product is found? actually I already know the answer, this isn't a question asked in good faith Point, laugh and AMD for loving up sig validation, patch in a few weeks. Make sure your siem is alarming on unplanned firmware updates.
|
|
#
?
Mar 22, 2018 12:35
|
|
|
And most importantly, continue to ridicule Intel for continuing to bungle Spectre patches while their PR handles the situation almost as poorly as TeamViewer  Then go buy Intel chips 
|
|
#
?
Mar 22, 2018 12:38
|
|
|
Measly Twerp posted:Looks like you've caused a meltdown in this thread. Maybe he'll get so mad that his heart gives out, and then his spectre will haunt the thread forever. 
|
|
#
?
Mar 22, 2018 14:20
|
|
|
'you have no idea what your talking about' shitposts the shitposter in between hilariously ignorant shitposts e: actually they're not that funny but whatever
|
|
#
?
Mar 22, 2018 14:43
|
|
|
... Did we conveniently forget that Chimera isn't even an AMD exploit? It's an ASMedia exploit, and is on Intel motherboards from the past 6 years.
|
|
#
?
Mar 22, 2018 15:09
|
|
|
PerrineClostermann posted:... Did we conveniently forget that Chimera isn't even an AMD exploit? It's an ASMedia exploit, and is on Intel motherboards from the past 6 years. Umm excuse me the website said "AMD VULNERABILITIES CATCHY NAMES, status: really loving bad*" so of course it's an AMD exploit. * please sell all your stocks
|
|
#
?
Mar 22, 2018 15:16
|
|
|
I'm still not concerned about the exploit that requires already having methods to completely pwn the machine. It's a neat exploit, and yes it lets you gently caress with the firmware, but it still requires you to find some way to be on the other side of the airtight hatchway. At that point you've already lost. This is just a deeper level of "you've lost".
|
|
#
?
Mar 22, 2018 21:25
|
|
|
Potato Salad posted:
And how exactly do you plan on interrogating hardware for firmware modifications when that in itself is a function of the firmware that has been tampered with?
|
|
#
?
Mar 22, 2018 22:46
|
|
|
BangersInMyKnickers posted:And how exactly do you plan on interrogating hardware for firmware modifications when that in itself is a function of the firmware that has been tampered with? Force install it, then reimage? There’s still a window (attacker could be interfering with firmware update), but smaller. The lack of 100% remediation other than hardware replacement is what I don’t like about this.
|
|
#
?
Mar 22, 2018 23:37
|
|
|
Aww man I thought something cool happened with all the unread posts. Lame.
|
|
#
?
Mar 23, 2018 00:06
|
|
|
So what about rumours of 8 core Intel desktop chips? Hope AMD has an answer to them beyond +200MHz in a year.
|
|
#
?
Mar 23, 2018 03:45
|
|
|
GRINDCORE MEGGIDO posted:So what about rumours of 8 core Intel desktop chips? Hope AMD has an answer to them beyond +200MHz in a year. Later this year, which means like 6 months for an answer from AMD if 7nm is on time.
|
|
#
?
Mar 23, 2018 04:08
|
|
|
FaustianQ posted:Later this year, which means like 6 months for an answer from AMD if 7nm is on time. I just really hope they have something big planned, or it's not going to be pretty at all.
|
|
#
?
Mar 23, 2018 04:56
|
|
|
GRINDCORE MEGGIDO posted:I just really hope they have something big planned, or it's not going to be pretty at all. 7nm will put AMD at a node advantage. Even with no other changes, they probably close up their clock-speed disadvantage and are pulling significantly less power, plus they will probably also change to a 6-core or 8-core CCX. Really, unless Intel has something big planned, they're the ones it's not going to be pretty for. They have really, really screwed the pooch on 10nm and they are out of time. They desperately need a post-Skylake uarch, whether that's moving to a CCX layout or if they can pull another rabbit out of the hat on IPC/clocks. Bigger dies aren't going to work forever and will be especially problematic on 10nm. Paul MaudDib fucked around with this message at 05:33 on Mar 23, 2018 |
|
#
?
Mar 23, 2018 05:29
|
|
|
I'm not so sure, I mean on raw performance yes, but then Intel intends on releasing the Z390 boards which are going to be required for the 8C Coffeelakes, so anyone who's already invested in Coffeelake won't switch over and it's going to be a large enough expenditure that unless you're die hard Intel, you'll wait to see what Zen2 is like. Maybe Intel intends to just use Z390 to phase in Icelake as well? So you can flash a Z390 to be compatible, while they release H410, H460, H470 and Z490 to be compatible from the start?
|
|
#
?
Mar 23, 2018 05:32
|
|
|
FaustianQ posted:I'm not so sure, I mean on raw performance yes, but then Intel intends on releasing the Z390 boards which are going to be required for the 8C Coffeelakes, so anyone who's already invested in Coffeelake won't switch over and it's going to be a large enough expenditure that unless you're die hard Intel, you'll wait to see what Zen2 is like. Maybe Intel intends to just use Z390 to phase in Icelake as well? So you can flash a Z390 to be compatible, while they release H410, H460, H470 and Z490 to be compatible from the start? The leaked roadmaps don't show Cascade Lake on the client platform at all. They show it as "Purley Refresh", i.e. HEDT and -SP lineup.
|
|
#
?
Mar 23, 2018 05:35
|
|
|
Paul MaudDib posted:The leaked roadmaps don't show Cascade Lake on the client platform at all. They show it as "Purley Refresh", i.e. HEDT and -SP lineup. Not talking about Cascade Lake, talking about the rumored 8 core Coffee Lakes https://www.techradar.com/news/intel-coffee-lake-s-8-core-processors-will-land-later-this-year-3dmark-leak-teases
|
|
#
?
Mar 23, 2018 05:41
|
|
|
FaustianQ posted:Not talking about Cascade Lake, talking about the rumored 8 core Coffee Lakes https://www.techradar.com/news/intel-coffee-lake-s-8-core-processors-will-land-later-this-year-3dmark-leak-teases Oh, I hadn't heard about a Coffee Lake refresh then. Well, back when everyone was whining about Z370, one train of thought was that crappy Z170/270 boards might be marginal for 6-core but that Intel might drop 8-cores at some point, and they wanted to set up that move. On the other hand, Intel is being super dickish about chipset compatibility in general, so who knows, but with a resurgent AMD they may be forced to be a little nicer to their customers. There's lots of ways this could play out. It still doesn't change the fundamental balance of power here though. In 2019 they are probably going to be going up against 12-core 7nm Ryzen (a true second-gen architecture, not just a stepping) that clocks as high as theirs do. They have dead-ended themselves into extreme clockrates that 10nm can't deliver, they have dead-ended themselves into low-yielding monolithic chips that 10nm can't deliver, and they have dead-ended themselves into an architecture that is tapped out at this point and will probably involve short-term performance losses until stuff gets re-optimized. And they don't even have a functional 10nm process at this point. Coffee Lake isn't the killing blow here, it's the last gasp of the big monolithic 14nm Sandy Bridge-sequence chips. If Intel is going to remain competitive, at least one of those things is going to have to change. Otherwise, AMD takes the performance crown in 2019, not just value or in MT performance but across the board. In fact, at this point that's probably almost inevitable in the short term, even if they do change course. It's a loving mystery how Brian Krzanich still has a job, letting GF skip right over them and take a node advantage is straight-up incompetence and now they're going to have to do something drastic to catch up. If they had a working 10nm node they could have had a little more breathing room, but at this rate they've got a year until AMD is on top. They either need to get their 10nm working, or to start begging GF to let them use 7nm. Paul MaudDib fucked around with this message at 06:20 on Mar 23, 2018 |
|
#
?
Mar 23, 2018 05:56
|
|
|
I feel like to really make progress at this time, AMD and Intel both need to work with software companies and specifically Microsoft so they can drop older instruction sets for better ones and regain die space and performance. Can't we just collapse MMX and SSE into a single unified SIMD extension and just emulate the bits still necessary until we migrate?
|
|
#
?
Mar 23, 2018 06:02
|
|
|
There were some rumors a while back that Intel's new upcoming uarch (meant for 2020 or whatever) was essentially going to be attempting to get at least some of its performance improvements by simplifying the hardware by stripping out hardware support for older and now less used portions of the x86 ISA. Exactly what that would mean (so would anything that was "old" (and what exactly would be considered "old" anyways? pre-IA32?? pre-x86-64???) now just be ran as slow microcode as needed?) and what sort of performance improvement it'd give you I couldn't really say. Personally I don't think replacing MMX or SSE is going to get anyone much of anything like a improvement. Those older vector processing ISA's have largely been supplanted by SSE2-onwards and are pretty much legacy at this point already. From what (little) I understand dumping or greatly reducing hardware support for the x87 FPU and essentially emulating it via microcode on the CPU through the vector math FPU would probably be of bigger benefit than trying to do some sort of industry standard vector math ISA. Especially since SSE2+ is already the de facto standard.
|
|
#
?
Mar 23, 2018 06:20
|
|
|
FaustianQ posted:I feel like to really make progress at this time, AMD and Intel both need to work with software companies and specifically Microsoft so they can drop older instruction sets for better ones and regain die space and performance. Can't we just collapse MMX and SSE into a single unified SIMD extension and just emulate the bits still necessary until we migrate? You just tell the OS "lolno, I don't have MMX or SSE 1/2, you want these shiny new AVX functions, right?" Though who knows how much legacy crap has MMX optimizations only, or how much die space on the decode that would actually save.
|
|
#
?
Mar 23, 2018 06:30
|
|
|
Methylethylaldehyde posted:You just tell the OS "lolno, I don't have MMX or SSE 1/2, you want these shiny new AVX functions, right?" Though who knows how much legacy crap has MMX optimizations only, or how much die space on the decode that would actually save. The problem is the stuff that doesn't have fallbacks. There are games that won't run unless you have SSE2 or whatever, and having AVX isn't going to help you if the game doesn't understand that. Maybe that's an acceptable casualty if there's big gains, but I kinda doubt it.
|
|
#
?
Mar 23, 2018 06:54
|
|
|
...Aren't most instructions broken down into common micro-ops anyway? Would you really save that much silicon by dropping old instruction sets?
|
|
#
?
Mar 23, 2018 07:02
|
|
|
|
| # ? Apr 26, 2024 20:42 |
|
|
Yeah, you wouldn't save anything. You wouldn't even free up any pipelines by dropping MMX, since it shares a pipeline and register file with the x87 FPU.
|
|
#
?
Mar 23, 2018 07:04
|
|