http://boingboing.net/2016/06/15/intel- ... -with.html
That is some disturbing shit right there!
Intel heard you liked cpu's so it put a cpu in your cpu
-
bark_bark_bark
- Posts: 1885
- Joined: Tue 05 Jun 2012, 12:17
- Location: Wisconsin USA
and ARM where possible.bark_bark_bark wrote:Another reason to love AMD.
The problem is that many companies/manufactures include "back doors" in hardware and/or software and are not allowed to disclose it.
Oh the joys of manufacturing in the US.
But not to worry, this Intel thing will come back to bite them as certain corporations/organizations/governments will either find ways to circumvent the Intel "feature" or simply look for alternatives.
Personally I couldn't give a rats @R$3 if they read my data (and hope they choke on it) but for those that may be, what can be done?
Stick to older processors for as long as possible.
Distribute your "data" across several devices such as tablets, phones, AMD based computers (if they don't have it too), or even a puny little Pi.
Make sure that you are connected to the net only when required then switch off again.
Since this "feature" runs behind the OS, it's not good enough just to disable your wifi/ethernet via software, it has to be done physically.
For ethernet it's simple, a 4 pole double throw switch is all that is required on the nic of the computer.
If however you are using wifi, then the manual switch has to be installed after your A.P. if the A.P. is separate from your modem/router.
If you are using DSL, then a 2 pole double throw switch on the DSL line will take care of it.
One could even replace the switch with a relay (driven by a transistor) which in turn can be activated via a script.
I will draw up a schematic shortly and post here.
This certainly won't completely stop it, but will minimize the chances.
As promised, the schematic.
It switches both Ethernet and/or DSL.
The three relays are DPDT with a 5V 30mA coil, so all three can be powered from a USB port which can supply 100mA.
The control signal "CTL" can be a pin from a real serial port, a USB to serial converter or a LPT port or simply a manual SPDT switch wired between the CTL pin and the +5V pin.
To control it, one can use a Bash script, C, Python, or anything else that will give access to the port being used.
For the ethernet connections, refer to the second attached diagram.
Hope it's of some use to someone.
It switches both Ethernet and/or DSL.
The three relays are DPDT with a 5V 30mA coil, so all three can be powered from a USB port which can supply 100mA.
The control signal "CTL" can be a pin from a real serial port, a USB to serial converter or a LPT port or simply a manual SPDT switch wired between the CTL pin and the +5V pin.
To control it, one can use a Bash script, C, Python, or anything else that will give access to the port being used.
For the ethernet connections, refer to the second attached diagram.
Hope it's of some use to someone.
- Attachments
-
- EthernetAndDSLswitcher.jpg
- (39.37 KiB) Downloaded 291 times
-
- Ethernet-wiring_sm.jpg
- (84.39 KiB) Downloaded 287 times
-
learnhow2code
Re: Intel heard you liked cpu's so it put a cpu in your cpu
thats exactly what i was talking about when i posted: http://murga-linux.com/puppy/viewtopic. ... 751#907751solo wrote:That is some disturbing shit right there!
ive had a 2 year old chip with this. well, perhaps it wasnt the same chip but if im not going to open the thing up and desolder it (or it wont operate reliably with the chip removed) then what difference does it make?
i also posted about an intel chip from 2012 with wifi built in.
chips run microcode, management engines + microcode updates are as bad as this.
the problem is real, the technology isnt new.
ultimately, youre going to a lot of trouble to secure your software, without any ability to secure the hardware.
i would love to think amd is better (usually theyre just a year or two behind) and arm isnt even a chip. (its more like a style, because you can do anything with/to it.)
they also have x86/arm hybrid chips. some cores are x86, some are arm.
free/open hardware is probably the only way out of this. that could take a while. first this stuff goes on top-of-the-line equipment (like cameras on smartphones) and sooner or later, its harder to find cheap stuff without it.
at least pete has options! http://www.bigmessowires.com/2014/11/17 ... readboard/
@learnhow2code
I must point out that my options/ideas won't completely negate the problem, but it will at least minimize it so some degree.
Was giving this CPU in a CPU thing more thought and I'm pretty sure that it can be accessed via the main CPU via some special registers.
The way I see it, it has three layers.
1) Access the special registers of the "little" CPU via the "big" CPU
(More on this later).
2) The "little" CPU will in turn populate those registers with a reply.
3) Last step, we have to populate those registers again with the RSA2048 bits.
From here it will be open.
There has to be a way (similar to what I described) so that the microcode can be uploaded and also to be able to check the status of the "little" CPU and also do updates.
After all they have to load and test the microcode during manufacturing and QC.
Now back to step 1.
Since most likely they will use special registers and/or undocumented opcodes, we will need to use a low level language like ASM.
Now no current ASM compiler will have these special opcodes so will refuse to compile, but all is not lost as we can include raw data bytes in-line to make up the hex values of these opcodes.
(After all that is all opcodes are, data values corresponding to actions in the microcode).
Example (assuming these registers and opcodes are 64 bits):
The align64 directive tells the assembler/compiler to align the data in 64 bit boundries.
Now the DQ stands for "Data Word Quad" i.e. 64 bits.
Then the hex values are the actual opcodes..
(This is an old trick from the 16 bit days but no reason it will not work with 64 bits).
From there when can use mov EDX:EAX to move the "ocodes" to the required registers.
However this is only part of the "protocol".
The hard part comes in interpreting the returned data and of course the 2048 bit key.
BTW, loved the article on the guy who built his own "computer".
If it carries on like this, we may all have to follow suit.
I must point out that my options/ideas won't completely negate the problem, but it will at least minimize it so some degree.
Was giving this CPU in a CPU thing more thought and I'm pretty sure that it can be accessed via the main CPU via some special registers.
The way I see it, it has three layers.
1) Access the special registers of the "little" CPU via the "big" CPU
2) The "little" CPU will in turn populate those registers with a reply.
3) Last step, we have to populate those registers again with the RSA2048 bits.
From here it will be open.
There has to be a way (similar to what I described) so that the microcode can be uploaded and also to be able to check the status of the "little" CPU and also do updates.
After all they have to load and test the microcode during manufacturing and QC.
Now back to step 1.
Since most likely they will use special registers and/or undocumented opcodes, we will need to use a low level language like ASM.
Now no current ASM compiler will have these special opcodes so will refuse to compile, but all is not lost as we can include raw data bytes in-line to make up the hex values of these opcodes.
(After all that is all opcodes are, data values corresponding to actions in the microcode).
Example (assuming these registers and opcodes are 64 bits):
Code: Select all
:
:
Usual headers and declarations
:
:
align64
DQ 0x557809FF, 0xEA77053CA, .......
etc etc
Now the DQ stands for "Data Word Quad" i.e. 64 bits.
Then the hex values are the actual opcodes..
(This is an old trick from the 16 bit days but no reason it will not work with 64 bits).
From there when can use mov EDX:EAX to move the "ocodes" to the required registers.
However this is only part of the "protocol".
The hard part comes in interpreting the returned data and of course the 2048 bit key.
BTW, loved the article on the guy who built his own "computer".
If it carries on like this, we may all have to follow suit.
-
learnhow2code
DIY forever, DIY/T (do it yourself/together) is the name of the game. i know perfectly well that "roll your own security" is practically a contradiction in terms.Pete wrote:If it carries on like this, we may all have to follow suit.
somewhere between that and "just trust apple" there has to be a sane compromise-- almost nothing like what we are doing these days, but much more like what "real security people" do.
i like to assume there is a future. but if there is a future worth having, it looks different than the dumb sh** we are getting right now.
amendment 0 is the right to be free.
-
gcmartin
Secondary processor for system controls and maintenance
I understand the initial poster's concerns, but this practice has been a "staple" in Intel based server processors system for awhile now. I forgot the term they use, but its posted everywhere anyone talks about Intel based servers as well as the engineering based PC systems sold.
HPE's server (Gen8s and Gen9s) have this utility processor built in. This is one of the reasons you see 2 LAN adapters onboard. With HP's utilities, you can use that processor for many sorts of useful purposes including system design, system setup, OS controls, Remote Desktop, backup-restores, etc that people/admins would find useful. From what I have known, it is Linux/HPUX as its processor OS providing these utility services to your system. This capability is in both, standalone or rack-mount systems. Much benefit in it.
Hope this reduces the alarm and we can see benefit.
HPE's server (Gen8s and Gen9s) have this utility processor built in. This is one of the reasons you see 2 LAN adapters onboard. With HP's utilities, you can use that processor for many sorts of useful purposes including system design, system setup, OS controls, Remote Desktop, backup-restores, etc that people/admins would find useful. From what I have known, it is Linux/HPUX as its processor OS providing these utility services to your system. This capability is in both, standalone or rack-mount systems. Much benefit in it.
Hope this reduces the alarm and we can see benefit.
-
learnhow2code
Re: Secondary processor for system controls and maintenance
at ycombinator theyre having a more detailed talk than is likely to happen here:
https://news.ycombinator.com/item?id=11913379
look for the mention of joanna rutkowska, the "qubes os" researcher who covers the problem in great detail.
basically, security is about keeping bad things from getting in, knowing when bad things get in, and (worst case) removing them when theyve gotten in.
me makes the first one nearly impossible, the second one just as difficult, and the third one extremely challenging. and thats when its not even on the same chip. linux puts you in charge of your security, and your cpu/northbridge/network hw simply takes away your opportunity to be in charge.
on some machines this is based on a separate network interface. in theory (maybe not in practice) that means if you dont plug into the second nic, youre ok.
have you ever seen how many ways there are to bridge network hardware? so perhaps theres reason to be skeptical.
doesnt matter though, on some systems the me sort of duplexes over a single network interface. it would be nice if that means installing your own nic prevents the issue (see previous paragraph.)
rutkowska seems more pessimistic than i am. although personally i think free/libre hardware is the main option going (far) forward. dont throw away your older pentiums. run puppy on them, and if that doesnt work run server puppy (no x.) and if that doesnt work, find something lighter to run on them. (also dont use puppy for online banking, imo.)
you can however, use your fancy-pants new 50-core cpu for online banking. it is probably going to be a while before thats the weakest link in the online banking chain.
https://news.ycombinator.com/item?id=11913379
look for the mention of joanna rutkowska, the "qubes os" researcher who covers the problem in great detail.
basically, security is about keeping bad things from getting in, knowing when bad things get in, and (worst case) removing them when theyve gotten in.
me makes the first one nearly impossible, the second one just as difficult, and the third one extremely challenging. and thats when its not even on the same chip. linux puts you in charge of your security, and your cpu/northbridge/network hw simply takes away your opportunity to be in charge.
on some machines this is based on a separate network interface. in theory (maybe not in practice) that means if you dont plug into the second nic, youre ok.
have you ever seen how many ways there are to bridge network hardware? so perhaps theres reason to be skeptical.
doesnt matter though, on some systems the me sort of duplexes over a single network interface. it would be nice if that means installing your own nic prevents the issue (see previous paragraph.)
rutkowska seems more pessimistic than i am. although personally i think free/libre hardware is the main option going (far) forward. dont throw away your older pentiums. run puppy on them, and if that doesnt work run server puppy (no x.) and if that doesnt work, find something lighter to run on them. (also dont use puppy for online banking, imo.)
you can however, use your fancy-pants new 50-core cpu for online banking. it is probably going to be a while before thats the weakest link in the online banking chain.
Re: Secondary processor for system controls and maintenance
GC, I consider myself an avarage user, and I can inform you that your explanation has not given me any comfort in any way.gcmartin wrote:I understand the initial poster's concerns, but this practice has been a "staple" in Intel based server processors system for awhile now. I forgot the term they use, but its posted everywhere anyone talks about Intel based servers as well as the engineering based PC systems sold.
HPE's server (Gen8s and Gen9s) have this utility processor built in. This is one of the reasons you see 2 LAN adapters onboard. With HP's utilities, you can use that processor for many sorts of useful purposes including system design, system setup, OS controls, Remote Desktop, backup-restores, etc that people/admins would find useful. From what I have known, it is Linux/HPUX as its processor OS providing these utility services to your system. This capability is in both, standalone or rack-mount systems. Much benefit in it.
Hope this reduces the alarm and we can see benefit.
Perhaps from a position as a developer/engineer/admin putting in a seperate processing unit which can completely bypass any security in place to take total control of a computer remotely may seem like a beneficial, and perhaps even neccessary utility to have, but you have to forgive my lack of trust in this day and age when I tell ya that from my end, this creeps me out tremendously.
And surely Intel is well aware of my reservations as well, because I haven't seen any small print in their hardware ads explaining that yes, by the way, we kind of sort of turned your cpu into a trojan horse, but don't worry, we promise only the good guys will use it for good things.
Listen, I'm not disputing the fact that it has potentialy beneficial purposes. But it is kind of like saying to someone their house is well ventilated after blowing a big hole into their wall.
Can Intel give me the assurance that this will never ever ever ever be used by anyone for malicious reasons?! Or their own reasons?!
They can not.
As consumers, you have been assured by Intel you received a product that would meet certain standards, and security standards are certainly part of that.
And quite simply put, those standards have not been met.
So, as a consumer, you have not received the standard of service you have payed for.
I believe it would be a beneficial development if a large group of consumers would sue Intel.
Although gcmartin has a few valid points that it could be used for "good",
I have to agree with both learnhow2code and solo in that the disadvantages far outweigh the advantages.
Solo's analogy of the big hole in the wall sums it up perfectly.
It also gives me no comfort that the extra CPU has it's own ethernet connections.
This means diddle-squat for the simple reason of multiplexing which learnhow2code alluded to.
In short, I too would like to see some civil action against Intel.
If nothing else, it would make more people aware of this "feature"
and all the negative publicity would make Intel a bit nervous.
It would of course have an added benefit that people would start asking other CPU manufactures (AMD, ARM) if they have this too.
I have to agree with both learnhow2code and solo in that the disadvantages far outweigh the advantages.
Solo's analogy of the big hole in the wall sums it up perfectly.
It also gives me no comfort that the extra CPU has it's own ethernet connections.
This means diddle-squat for the simple reason of multiplexing which learnhow2code alluded to.
In short, I too would like to see some civil action against Intel.
If nothing else, it would make more people aware of this "feature"
and all the negative publicity would make Intel a bit nervous.
It would of course have an added benefit that people would start asking other CPU manufactures (AMD, ARM) if they have this too.
-
learnhow2code
it would be fine, imo-- if this were only a feature in some chips they make, and it was made clear to customers what it does-- i really question if this is the case-- and there was some way to clearly avoid ever having it.Pete wrote:If nothing else, it would make more people aware of this "feature"
and all the negative publicity would make Intel a bit nervous.
this desire invites a slew of partly-irrelevant solutions-- support-per-motherboard, an "off" setting, firmware changes at levels that dont pertain to the functionality... yeah, yeah, yeah-- no.
just dont put it in all consumer pcs. given what its good for (not anti-virus. what gnu/linux user wants an anti-virus they cant remove or audit or upgrade?) it probably shouldnt be on most consumer pcs.
but if someone wants it, its cheaper to put it on the chip and turn it on and off. well, no. sometimes that isnt good enough, and this is the perfect example of that. this is something consumers should be wary of, and after a year or two (in a way, this isnt news) some finally, at least for a moment, are.