Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #17709 > unrolled thread

Intel VISA

Back to article view | Back to comp.misc

Contents

  Intel VISA RS Wood  <rsw@therandymon.com> - 2019-03-30 17:08 -0400
    Re: Intel VISA Oregonian Haruspex <no_email@invalid.invalid> - 2019-04-10 06:10 +0000
    Re: Intel VISA Steve555 <Steve555@reallybogus.nodomain.nowhere.invalid> - 2019-06-17 22:05 +0000

#17709 — Intel VISA

From the «yay, a new vulnerability» department:
Title: Researchers Discover and Abuse New Undocumented Feature in Intel Chipsets
Author: help@slashdot.org
Date: Fri, 29 Mar 2019 13:58:00 -0400
Link: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/VsjqKX7Yml0/researchers-discover-and-abuse-new-undocumented-feature-in-intel-chipsets

At the Black Hat Asia 2019 security conference, security researchers from
Positive Technologies disclosed the existence of a previously unknown and
undocumented feature in Intel chipsets. From a report: Called Intel
Visualization of Internal Signals Architecture (Intel VISA), Positive
Technologies researchers Maxim Goryachy and Mark Ermolov said this is a new
utility included in modern Intel chipsets to help with testing and debugging on
manufacturing lines. VISA is included with Platform Controller Hub (PCH)
chipsets part of modern Intel CPUs and works like a full-fledged logic signal
analyzer. According to the two researchers, VISA intercepts electronic signals
sent from internal buses and peripherals (display, keyboard, and webcam) to the
PCH -- and later the main CPU. Unauthorized access to the VISA feature would
allow a threat actor to intercept data from the computer memory and create
spyware that works at the lowest possible level. But despite its extremely
intrusive nature, very little is known about this new technology.

[image 2][2][image 4][4][image 6][6]

Read more of this story[7] at Slashdot.
[image 8]

Links:
[1]: http://twitter.com/home?status=Researchers+Discover+and+Abuse+New+Undocumented+Feature+in+Intel+Chipsets%3A+http%3A%2F%2Fbit.ly%2F2U4HDyP (link)
[2]: https://a.fsdn.com/sd/twitter_icon_large.png (image)
[3]: http://www.facebook.com/sharer.php?u=https%3A%2F%2Fit.slashdot.org%2Fstory%2F19%2F03%2F29%2F1657225%2Fresearchers-discover-and-abuse-new-undocumented-feature-in-intel-chipsets%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook (link)
[4]: https://a.fsdn.com/sd/facebook_icon_large.png (image)
[5]: http://plus.google.com/share?url=https://it.slashdot.org/story/19/03/29/1657225/researchers-discover-and-abuse-new-undocumented-feature-in-intel-chipsets?utm_source=slashdot&utm_medium=googleplus (link)
[6]: https://www.gstatic.com/images/icons/gplus-16.png (image)
[7]: https://it.slashdot.org/story/19/03/29/1657225/researchers-discover-and-abuse-new-undocumented-feature-in-intel-chipsets?utm_source=rss1.0moreanon&utm_medium=feed (link)
[8]: http://feeds.feedburner.com/~r/Slashdot/slashdot/~4/VsjqKX7Yml0 (image)


--
Burger? You burger, you brought'er.

[toc] | [next] | [standalone]

#17795

I’m saving up for a Talos Raptor. Screw Intel and AMD seems better but you
just know...

[toc] | [prev] | [next] | [standalone]

#18236

Initially I thought this is like shipping a large software product with all 
the debug code left in.  In a software product there is usually something
like a compile-time option to exclude most of the debug code using conditional 
compilation; you don't ship a lot of unnecessary debug code in the product.
And leaving the debug on in a chip will have the undesirable consequence of
using up die surface area... which is something you don't want to do when
you're trying to minimise die size and maximise yield.

But then I read the sentance that says this helps debugging on the 
manufacturing line, so maybe this is actually used during chip 
production.  I guess if the chips coming off the line fail some tests, or
you want to tune the layout to get (say) better yield at higher frequencies,
you need a way to test and debug them.  So it might not so easy to switch off 
the debug in hardware as it is in software.  In fact having the debug
infrastructure in place may be essential to fix bugs in the chip as they
are found in the field.  If this is correct, I would expect AMD and 
ARM to have similar technology for production debug and test.

-- 
  Gnd  -|o----|- Vcc      Hey computer, what's the weather in Sydney?
 trig  -| 555 |- dschrg   $> finger o:sydney@graph.no|tail -1|espeak
  o/p  -|     |- thrsh
  rst  -|-----|- cntrl    Steve555

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web