If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Concesus of AMD PSP security issue?
There's been a lot of talk lately about CPU vulnerabilities ala Meltown but what is the general consensus with the obvious built in back doors being put into CPU's at the OEM level. AMD Platform Security Processor/Trust Zone Secure Technology which is AMD's version of Intel AMT/Intel Management Engine/vPro The processor within a processor with it's own unknown closed source OS that has access to literally all functions of the system. I don't think AMD currently has an equivalent to Intels vPro which is the 3G chips in the CPU that can receive secret forced updates, access to the TCP/IP stack even before the OS is booted, etc... In any case there was a lot of talk surrounding this as this is ripe for potential exploits/vulnerabilities/back doors and there's almost nothing we can do to prevent them/stop them nor do we even really understand the full ramifications. I recall seeing some attempts at getting AMD to release the code open source, there was various petitions, etc, and then everything died out. So what's been the consensus on this issue? Has there been any advancements in getting the code open sourced or at the very least being able to disable it? I gather I heard a few mobo makers added the option to disable AMD PSP in BIOS updates, I don't think it's come to mine yet nor does it seem to be something widespread. |
#2
|
|||
|
|||
Concesus of AMD PSP security issue?
xJumper wrote:
There's been a lot of talk lately about CPU vulnerabilities ala Meltown but what is the general consensus with the obvious built in back doors being put into CPU's at the OEM level. AMD Platform Security Processor/Trust Zone Secure Technology which is AMD's version of Intel AMT/Intel Management Engine/vPro The processor within a processor with it's own unknown closed source OS that has access to literally all functions of the system. I don't think AMD currently has an equivalent to Intels vPro which is the 3G chips in the CPU that can receive secret forced updates, access to the TCP/IP stack even before the OS is booted, etc... In any case there was a lot of talk surrounding this as this is ripe for potential exploits/vulnerabilities/back doors and there's almost nothing we can do to prevent them/stop them nor do we even really understand the full ramifications. I recall seeing some attempts at getting AMD to release the code open source, there was various petitions, etc, and then everything died out. So what's been the consensus on this issue? Has there been any advancements in getting the code open sourced or at the very least being able to disable it? I gather I heard a few mobo makers added the option to disable AMD PSP in BIOS updates, I don't think it's come to mine yet nor does it seem to be something widespread. The second half of this page has an answer. https://security.stackexchange.com/q...cure-processor The purpose of the two implementations is different. The Intel VPro setup, the NIC chip has to be an Intel chip, and those are "split-in-half" NICs. They have a section for the ME to do communications, and a section for the main CPU to use. The AMD implementation doesn't have special hardware paths, and is more of a dis-embodied processing core inside the CPU. And like the Intel implementation, has some means of loading a signed code module as part of the BIOS image. The AMD implementation still has full access to resources in the computer, but it can't really use them smoothly, without upsetting the OS state that also uses the resources. ******* As for this notion of "back doors in firmware", you're missing a giant one. The SMM (System Management Mode) allows time-sliced BIOS operation, while the OS is running. And the OS has *no* resources to tell it's been swapped out. (You can only tell indirectly by "missing" time when time-keeping.) If someone wanted to bug your machine, all they'd need to do is load a special firmware, and you'd never know it was running. It wouldn't need to leave any tracks. It would be like a hardware rootkit. But nobody worries about that. I don't think, at least for 5+ year older machines, there's any signing requirement for such firmwares. So if someone could gain physical access to your machine, they wouldn't need to put a bug into your OS (where your AV could detect it), they could just do something to gain access via SMM. Intel did add something (which may actually be switched on with business class computers), where the BIOS signing is checked at POST time. And this prevents easy insertion of bogus firmware serial EEPROMs. The OEM designing the motherboard, has to make sure this is working right before shipping. This feature would, say, prevent a computer from being switched to CoreBoot. ******* I would agree with a need for paranoia concerning the Intel ME. That scares the crap out of me, because all the hardware paths are there to "make trouble". The AMD one, just doesn't seem to have the same level of exposure. They could probably exploit it, but you might notice something at OS level if they did. AMD may try to make a remote management solution out of it some day, so the possibility remains. At least AMD has potentially put a disable feature in AGESA for it, but Intel, I don't think I've seen them just flat out offer an OFF switch for theirs. They offer some shabby workarounds that still don't satisfy me. Paul |
#3
|
|||
|
|||
Concesus of AMD PSP security issue?
On Wed, 6 Jun 2018 00:55:00 -0400, xJumper
wrote: There's been a lot of talk lately about CPU vulnerabilities ala Meltown but what is the general consensus with the obvious built in back doors being put into CPU's at the OEM level. AMD Platform Security Processor/Trust Zone Secure Technology which is AMD's version of Intel AMT/Intel Management Engine/vPro The processor within a processor with it's own unknown closed source OS that has access to literally all functions of the system. I don't think AMD currently has an equivalent to Intels vPro which is the 3G chips in the CPU that can receive secret forced updates, access to the TCP/IP stack even before the OS is booted, etc... In any case there was a lot of talk surrounding this as this is ripe for potential exploits/vulnerabilities/back doors and there's almost nothing we can do to prevent them/stop them nor do we even really understand the full ramifications. I recall seeing some attempts at getting AMD to release the code open source, there was various petitions, etc, and then everything died out. So what's been the consensus on this issue? Has there been any advancements in getting the code open sourced or at the very least being able to disable it? I gather I heard a few mobo makers added the option to disable AMD PSP in BIOS updates, I don't think it's come to mine yet nor does it seem to be something widespread. Cache coherence, both across and between individual cores, is the protocol given Spectre/Meltdown[PrimeVariants], which by intent is to modify speculative execution, through an artificially induced buffer of shared instances, otherwise limited to an invalidity factor, that software traditionally would not address. And so it appears that Princeton university computer research facilities, along with Nvidia, subsequently have examined industry microprocessor implementation of cache reserves directly for and in further light of addressing its implementation. We have developed a tool for automatically synthesizing microarchitecture-aware assembly language programs given two inputs: (i) a formal description of a microarchitecture in a domain-specific language [...], and (ii) a formal description of a microarchitectural execution pattern of interest. This tool is consequently capable of synthesizing implementation-aware programs that can induce any user-specified threat pattern representative of a class of security exploits. https://www.tomshardware.com/news/ne...red,36533.html About time. It's been awhile since I bought one MEG of ram in 128K banks of 9-chipped "critters" to an array. I recall paying $300/US. Extra memory of course, along with a couple early EMS(2.0) expansion boards, for caching on varied programs and applicable focus, efficiency and speed. At some later point, I forget when, memory eventually became relatively as cheap as dirt. Looks like someone decided to speculatively expand upon a similar precept and into the a principle reserve left to computer design. At least since running into a brick-wall a decade ago, the hard physics and a pathway constraint pragmatically limited to such as processing cores, mine, each are throttled to a present maximum capacity of about 4GHz. Nor further across AMD's Bulldozer speculative cache implementation for eight cores, as the inroads, possibly excepting an hint of a few games, are not, really, of a speculative nature to programming multiples of core arrays in a predicative sense of syllogistic cybernetics. But then Intel has overall invalidated AMD, perhaps less so from a Ryzen platform, for cache-coherency protocols. |
#4
|
|||
|
|||
Concesus of AMD PSP security issue?
The AMD implementation still has full access to resources
in the computer, but it can't really use them smoothly, without upsetting the OS state that also uses the resources. As for this notion of "back doors in firmware", you're missing a giant one. The SMM (System Management Mode) allows time-sliced BIOS operation, while the OS is running. And the OS has *no* resources to tell it's been swapped out. (You can only tell indirectly by "missing" time when time-keeping.) If someone wanted to bug your machine, all they'd need to do is load a special firmware, and you'd never know it was running. It wouldn't need to leave any tracks. It would be like a hardware rootkit. Paul, This is your coolest posting so far ! In 2012 I invented an application which can visualize time slices. (I invented it to get an idea of the effect multi threading/time slices have an audio buffers/asio, too much time slicing can cause pops/noises when processing audio in real time) It draws a box of something like 200 by 200 pixels. Fills the pixels according to time passed. Red if pixel was hit once/little processing, green if pixel had more processing. Black if no processing. Green indicates basically the thread had full time slice available to color that/those pixels. What red means I am not sure.... it probably had little time, could be start or end of a time slice. Black is definetly an indication that something else interrupted the time slice. As far as I know this application is unique in the world. Quickly googled "visualizing time slices" turned up nothing. The application is quite easy to code but I guess the idea is genius like yours. I did not realize this app could be used to spy on spyware in firmware. Indeed if firmware uses the processor/cpu to interrupt the OS/threads than it can be visualized. But only if the timer/high performance timer is true/genuine. If time were frozen then nothing would be visible. Though something would eventually show up. Also if spyware is executed by an external cpu/dedicated cpu then nothing will show up. So far this test app of mine version 0.01 only spawns one thread. The application could be started multiple times though and made to run dedicated per core. Somebody could patent it though.... though hopefully this description will be enough to avoid that. Maybe I should not be sharing it... but you kinda had the same idea already but very vaguely. I take it you are not a programmer. But I will try and help you anyway. There is a problem though. www.mijndomein.nl seems completely ****ed up. ^ My webhoster. They changed their ftp... and now I upload my files and they are not showing up on the web... perhaps this is because of no EU rules... or they screwed up... Perhaps it takes a while for these files to show up. Anyway wanted to share it with you... so you have at least 1 tool to keep an eye on cores to see if you spot anything weird going on ! Might be nice ! Hereby I also thank you for your insight/realization into this idea of using time to detect spyware (stealing cpu time) ! Pretty cool ! The app is supposed to be he http://www.skybuck.org/Applications/TimeSliceVisualizer But somehow it's not showing up. Perhaps check back later ! To bad I can't share it with you currently, that sucks. I will make a new posting if this ftp/www starts working again. Perhaps in future I or you will think about it some more how an even more ingenius app can be created which for example fully uses all cores to fill pixels as an ultimate attempt to detect any time stealing. However perhaps a tiny little 200 by 200 is better in case spyware only activates if processor is little utilized So perhaps the 200 by 200 is even better Bye for now, Skybuck. |
#5
|
|||
|
|||
Concesus of AMD PSP security issue?
On Wednesday, June 6, 2018 at 8:00:19 PM UTC+2, Flasherly wrote:
On Wed, 6 Jun 2018 00:55:00 -0400, xJumper wrote: There's been a lot of talk lately about CPU vulnerabilities ala Meltown but what is the general consensus with the obvious built in back doors being put into CPU's at the OEM level. AMD Platform Security Processor/Trust Zone Secure Technology which is AMD's version of Intel AMT/Intel Management Engine/vPro The processor within a processor with it's own unknown closed source OS that has access to literally all functions of the system. I don't think AMD currently has an equivalent to Intels vPro which is the 3G chips in the CPU that can receive secret forced updates, access to the TCP/IP stack even before the OS is booted, etc... In any case there was a lot of talk surrounding this as this is ripe for potential exploits/vulnerabilities/back doors and there's almost nothing we can do to prevent them/stop them nor do we even really understand the full ramifications. I recall seeing some attempts at getting AMD to release the code open source, there was various petitions, etc, and then everything died out. So what's been the consensus on this issue? Has there been any advancements in getting the code open sourced or at the very least being able to disable it? I gather I heard a few mobo makers added the option to disable AMD PSP in BIOS updates, I don't think it's come to mine yet nor does it seem to be something widespread. Cache coherence, both across and between individual cores, is the protocol given Spectre/Meltdown[PrimeVariants], which by intent is to modify speculative execution, through an artificially induced buffer of shared instances, otherwise limited to an invalidity factor, that software traditionally would not address. And so it appears that Princeton university computer research facilities, along with Nvidia, subsequently have examined industry microprocessor implementation of cache reserves directly for and in further light of addressing its implementation. We have developed a tool for automatically synthesizing microarchitecture-aware assembly language programs given two inputs: (i) a formal description of a microarchitecture in a domain-specific language [...], and (ii) a formal description of a microarchitectural execution pattern of interest. This tool is consequently capable of synthesizing implementation-aware programs that can induce any user-specified threat pattern representative of a class of security exploits. https://www.tomshardware.com/news/ne...red,36533.html About time. It's been awhile since I bought one MEG of ram in 128K banks of 9-chipped "critters" to an array. I recall paying $300/US. Extra memory of course, along with a couple early EMS(2.0) expansion boards, for caching on varied programs and applicable focus, efficiency and speed. At some later point, I forget when, memory eventually became relatively as cheap as dirt. Looks like someone decided to speculatively expand upon a similar precept and into the a principle reserve left to computer design. At least since running into a brick-wall a decade ago, the hard physics and a pathway constraint pragmatically limited to such as processing cores, mine, each are throttled to a present maximum capacity of about 4GHz. Nor further across AMD's Bulldozer speculative cache implementation for eight cores, as the inroads, possibly excepting an hint of a few games, are not, really, of a speculative nature to programming multiples of core arrays in a predicative sense of syllogistic cybernetics. But then Intel has overall invalidated AMD, perhaps less so from a Ryzen platform, for cache-coherency protocols. Has very little to do with this thread's discussion, except for reference to cache exploits/timing exploits. Was this text generated by a bot ? Seems like it ! Bye, Skybuck |
#6
|
|||
|
|||
Concesus of AMD PSP security issue?
|
#8
|
|||
|
|||
Concesus of AMD PSP security issue?
On Fri, 08 Jun 2018 14:16:23 -0400, Paul
wrote: It would be unacceptable to use a system with "red spikes" as an audio recording workstation (as it can screw up sound). They do bill themselves as acceptable, and whenever possible -- as there are soundcards and then there are other soundcards (and their drivers). " Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs. " https://www.thesycon.de/eng/latency_check.shtml I switched recently to supposed 3rd-party drivers for a popular soundboard - one, a low-latency mode, which eliminated the software control interface for various driver-to-hardware functions and switches;- basically looks like a set and forget any polling scenario, for a much lower latency module option for subsequent smaller buffer settings than I'd used prior. So far. For recording purposes, forget all that. I wouldn't trust common computer gear at that level. I've used specialty recording equipment, (mixer to USB preprocessing module), in a no-latency computer multitracking and dubover environ. The quality possible became immediately apparent, easily attainable and increasingly respectable. Specialty recording gear that came with some added cost for specifically addressing DPC issues. |
#9
|
|||
|
|||
Concesus of AMD PSP security issue?
On Friday, June 8, 2018 at 8:16:28 PM UTC+2, Paul wrote:
wrote: The AMD implementation still has full access to resources in the computer, but it can't really use them smoothly, without upsetting the OS state that also uses the resources. As for this notion of "back doors in firmware", you're missing a giant one. The SMM (System Management Mode) allows time-sliced BIOS operation, while the OS is running. And the OS has *no* resources to tell it's been swapped out. (You can only tell indirectly by "missing" time when time-keeping.) If someone wanted to bug your machine, all they'd need to do is load a special firmware, and you'd never know it was running. It wouldn't need to leave any tracks. It would be like a hardware rootkit. Paul, This is your coolest posting so far ! In 2012 I invented an application which can visualize time slices. (I invented it to get an idea of the effect multi threading/time slices have an audio buffers/asio, too much time slicing can cause pops/noises when processing audio in real time) It draws a box of something like 200 by 200 pixels. Fills the pixels according to time passed. Red if pixel was hit once/little processing, green if pixel had more processing. Black if no processing. Green indicates basically the thread had full time slice available to color that/those pixels. What red means I am not sure.... it probably had little time, could be start or end of a time slice. Black is definetly an indication that something else interrupted the time slice. As far as I know this application is unique in the world. Quickly googled "visualizing time slices" turned up nothing. The application is quite easy to code but I guess the idea is genius like yours. I did not realize this app could be used to spy on spyware in firmware. Indeed if firmware uses the processor/cpu to interrupt the OS/threads than it can be visualized. But only if the timer/high performance timer is true/genuine. If time were frozen then nothing would be visible. Though something would eventually show up. Also if spyware is executed by an external cpu/dedicated cpu then nothing will show up. So far this test app of mine version 0.01 only spawns one thread. The application could be started multiple times though and made to run dedicated per core. Somebody could patent it though.... though hopefully this description will be enough to avoid that. Maybe I should not be sharing it... but you kinda had the same idea already but very vaguely. I take it you are not a programmer. But I will try and help you anyway. There is a problem though. www.mijndomein.nl seems completely ****ed up. ^ My webhoster. They changed their ftp... and now I upload my files and they are not showing up on the web... perhaps this is because of no EU rules... or they screwed up... Perhaps it takes a while for these files to show up. Anyway wanted to share it with you... so you have at least 1 tool to keep an eye on cores to see if you spot anything weird going on ! Might be nice ! Hereby I also thank you for your insight/realization into this idea of using time to detect spyware (stealing cpu time) ! Pretty cool ! The app is supposed to be he http://www.skybuck.org/Applications/TimeSliceVisualizer But somehow it's not showing up. Perhaps check back later ! To bad I can't share it with you currently, that sucks. I will make a new posting if this ftp/www starts working again. Perhaps in future I or you will think about it some more how an even more ingenius app can be created which for example fully uses all cores to fill pixels as an ultimate attempt to detect any time stealing. However perhaps a tiny little 200 by 200 is better in case spyware only activates if processor is little utilized So perhaps the 200 by 200 is even better Bye for now, Skybuck. There is a utility for visualization. DPC_LAT The DPC Latency checker, I don't think it works on Windows 10, but works on some of the older OSes. It uses colored spikes to indicate the duration where a delayed procedure call could not receive service. That's how you tell (amongst other things) that SMM is running. The DPC are timestamped and sitting in a queue in the OS, and the service time for a DPC is a measure of system responsiveness. It would be unacceptable to use a system with "red spikes" as an audio recording workstation (as it can screw up sound). https://lnv.i.lithium.com/t5/image/s...v=mpbl-1&px=-1 http://forum.notebookreview.com/atta...901-jpg.64223/ In some cases, DPC latency spiking like that was so bad, it was longer than an OS "clock tick" and affected timekeeping of the system clock. And an unavoidable gap in system responsiveness happens when you play a 3D game and the video card changes modes. That results in a pretty big spike where the OS can't do anything. Paul ( Ok problem with webhosting solved. Webhoster probably moved to a new sftp server while letting the old ftp server run TimeSliceVisualizer application can now be downloaded from my humble website =D http://www.skybuck.org/Applications/...iceVisualizer/ ) I am surprised you put some much trust in a "delayed procedure call" feature of an OS, it's very OS-specific and very gimicky... doesn't tell you much about what the CPU is truely doing. DPC could be issued on time and you'd never know something evil was running. Though the more tools the better. Give my tool a try and see what you like it ! Bye, Skybuck. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Another security issue in the news | Davej | Homebuilt PC's | 1 | January 7th 12 09:15 AM |
Memory Issue or Test issue?? | bill | General | 5 | April 14th 08 01:28 PM |
KB942615 Cumulative Security Update for IE - Post Install Issue | Rich[_8_] | Dell Computers | 12 | December 23rd 07 09:25 AM |
IBM DS4000 security issue when manager is compromised? | IP21Haas | Storage & Hardrives | 2 | February 22nd 07 04:57 PM |
NetApp Data Ontap 6.5 CIFS security issue | Deadgame | Storage & Hardrives | 9 | February 29th 04 08:57 PM |