A computer components & hardware forum. HardwareBanter

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.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Homebuilt PC's
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Concesus of AMD PSP security issue?



 
 
Thread Tools Display Modes
  #1  
Old June 6th 18, 05:55 AM posted to alt.comp.hardware.pc-homebuilt
xJumper
external usenet poster
 
Posts: 3
Default 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  
Old June 6th 18, 06:42 AM posted to alt.comp.hardware.pc-homebuilt
Paul[_28_]
external usenet poster
 
Posts: 814
Default 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  
Old June 6th 18, 07:00 PM posted to alt.comp.hardware.pc-homebuilt
Flasherly[_2_]
external usenet poster
 
Posts: 2,086
Default 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  
Old June 8th 18, 02:23 PM posted to alt.comp.hardware.pc-homebuilt
[email protected]
external usenet poster
 
Posts: 185
Default 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  
Old June 8th 18, 02:29 PM posted to alt.comp.hardware.pc-homebuilt
[email protected]
external usenet poster
 
Posts: 185
Default 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
  #7  
Old June 8th 18, 07:16 PM posted to alt.comp.hardware.pc-homebuilt
Paul[_28_]
external usenet poster
 
Posts: 814
Default Concesus of AMD PSP security issue?

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
  #8  
Old June 8th 18, 09:13 PM posted to alt.comp.hardware.pc-homebuilt
Flasherly[_2_]
external usenet poster
 
Posts: 2,086
Default 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  
Old June 10th 18, 06:38 PM posted to alt.comp.hardware.pc-homebuilt
[email protected]
external usenet poster
 
Posts: 185
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 10:41 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 HardwareBanter.
The comments are property of their posters.