Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #518379 > unrolled thread
| Started by | Clifford Heath <no.spam@please.net> |
|---|---|
| First post | 2018-10-05 09:29 +1000 |
| Last post | 2018-10-12 08:21 +0200 |
| Articles | 20 on this page of 106 — 24 participants |
Back to article view | Back to sci.electronics.design
Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-05 09:29 +1000
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-05 01:14 +0100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-04 19:31 -0700
Re: Supermicro server motherboards with hardware backdoor? Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2018-10-05 07:27 +0000
Re: Supermicro server motherboards with hardware backdoor? Gene Filatov <evgeny.filatov@ieee.org> - 2018-10-05 11:12 +0300
Re: Supermicro server motherboards with hardware backdoor? Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2018-10-05 08:41 +0000
Re: Supermicro server motherboards with hardware backdoor? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-10-05 16:28 +0100
Re: Supermicro server motherboards with hardware backdoor? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-10-05 09:34 -0700
Re: Supermicro server motherboards with hardware backdoor? Theo <theom+news@chiark.greenend.org.uk> - 2018-10-05 20:59 +0100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-05 14:19 -0700
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-05 23:44 +0100
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 09:58 +1000
Re: Supermicro server motherboards with hardware backdoor? Steve Wilson <no@spam.com> - 2018-10-06 00:39 +0000
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 12:50 +1000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 08:42 +0000
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 21:41 +1000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 14:59 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-06 09:10 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 16:44 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 16:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:34 -0700
Re: Supermicro server motherboards with hardware backdoor? Rob <nomail@example.com> - 2018-10-06 13:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 05:12 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 04:36 -0700
Re: Supermicro server motherboards with hardware backdoor? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-06 14:50 -0400
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:43 -0700
Re: Supermicro server motherboards with hardware backdoor? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-08 13:58 -0400
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-08 20:04 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-09 07:03 +0000
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-09 12:13 +0100
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-09 22:52 +0000
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-10 10:06 +1100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-10 19:06 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-10 18:43 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 12:16 +0000
Re: Supermicro server motherboards with hardware backdoor? Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2018-10-11 14:50 +0200
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 13:51 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 08:35 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 15:56 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 13:24 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 21:24 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 20:43 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 07:38 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 08:55 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 16:48 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 10:22 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 16:49 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 16:53 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 10:27 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 23:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 17:10 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-13 02:13 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 22:29 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-13 09:14 +0000
Re: Supermicro server motherboards with hardware backdoor? +++ATH0 <news@ringpiece.local> - 2018-10-13 14:29 -0700
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-15 16:27 +0100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 08:28 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 08:27 -0700
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-10 10:04 +1100
Re: Supermicro server motherboards with hardware backdoor? pcdhobbs@gmail.com - 2018-10-10 06:47 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-10 19:01 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-06 06:03 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 05:17 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-06 15:38 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:14 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-07 07:15 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-07 08:13 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-20 07:07 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-05 20:12 -0700
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 13:42 +1000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-05 21:02 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-06 06:03 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 08:45 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-06 08:51 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 16:42 +0000
Re: Supermicro server motherboards with hardware backdoor? Dimiter_Popoff <dp@tgi-sci.com> - 2018-10-06 19:55 +0300
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-06 19:29 +0100
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-06 22:41 +0000
Re: Supermicro server motherboards with hardware backdoor? Dimiter_Popoff <dp@tgi-sci.com> - 2018-10-07 02:07 +0300
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-07 11:56 +1100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 20:06 -0700
Re: Supermicro server motherboards with hardware backdoor? Johnny B Good <johnny-b-good@invalid.ntlworld.com> - 2018-10-07 03:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 22:04 -0700
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-06 22:40 +0000
Re: Supermicro server motherboards with hardware backdoor? Dimiter_Popoff <dp@tgi-sci.com> - 2018-10-07 02:05 +0300
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-07 01:36 +0100
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-06 20:14 -0700
Re: Supermicro server motherboards with hardware backdoor? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-10-07 08:07 +0100
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-07 14:09 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-07 08:55 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:50 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:51 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:23 -0700
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-07 13:52 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-07 08:18 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:52 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:54 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-07 22:20 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 08:20 +0000
Re: Supermicro server motherboards with hardware backdoor? Cows are Nice <nice@cows.moo> - 2018-10-08 08:19 -0700
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-08 10:30 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-08 19:57 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-09 06:51 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 08:50 +0000
Re: Supermicro server motherboards with hardware backdoor? jurb6006@gmail.com - 2018-10-11 07:14 -0700
Re: Supermicro server motherboards with hardware backdoor? Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 08:21 +0200
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-05 09:29 +1000 |
| Subject | Supermicro server motherboards with hardware backdoor? |
| Message-ID | <WnxtD.55769$6y.40842@fx09.iad> |
Whether it turns out to be true or not, this will be the biggest security blockbuster of the decade. <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies> Clifford Heath
[toc] | [next] | [standalone]
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2018-10-05 01:14 +0100 |
| Message-ID | <pp6ace$1f23$1@gioia.aioe.org> |
| In reply to | #518379 |
On 10/05/18 00:29, Clifford Heath wrote: > Whether it turns out to be true or not, this will be the biggest > security blockbuster of the decade. > > <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china- used-a-tiny-chip-to-infiltrate-america-s-top-companies> > > > Clifford Heath Couple of articles in The Register as well. Have said for years that we should keep the Chinese at arms length for hi tech, as even if they are not stealing the ip, they have more than enough reason to subvert the designs for their own good and the intellect to implement it. All good and furry on the outside, cheap manufacturing etc, but an undemocratic police state at core, with an expansionist agenda. More than ever, nations progress through advances in the sciences and technology and it should be considered a national security asset. Don't need a tinfoil hat to see that... Chris
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-04 19:31 -0700 |
| Message-ID | <d4d5f8a5-2e8d-4242-8ba7-be0e0a6081db@googlegroups.com> |
| In reply to | #518379 |
On Thursday, October 4, 2018 at 7:30:02 PM UTC-4, Clifford Heath wrote: > Whether it turns out to be true or not, this will be the biggest > security blockbuster of the decade. > > <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies> > > Clifford Heath I hate those white on black web sites. I won't be able to see for a while. Otherwise a great article. Doh, I could have used the reader view button! Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> |
|---|---|
| Date | 2018-10-05 07:27 +0000 |
| Message-ID | <pp73ra$qpc$1@dont-email.me> |
| In reply to | #518379 |
On a sunny day (Fri, 5 Oct 2018 09:29:55 +1000) it happened Clifford Heath <no.spam@please.net> wrote in <WnxtD.55769$6y.40842@fx09.iad>: >Whether it turns out to be true or not, this will be the biggest >security blockbuster of the decade. > ><https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies >> > >Clifford Heath Talk about politics, the news is full of 'China has done it' 'Russia has done it', all fake news originating from trumpesite infiltrated organizations. Same here, Netherlands, gov echoing 'Russia bad ', in the mean time the international court of justice in The Hague here is threatened by the war mongering US as it it ordered that same US to end sanctions against Iran, US industry and consumers are paying more an more for their home appliances and fuel, large parts of US industry suffer under the tariffs imposed by that clueless reality show host posing as 'president', and microsoft spy software is forced upon hardware sellers with modified BIOSes so it won't run anything else, every Intel processor if full of security holes, same for the what's it on board chips. Spy satellites look at what is on your plate, everything is listened to and recorded by same US and there slave states, I wanted to write to nl.politics where are we now, let's make our own nukes and take over that silly club there in N America, let's be great again. Days of Piet Hein https://en.wikipedia.org/wiki/Piet_Pieterszoon_Hein Don't be a US slave. Respect Russia and China. STAND UP! pussies hehe
[toc] | [prev] | [next] | [standalone]
| From | Gene Filatov <evgeny.filatov@ieee.org> |
|---|---|
| Date | 2018-10-05 11:12 +0300 |
| Message-ID | <I1FtD.273300$Vl2.204335@fx46.iad> |
| In reply to | #518406 |
On 05.10.2018 10:27, Jan Panteltje wrote: > On a sunny day (Fri, 5 Oct 2018 09:29:55 +1000) it happened Clifford Heath > <no.spam@please.net> wrote in <WnxtD.55769$6y.40842@fx09.iad>: > >> Whether it turns out to be true or not, this will be the biggest >> security blockbuster of the decade. >> >> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies >>> >> >> Clifford Heath > > Talk about politics, the news is full of 'China has done it' > 'Russia has done it', all fake news originating from trumpesite infiltrated organizations. > Same here, Netherlands, gov echoing 'Russia bad ', > in the mean time the international court of justice in The Hague here is threatened by the war mongering US > as it it ordered that same US to end sanctions against Iran, > US industry and consumers are paying more an more for their home appliances and fuel, > large parts of US industry suffer under the tariffs imposed by that clueless reality show host posing as 'president', > and microsoft spy software is forced upon hardware sellers with modified BIOSes so it won't run anything else, > every Intel processor if full of security holes, same for the what's it on board chips. > Spy satellites look at what is on your plate, everything is listened to and recorded by same US and there slave states, > I wanted to write to nl.politics where are we now, let's make our own nukes and take over that silly club there in N America, > let's be great again. > Days of Piet Hein > https://en.wikipedia.org/wiki/Piet_Pieterszoon_Hein > > Don't be a US slave. > > Respect Russia and China. > STAND UP! > > pussies > hehe > It's interesting how a lot of political discussions are poorly understood psychology in a nutshell. Presumably, you feel insecure because of the world politics, and you want nukes. But suppose you had nukes. Would that make you feel more secure? I believe, that if the problem lies in some kind of a shared feeling of insecurity, then we don't need more nukes. We need more art, more culture, more things which make us happier. Gene.
[toc] | [prev] | [next] | [standalone]
| From | Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> |
|---|---|
| Date | 2018-10-05 08:41 +0000 |
| Message-ID | <pp784h$ipj$1@dont-email.me> |
| In reply to | #518407 |
On a sunny day (Fri, 5 Oct 2018 11:12:22 +0300) it happened Gene Filatov
<evgeny.filatov@ieee.org> wrote in <I1FtD.273300$Vl2.204335@fx46.iad>:
>On 05.10.2018 10:27, Jan Panteltje wrote:
>> On a sunny day (Fri, 5 Oct 2018 09:29:55 +1000) it happened Clifford Heath
>> <no.spam@please.net> wrote in <WnxtD.55769$6y.40842@fx09.iad>:
>>
>>> Whether it turns out to be true or not, this will be the biggest
>>> security blockbuster of the decade.
>>>
>>>
>>> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>>>>
>>>
>>> Clifford Heath
>>
>> Talk about politics, the news is full of 'China has done it'
>> 'Russia has done it', all fake news originating from trumpesite infiltrated organizations.
>> Same here, Netherlands, gov echoing 'Russia bad ',
>> in the mean time the international court of justice in The Hague here is threatened by the war mongering US
>> as it it ordered that same US to end sanctions against Iran,
>> US industry and consumers are paying more an more for their home appliances and fuel,
>> large parts of US industry suffer under the tariffs imposed by that clueless reality show host posing as 'president',
>> and microsoft spy software is forced upon hardware sellers with modified BIOSes so it won't run anything else,
>> every Intel processor if full of security holes, same for the what's it on board chips.
>> Spy satellites look at what is on your plate, everything is listened to and recorded by same US and there slave states,
>> I wanted to write to nl.politics where are we now, let's make our own nukes and take over that silly club there in N America,
>> let's be great again.
>> Days of Piet Hein
>> https://en.wikipedia.org/wiki/Piet_Pieterszoon_Hein
>>
>> Don't be a US slave.
>>
>> Respect Russia and China.
>> STAND UP!
>>
>> pussies
>> hehe
>>
>
>
>It's interesting how a lot of political discussions are poorly
>understood psychology in a nutshell.
>
>Presumably, you feel insecure because of the world politics, and you
>want nukes. But suppose you had nukes. Would that make you feel more secure?
>
>I believe, that if the problem lies in some kind of a shared feeling of
>insecurity, then we don't need more nukes. We need more art, more
>culture, more things which make us happier.
>
>Gene.
Personally I believe in the right of the strongest [1].
US falling victim to decadence and stupidity snake oil, racism, climate change,
the list is endless.
[1] That includes intellect to defeat the competition in evolution.
Empires are being digged up and people wonder why those ended.
Same will happen in N 'merrica.
Already it is falling apart internally, all it takes is to march in there and free the people.
[toc] | [prev] | [next] | [standalone]
| From | Theo Markettos <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2018-10-05 16:28 +0100 |
| Message-ID | <zpz*fdE7w@news.chiark.greenend.org.uk> |
| In reply to | #518379 |
In comp.arch.embedded Clifford Heath <no.spam@please.net> wrote: > Whether it turns out to be true or not, this will be the biggest > security blockbuster of the decade. > > <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies> This is my analysis: https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/ Theo
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2018-10-05 09:34 -0700 |
| Message-ID | <pp83rj$3um$1@dont-email.me> |
| In reply to | #518424 |
On 10/05/2018 08:28 AM, Theo Markettos wrote: > In comp.arch.embedded Clifford Heath <no.spam@please.net> wrote: >> Whether it turns out to be true or not, this will be the biggest >> security blockbuster of the decade. >> >> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies> > > This is my analysis: > https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/ > > Theo > Thanks for that write-up, but why do you find it more feasible that the firmware's being fetched across the network than that the interceptor chip simply has 32Mb of flash on it? It seems like that additional network traffic at boot time would be a pretty recognizable signature. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2018-10-05 20:59 +0100 |
| Message-ID | <Bpz*TcF7w@news.chiark.greenend.org.uk> |
| In reply to | #518439 |
In comp.arch.embedded Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote: > Thanks for that write-up, but why do you find it more feasible that the > firmware's being fetched across the network than that the interceptor > chip simply has 32Mb of flash on it? It seems like that additional > network traffic at boot time would be a pretty recognizable signature. It is possible that the implant is simply replacing the existing QSPI flash, but then a firmware update would either replace it, or the update checksum would fail. So it has to be something that keeps the original flash functioning and tampers with it conditionally. A regular SPI flash chip couldn't that. A very basic flash edit (overdrive the real data lines and force some bytes of config settings) could be done in a CPLD - I didn't check what die sizes vendors have, but they can be small. An FPGA would likely be too big. A full custom chip is also feasible, but in another league in terms of costs. Theo
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-05 14:19 -0700 |
| Message-ID | <c18d12de-b30e-447b-936b-d34fa4bf1ac9@googlegroups.com> |
| In reply to | #518455 |
On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: > In comp.arch.embedded Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote: > > Thanks for that write-up, but why do you find it more feasible that the > > firmware's being fetched across the network than that the interceptor > > chip simply has 32Mb of flash on it? It seems like that additional > > network traffic at boot time would be a pretty recognizable signature. > > It is possible that the implant is simply replacing the existing QSPI flash, > but then a firmware update would either replace it, or the update checksum > would fail. So it has to be something that keeps the original flash > functioning and tampers with it conditionally. > > A regular SPI flash chip couldn't that. A very basic flash edit (overdrive > the real data lines and force some bytes of config settings) could be done > in a CPLD - I didn't check what die sizes vendors have, but they can be > small. An FPGA would likely be too big. > > A full custom chip is also feasible, but in another league in terms of > costs. It's a bit pedantic, but your distinction between CPLD and FPGA is not valid, in fact there are very few CPLDs left on the market because they are not very competitive with FPGAs even on die size. Both types of devices waste a lot of real estate. CPLDs use large arrays to implement the local interconnect with a complete matrix. Larger CPLDs become disproportionately large. FPGAs use a mix of interconnect to try to find an optimal solution to the interconnect problem, but it is a somewhat intractable problem so a lot of real estate is still wasted trying to provide speed optimal solutions. All in all even in smaller PLD designs the FPGA architecture is usually used. There are several FPGAs with only 256 LUT-FFS in the chip and are very small sizes. They are always size limited by the need for I/O pads. In this case, a 6 pin package with at most 4 I/Os, an FPGA could be built that was very small indeed, but still very functional. Still, I expect it is a fully custom chip with an MCU, neither FPGA or CPLD. Did I miss something in the article? BTW, if the chip has sufficient internal capacitance, it is possible to have five I/Os by scavenging power from the I/Os. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2018-10-05 23:44 +0100 |
| Message-ID | <pp8pg7$1ndi$1@gioia.aioe.org> |
| In reply to | #518466 |
On 10/05/18 22:19, gnuarm.deletethisbit@gmail.com wrote: > On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: >> In comp.arch.embedded Rob Gaddi<rgaddi@highlandtechnology.invalid> wrote: >>> Thanks for that write-up, but why do you find it more feasible that the >>> firmware's being fetched across the network than that the interceptor >>> chip simply has 32Mb of flash on it? It seems like that additional >>> network traffic at boot time would be a pretty recognizable signature. >> >> It is possible that the implant is simply replacing the existing QSPI flash, >> but then a firmware update would either replace it, or the update checksum >> would fail. So it has to be something that keeps the original flash >> functioning and tampers with it conditionally. >> >> A regular SPI flash chip couldn't that. A very basic flash edit (overdrive >> the real data lines and force some bytes of config settings) could be done >> in a CPLD - I didn't check what die sizes vendors have, but they can be >> small. An FPGA would likely be too big. >> >> A full custom chip is also feasible, but in another league in terms of >> costs. > > It's a bit pedantic, but your distinction between CPLD and FPGA is not valid, in fact there are very few CPLDs left on the market because they are not very competitive with FPGAs even on die size. Both types of devices waste a lot of real estate. CPLDs use large arrays to implement the local interconnect with a complete matrix. Larger CPLDs become disproportionately large. > > FPGAs use a mix of interconnect to try to find an optimal solution to the interconnect problem, but it is a somewhat intractable problem so a lot of real estate is still wasted trying to provide speed optimal solutions. All in all even in smaller PLD designs the FPGA architecture is usually used. There are several FPGAs with only 256 LUT-FFS in the chip and are very small sizes. They are always size limited by the need for I/O pads. > > In this case, a 6 pin package with at most 4 I/Os, an FPGA could be built that was very small indeed, but still very functional. > > Still, I expect it is a fully custom chip with an MCU, neither FPGA or CPLD. Did I miss something in the article? > > BTW, if the chip has sufficient internal capacitance, it is possible to have five I/Os by scavenging power from the I/Os. > > Rick C. One article I read suggested that such a device would not even need to be visible on the board, but could mounted on one of the internal pcb layers. Perhaps they already are, but companies need to be very wary of what they farm out for manufacturing overseas, especially considering that state level actors have essentially unlimited resources to engineer and hide such hardware hacks... Chris Chris
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-06 09:58 +1000 |
| Message-ID | <YUStD.102151$OM2.49626@fx37.iad> |
| In reply to | #518475 |
On 06/10/18 08:44, Chris wrote: > On 10/05/18 22:19, gnuarm.deletethisbit@gmail.com wrote: >> On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: >>> In comp.arch.embedded Rob Gaddi<rgaddi@highlandtechnology.invalid> >>> wrote: >>>> Thanks for that write-up, but why do you find it more feasible that the >>>> firmware's being fetched across the network than that the interceptor >>>> chip simply has 32Mb of flash on it? It seems like that additional >>>> network traffic at boot time would be a pretty recognizable signature. >>> >>> It is possible that the implant is simply replacing the existing QSPI >>> flash, >>> but then a firmware update would either replace it, or the update >>> checksum >>> would fail. So it has to be something that keeps the original flash >>> functioning and tampers with it conditionally. >>> >>> A regular SPI flash chip couldn't that. A very basic flash edit >>> (overdrive >>> the real data lines and force some bytes of config settings) could be >>> done >>> in a CPLD - I didn't check what die sizes vendors have, but they can be >>> small. An FPGA would likely be too big. >>> >>> A full custom chip is also feasible, but in another league in terms of >>> costs. >> >> It's a bit pedantic, but your distinction between CPLD and FPGA is not >> valid, in fact there are very few CPLDs left on the market because >> they are not very competitive with FPGAs even on die size. Both types >> of devices waste a lot of real estate. CPLDs use large arrays to >> implement the local interconnect with a complete matrix. Larger CPLDs >> become disproportionately large. >> >> FPGAs use a mix of interconnect to try to find an optimal solution to >> the interconnect problem, but it is a somewhat intractable problem so >> a lot of real estate is still wasted trying to provide speed optimal >> solutions. All in all even in smaller PLD designs the FPGA >> architecture is usually used. There are several FPGAs with only 256 >> LUT-FFS in the chip and are very small sizes. They are always size >> limited by the need for I/O pads. >> >> In this case, a 6 pin package with at most 4 I/Os, an FPGA could be >> built that was very small indeed, but still very functional. >> >> Still, I expect it is a fully custom chip with an MCU, neither FPGA or >> CPLD. Did I miss something in the article? >> >> BTW, if the chip has sufficient internal capacitance, it is possible >> to have five I/Os by scavenging power from the I/Os. >> >> Rick C. > > One article I read suggested that such a device would not even need > to be visible on the board, but could mounted on one of the internal > pcb layers. That was the original Bloomberg article. Down the bottom it said that this had already happened. It seems like something that would need substantial modifications to any existing PCB production tooling, so would be hard to do covertly. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | Steve Wilson <no@spam.com> |
|---|---|
| Date | 2018-10-06 00:39 +0000 |
| Message-ID | <XnsA972D232F8D94idtokenpost@69.16.179.22> |
| In reply to | #518484 |
Clifford Heath <no.spam@please.net> wrote: >> One article I read suggested that such a device would not even need >> to be visible on the board, but could mounted on one of the internal pcb >> layers. > That was the original Bloomberg article. Down the bottom > it said that this had already happened. It seems like > something that would need substantial modifications to > any existing PCB production tooling, so would be hard to > do covertly. > Clifford Heath. Modifying the hardware is virtually imposssible. You need the schematic, the pcb layout tools, a vendor who can duplicate the original pcb process, and a way to get the modified board into the process stream undetected. Any hardware change can easily be detected. Take a photo of a known good board and a suspect board. Subtract them. Any differences would be instantly visible. Do the same with X-Rays. That would capture any changes to the internal layers. It is far easier to do it in software. Modify the firmware so the change is invisible. There are virtually an infinite number of ways to do it. Untraceable, so no one can tell where it occurred in the process stream. Selective, so you can turn it on only when a desired target is found. Someone is running a clickbait article. The whole idea of a hardware attack is not worth reading.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-06 12:50 +1000 |
| Message-ID | <VpVtD.128717$SN2.9245@fx38.iad> |
| In reply to | #518488 |
On 06/10/18 10:39, Steve Wilson wrote: > Clifford Heath <no.spam@please.net> wrote: > >>> One article I read suggested that such a device would not even need >>> to be visible on the board, but could mounted on one of the internal pcb >>> layers. > >> That was the original Bloomberg article. Down the bottom >> it said that this had already happened. It seems like >> something that would need substantial modifications to >> any existing PCB production tooling, so would be hard to >> do covertly. > >> Clifford Heath. > > Modifying the hardware is virtually imposssible. You need the schematic, > the pcb layout tools, a vendor who can duplicate the original pcb process, > and a way to get the modified board into the process stream undetected. > > Any hardware change can easily be detected. Take a photo of a known good > board and a suspect board. Subtract them. Any differences would be > instantly visible. Do the same with X-Rays. That would capture any changes > to the internal layers. > > It is far easier to do it in software. Modify the firmware so the change is > invisible. There are virtually an infinite number of ways to do it. > Untraceable, so no one can tell where it occurred in the process stream. > Selective, so you can turn it on only when a desired target is found. > > Someone is running a clickbait article. The whole idea of a hardware attack > is not worth reading. Steve, have you even read the article? The device just needs to feed the BMC customised code over SPI. Six pins on an EEPROM would do it, or a chip that sits between the code EEPROM and modifies the SPI data. Supermicro's San Jose design facility is full of Chinese, some of whom speak no English, just Mandarin. Of course the hack was a software hack; put there in the schematic and PCB layout by one of those designers. Or added to the Gerbers in the factory by someone who had access to the schematic and layout and knew where to cut and paste. Neither of those things is implausible for a nation-state capability that has agents working for the company. In any case, that wasn't the subject I was responding to. Chris said he'd read about the malware chip being inserted in between PCB layers during fab. I don't think there's anything in normal PCB fab that would make that feasible. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-06 08:42 +0000 |
| Message-ID | <pp9sgq$16t6$1@gioia.aioe.org> |
| In reply to | #518503 |
Clifford Heath <no.spam@please.net> wrote in news:VpVtD.128717$SN2.9245 @fx38.iad: > Of course > the hack was a software hack; put there in the schematic > and PCB layout by one of those designers. Nope. The design engineers for Supermicro are in the US. It may have been as simple as cutting and scraping clean pad areas on a single trace and adding the part to the trace lead. It was done at the manufacturing facility.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-06 21:41 +1000 |
| Message-ID | <rb1uD.295652$tK2.24441@fx42.iad> |
| In reply to | #518519 |
On 06/10/18 18:42, DecadentLinuxUserNumeroUno@decadence.org wrote: > Clifford Heath <no.spam@please.net> wrote in news:VpVtD.128717$SN2.9245 > @fx38.iad: > >> Of course >> the hack was a software hack; put there in the schematic >> and PCB layout by one of those designers. > > Nope. The design engineers for Supermicro are in the US. Most of the US staff at the San Jose facility are Chinese by descent, and many do not speak English well. Capice?
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-06 14:59 +0000 |
| Message-ID | <ppaikn$btu$1@gioia.aioe.org> |
| In reply to | #518524 |
Clifford Heath <no.spam@please.net> wrote in news:rb1uD.295652$tK2.24441 @fx42.iad: > Most of the US staff at the San Jose facility are Chinese > by descent, and many do not speak English well. Capice? They would not want it to be traceable in that manner, capice? It was done AT the contract manufacturing point... period. The only possible downstream accomplice might be the visual inspector for the mobo as it exits the reflow oven. After that all parties at the factory could be innocent and that makes it even more covert.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Liebermann <jeffl@cruzio.com> |
|---|---|
| Date | 2018-10-06 09:10 -0700 |
| Message-ID | <blmhrdlsv2eoeoghuup2qh23ggas9t1af3@4ax.com> |
| In reply to | #518532 |
On Sat, 6 Oct 2018 14:59:35 +0000 (UTC), DecadentLinuxUserNumeroUno@decadence.org wrote: >The only possible >downstream accomplice might be the visual inspector for the mobo as it >exits the reflow oven. Large PCB assembly shops do not do visual inspection for production boards. They use optical comparison equipment. Take a photo of a known working board and compare it with what comes out of the reflow oven. If a component is missing, backwards, sideways, or has been added, it will see the change, and flag the defective part. For smaller runs, a side by side optical comparator is sometimes used. Like a previously mumbled, why would someone add a spy chip, which could be easily be seen, when adding additional instructions or microcode inside commodity chips, such as bi-directional bus controllers that can see and write to the entire 64 bit bus, would make more sense? Or, if it were so important to remote control the server, why not just design it into the original reference design instead of adding it as an afterthought? -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-06 16:44 +0000 |
| Message-ID | <ppaope$mgp$2@gioia.aioe.org> |
| In reply to | #518535 |
Jeff Liebermann <jeffl@cruzio.com> wrote in news:blmhrdlsv2eoeoghuup2qh23ggas9t1af3@4ax.com: > why would someone add a spy chip, which > could be easily be seen, when adding additional instructions or > microcode inside commodity chips, such as bi-directional bus > controllers that can see and write to the entire 64 bit bus, would > make more sense? Yeah... mumbled is right. Picture this. Your ideas would get caught right away. Ooops, failed idea. This INSERTS the code, so goes undetected *until* implemented.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-06 16:46 +0000 |
| Message-ID | <ppaosl$mgp$3@gioia.aioe.org> |
| In reply to | #518535 |
Jeff Liebermann <jeffl@cruzio.com> wrote in news:blmhrdlsv2eoeoghuup2qh23ggas9t1af3@4ax.com: > Or, if it were so important to remote control the > server, why not just design it into the original reference design > instead of adding it as an afterthought? Because most of Supermicro's employees were legitimate folk.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | sci.electronics.design
csiph-web