Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sevenlayermuddle]

I did consider just disgregarding the smartness of my TV, denying it access to Lan.   Netflix, Iplayer etc can, after all, be provided by a separate STB that is cheap enough to replace every few years, thus keeping it up to date.    Trouble is, the draw of having Netflix & Iplayer fully integrated was too strong, it is just too convenient.

So I relinquished, but put the TV on my ‘guest’ Lan, where devices are isolated from from other Lan devices, can only access the internet.   But owing to my specific current equipment, a limitation arose - the only way to view my photos at 4k resolution, was to use the TV’s own photo App, so the TV needed access to my media server.   And the battle to secure the TV was lost.

[sevenlayermuddle]

Hmm, AMD do seem to be softening their denials, sounds like they are hit too.   Arm also.   Slashgear story includes statements from both...

https://www.slashgear.com/intels-bug-response-its-not-just-us-03513499/

More from AMD here...

https://www.amd.com/en/corporate/speculative-execution

Strikes me that ARM would be a pretty big problem, owing to use in smartphones.   Smartphone performance might well to tuned so as to depend upon every last CPU cycle, being a much more controlled and predictable environment, compared to a standalone PC.

[Weaver]

sevenlayermuddle: Would it be feasible to use a switch or firewall to restrict your TV to being only able to access the media server within your LAN? (Plus it will need to talk to the DHCP server probably, and probably the default gateway)

I have changed the firewalling scheme that is in use in my Firebrick so that I can have more classes of citizens, not just a binary arrangement if guests=pond-life or first-class citizens, but now I can have guests who can't pester first-class citizens, nodes that have assigned fixed IPv4 addresses [fixed values but still handed out by DHCP], nodes that are restricted to very slow internet access and so on, and these properties/restrictions can be much more easily be set separately rather thatn just being determined by the two-caste system. It's all driven by lists of MAC addresses in the Firebrick and in the ZyXel WAPs.

[sevenlayermuddle]

@Weaver, yes I am sure more could be done to secure my TV with special rules.   Trouble is, it all takes effort, and my time is limited. 

Another convenience I’ve not yet mentioned is my Panasonic camera can talk direct to a server provided by the TV, directly displaying new photos over WiFi.  Handy when I get back from a day out and just want to preview from the armchair.   That wouldn’t work on my guest Lan, as devices are isolated from one another.  Again, special rules could probably be established, if only I had the time, but I don’t.

[Weaver]

It is indeed all a pain, the time it takes to keep these things well tamed.

[sevenlayermuddle]

Google say ARM and AMD are affected too, not just Intel.

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

[broadstairs]

According to that AMD response they are only potentially at risk from 1 of the 3 variants and the one they say they are at risk of is resolved by updates to the OS. Although they are being careful about variant 2 where they say near zero risk. Which sounds to me like their hardware/firmware is more resilient than the Intel stuff.

Stuart

[sevenlayermuddle]

Suddenly they are falling over one another in attempts to explain the situation.   I guess the NDAs must have expired.

Sounds like Google found it and shared it many months ago, so all very well understood.  Similar can (I think) be found from Google, AMD and Intel, but I found ARM’s white paper very readable.   If my grey matter was 10 years younger, I might even have grasped it all from first pass.  Meanwhile I will continue reading over and over, in the hope it sinks in.   

https://developer.arm.com/support/security-update

White paper, linked from above...

https://armkeil.blob.core.windows.net/developer/Files/pdf/Cache_Speculation_Side-channels.pdf

[Weaver]

I would have thought that the cache timing thing is difficult to use practically.

I remember timing side channel stuff going back many years, it's hardly true to say it's a new general principle, but this particular application if it is new. I remember for example discussions about analysing timing of requests sent to a server, and such timing analysis could tell you whether an object was in a disk cache in a server or not, and intentional response-timing manipulation was suggested as a covert means of sending information out despite a blocking firewall. Basically, if you are living inside a firewall boundary, you thrash some box that is acting as a server and your friend outside makes allowed requests on that server and times the responses. By thrashing or not thrashing you can make the responses arrive back at your friend early or late so then you can send one bit of information out. Standard error correction helps.

[Chrysalis]

that performance hit is huge, surely they need to make some kind of optional flag/setting in the OS to give end users the choice.

[highpriest]

https://meltdownattack.com/

and...

https://spectreattack.com/

[Weaver]

I notice that the paper linked to earlier claims that the Spectre timing attack has been successfully tested on some ARM processors and on the AMD Ryzen. So Intel isn't the only one in the doghouse.

[burakkucat]

Here follows a copy of a post that Linus Torvalds made to the Linux Kernel Mailing List --

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you p00
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

                   Linus

https://lkml.org/lkml/2018/1/3/797

[Weaver]

So Linus agrees with me. Good for him. We don't all need this nightmare fix, but that is not to be understood as a recommendation for complacency. I also think it's time to take a careful and considered look rather than panicking. And the advice of people such as Linus is to be heeded, not those who have a political axe to grind.

Saying that something performs to spec is not good enough if the spec is insane, remember was the Airbus plane that put its wheels down when it went over the top of a hill, because that was the "definition" of "landing", and then crashed.

[kitz]

I notice that the updates have been rolling out.   

2018-01 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4056892)
Successfully installed on ‎04/‎01/‎2018

KB4056892 (OS Build 16299.192)

I've not noticed any performance issues but to be fair Ive not stressed it out or done any testing.   There is a large thread on tenforums where users have been doing more advanced testing.    From a very quick scan through that 15 page thread, apart from someone mentioning ASUS I couldnt see anything too negative.

---

ETA just noticed a post added a few mins ago here about someone's SATA performance.

Damn. This "fix" has completely killed my SATA SSD performance:
I couldn't believe it but I reinstalled the patch and got virtually identical results.

Yet bizzarely, an NVM-based SSD on the same machine is completely unaffected. A driver thing I guess.