Concesus of AMD PSP security issue?
View Single Post
June 8th 18, 07:16 PM posted to alt.comp.hardware.pc-homebuilt
external usenet poster
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
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.
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
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,
There is a utility for visualization.
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).
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.
View Public Profile
View message headers
Find all posts by Paul[_28_]
Find all threads started by Paul[_28_]