Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Another Intel vulnerability (L1TF)
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Another Intel vulnerability (L1TF)

ShazanShazan Member, Host Rep

Today Intel disclosed a new vulnerability that affects most of the recent processors.

From the website: "L1TF is a speculative execution side channel cache timing vulnerability. In this regard, it is similar to previously reported variants. There are three varieties of L1TF that have been identified. Each variety of L1TF could potentially allow unauthorized disclosure of information residing in the L1 data cache, a small pool of memory within each processor core designed to store information about what the processor core is most likely to do next."

You can find the detailed explanation at https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html

Thanked by 3Janevski szarka hien
«1

Comments

  • deankdeank Member, Troll

    The end was here and then the end is now. The end will be here.

  • ClouviderClouvider Member, Patron Provider

    That affects AMD as well ?

  • @Clouvider said:
    That affects AMD as well ?

    https://www.bleepingcomputer.com/news/security/researchers-disclose-new-foreshadow-l1tf-vulnerabilities-affecting-intel-cpus/

    "According to the research team behind the L1TF/Foreshadow flaws, only Intel CPUs are affected. Researchers contacted Intel earlier this year and worked with the company, OS makers, and cloud hosting providers to prepare mitigations and updates."

  • Time to move everything to ARM

  • Even we, as humans are full of vulnerabilities which nature exploits every day.

  • NeoonNeoon Community Contributor, Veteran

    Well, move everything to dedis, and you be fine.

  • Move to RISC-V

    Thanked by 1rm_
  • jsgjsg Member, Resident Benchmarker
    edited August 2018

    @Clouvider said:
    That affects AMD as well ?

    I guess yesno with a tendency towards no. Reasoning: Compatibility is quite tight a frame which means that AMD is all but bound to have quite some flaws in common. On the other hand AMD unlike intel really could do a relatively fresh start. So I wouldn't bet my house on AMD being more secure but it's quite probably a bit less f*cked up than the intel situation.

    @jiggawattz said:
    Time to move everything to ARM

    The speed of evolution there alone is all but a guarantee for some really ugly stuff. Plus of course the beloved trust zone monster ...

    @Jona4s said:
    Move to RISC-V

    Sounds nice and I would sign the dotted line if only there were not that big fat "but" of being immature, not even finished, and no products available but beta stuff and some dev. toys.


    What really p*sses me off is intel's nonchalant attitude and PR. Just read the link in OP. Sounds all nice but looking closer there are many thinly veiled ugly conditions and ifs. My favourite "if ALL virtualized systems are updated".

    Also note that when intel blurbs about "partners having fixes" what they mean is the REALLY BIG manufacturers and integrators and only relatively recent processors - and of course all providers properly firmware updating and all OSs/distros microcode updating all nodes, machines, systems ...

    In other words: intels worry isn't you or even really a solution but simply a fixed problem - well noted "problem" meaning THEIR image and share value.

    The good news is that AMD will "soon" launch a new EPYC generation ("Rome" iirc) and EPYC also takes on with large manufacturers/brands like HP, Cisco, Dell.

    IMO it would have been much smarter for intel to not care about with whom their Ex-CEO was fcking around but to make sure that their CPUs don't fck everybody.

  • I bet A.I run on Intel could fix this vulnerability itself.

  • mkshmksh Member

    @Chuck said:
    I bet A.I run on Intel could fix this vulnerability itself.

    Wat?

    Thanked by 1Aidan
  • Intel has larger market share, thus it is being targeted most of the time. I am guessing AMD has other issues and their vulnerability would be found as well if it is the bigger target.

  • It seems the possibility of a practical attack is very thin. So the take home message for me is to add l1tf=off to the kernel parameter on all KVM hypervisors on next kernel upgrade.

  • rm_rm_ IPv6 Advocate, Veteran
    edited August 2018

    Foreshadow-NG might also be used to read information stored in other virtual machines running on the same third-party cloud, presenting a risk to cloud infrastructure.

    With the rate and scale at which these keep popping up, it seems quite possible that someday soon there's another vulnerability which renders multi-customer VPS hosting as a concept completely unviable (insecure), and that can't be fixed short of replacing the CPUs. I'd suggest everyone to keep at least one cheap dedi handy, and migrate the most sensitive stuff to it even today, not to mention when a doomsday scenario like that hits.

    Thanked by 2Janevski mksh
  • LeviLevi Member

    No real world practical example is shown. 'probably vulnerable' doesn't cut it.

  • @LTniger said:
    No real world practical example is shown. 'probably vulnerable' doesn't cut it.

    I'm thinking the same. Pics or it didn't happen, as they say.

  • SplitIceSplitIce Member, Host Rep

    @rm_ said:
    With the rate and scale at which these keep popping up, it seems quite possible that someday soon there's another vulnerability which renders multi-customer VPS hosting as a concept completely unviable (insecure), and that can't be fixed short of replacing the CPUs. I'd suggest everyone to keep at least one cheap dedi handy, and migrate the most sensitive stuff to it even today, not to mention when a doomsday scenario like that hits.

    I had a similar shower thought the other day. It would suck to give up all the convenience that DigitalOcean, Vultr and kind provide though.

  • JanevskiJanevski Member
    edited August 2018

    @rm_ said:

    Foreshadow-NG might also be used to read information stored in other virtual machines running on the same third-party cloud, presenting a risk to cloud infrastructure.

    With the rate and scale at which these keep popping up, it seems quite possible that someday soon there's another vulnerability which renders multi-customer VPS hosting as a concept completely unviable (insecure), and that can't be fixed short of replacing the CPUs. I'd suggest everyone to keep at least one cheap dedi handy, and migrate the most sensitive stuff to it even today, not to mention when a doomsday scenario like that hits.

    I would love to see that happen, just for the sheer drama.

    And i know after a while we'll find a way to deal with it and life goes on as usual.

    Overcoming obstacles causes evolution.

  • jsgjsg Member, Resident Benchmarker
    edited August 2018

    @LTniger said:
    No real world practical example is shown. 'probably vulnerable' doesn't cut it.

    If someone like intel makes a press release about a vulnerability that IS a confession,

    @rm_ said:

    Foreshadow-NG might also be used to read information stored in other virtual machines running on the same third-party cloud, presenting a risk to cloud infrastructure.

    With the rate and scale at which these keep popping up, it seems quite possible that someday soon there's another vulnerability which renders multi-customer VPS hosting as a concept completely unviable (insecure), and that can't be fixed short of replacing the CPUs. I'd suggest everyone to keep at least one cheap dedi handy, and migrate the most sensitive stuff to it even today, not to mention when a doomsday scenario like that hits.

    I think your take is realistic - but there's a but: hosting is a multi billion $ business. The way I see it there are two possible routes. Either intel gets their act together and survives ... or they don't and will go down. The latter would be less tragic than one might think; there's Arm (not really much better), there's Risc-V (a little too early yet), and there's Power and Sparc, very well mastered and well proven architectures that have been taken care of and developped further by IBM (and Lenovo?), Fujitsu and Oracle (Yes, I know, "Oracle" and "taking care of" in one paragraph sounds strange) and that also spawned some more evolutions.

    So my take is that if intel went down (and in fact even right now albeit only by some) the scenario would somewhat split into three paths: (a) AMD for those who want or need, if any possible, to stay with the architecture, (b) Arm (and later Risc-V) for the lower end of the market, and (c) a big return to Sparc on the more professional end of the market. The OS selection is somewhat thinner but there ARE some OS available for those alternatives. And, low and behold, Oracle just so happens to think about getting out of the processor business (translation: someone will buy it or it will be spawned off. And as there is also Fujitsu Oracle doesn't have a monopoly and can't play too dirty a game). Why my hunch points to Sparc? (a) They already are well accepted in the higher end of the market, (b) some open source (thanks to Sun), (c) Power always was and is there but somehow failed to be a really major player.

    If push comes to shove (and bet you that some companies are already thinking in that direction) for example (even "old") S7 based systems (especially S7-2L) could take over the load of many Xeon systems tomorrow morning even at about the same cost.

  • raindog308raindog308 Administrator, Veteran

    jsg said: and there's Power and Sparc, very well mastered and well proven architectures that have been taken care of and developped further by IBM (and Lenovo?), Fujitsu and Oracle (Yes, I know, "Oracle" and "taking care of" in one paragraph sounds strange) and that also spawned some more evolutions.

    I believe the POWER chipset is exclusive to IBM. It powers their mainframes iSeries aka AS/400, and pSeries AIX-based stuff. It's a great chip but of course stratospherically expensive and only works in one manufacturer's hardware, so everything else is hugely expensive as well.

    jsg said: Power always was and is there but somehow failed to be a really major player.

    The mainframe market alone makes POWER a major player, but you're still right because it's only a player in IBM's walled ecosystem. I think at one point Sony or someone used POWER for consoles but that was a long time ago. So it's a big deal if you're an old-line IBM enterprise customer...and you don't care if you're not.

    I'm less optimistic on SPARC. Oracle has completely killed the SPARC engineering team and the M8 is their last SPARC system. After buying Sun, they had contractual obligations to governments, etc. to continue supporting SPARC, so they kept the lights on and let the R&D run on momentum. But they've made no real investments there in a long time. Solaris is dead and nearly all the people supporting it were axed last year.

    Fujitsu still makes SPARC and I haven't followed because...who cares. But last time I looked it got considerably more vague after 2018 with a "future generation" coming in 2020. Maybe...

    Thanked by 1jsg
  • jsgjsg Member, Resident Benchmarker

    @raindog308 said:
    I believe the POWER chipset is exclusive to IBM. It powers their mainframes iSeries aka AS/400, and pSeries AIX-based stuff. It's a great chip but of course stratospherically expensive and only works in one manufacturer's hardware, so everything else is hugely expensive as well.

    Yes and no. Probably there are major limitations and string attached but I know of at least one other power architecture: Freescale (now NXP).

    Of course you are right and most probably IBM kept the non-industrial and especially the server market for themselves but still it's helpful if a given architecture is at least partly avaliable elsewhere too.

    I'm less optimistic on SPARC. Oracle has completely killed the SPARC engineering team and the M8 is their last SPARC system. After buying Sun, they had contractual obligations to governments, etc. to continue supporting SPARC, so they kept the lights on and let the R&D run on momentum. But they've made no real investments there in a long time. Solaris is dead and nearly all the people supporting it were axed last year.

    Fujitsu still makes SPARC and I haven't followed because...who cares. But last time I looked it got considerably more vague after 2018 with a "future generation" coming in 2020. Maybe...

    Again yes and no. Yes, Oracle has badly butchered the Sparc eco system. But there's still an OpenSolaris world albeit one with VERY little Sparc dev. and mostly sold out to x86 plus there are of course diverse other Unices (and quasi-unices like linux).

    More importantly the hardware side was (thank God!) not exclusively depending on Oracle who were the major but by far not the only player. As mentioned there is also Fujitsu - who made THEIR OWN designs too - and there are a healthy Sparc proc. communities mainly in Russia and China (e.g. one of the famous chinese super computers is based on a modern Sparc processor designed in China).

    And btw. I'd choose an M8 (or even an M7) every day and twice on sundays over Xeon and bet you my system would not be weaker or slower than someones Xeon server.

    Which brings me to another important point: much of that (incl. exotic variants like the ESA "Leon") are based on Sun's open sourced T1 and T2 design. Now look at the gate size then and today. Merely adapting the T2 to a modern but still not too expensive gate size, say 28 nm, plus a bit of engineering (e.g. larger cache sizes, faster mem. interfaces) will give you something that, two of them in a casing, would be quite competitive with an Arm or even Xeon especially for typical server loads in hosting.

    To make it short: 2 modernized T2, around 30 nm in a processor casing and you'd have something like 128 (hardware!) threads, 16 MB, L2 cache, 512+ GB memory, 2 x 10 Gb ethernet, ...

    Is that feasible and realistic? Looking at what diverse "minor" players in Russia, China, and elsewhere had achieved even, say 5 years ago: yes, absolutely.

    Finally I see a VERY considerable advantage for Sparc (against Power) because thanks to Sun open-sourcing it (and quite many picking that up and developing based on it) translates to MUCH more and better available know-how. Having that know-how available would be the live-or-die difference if one needed to abort the x86.

    All that said I still wish AMD the best and a lucky hand alone for the fact that not changing architecture would still be the easiest and most convenient. At the same time I don't trust x86 any more; there's too much crap beginning with creepy management engines and not ending with security nightmares in the processors, and Arm seems to not be any better but just different.

    Thanked by 1mksh
  • AnthonySmithAnthonySmith Member, Patron Provider

    A new kernel hit the CentOS 7 repos not so long ago which mitigates some of this, still no microcode/bios updates from SM or Dell, I assume (hope) that will follow within 24 hours or so.

    Only mitigation so far I am aware of is to simply disable hyper-threading, or use core scheduling through CPU affinity and put each guest in their own isolated group the cost of which on performance would be probably worse than just disabling hyper-threading by a significant margin.

    At least it is not in the wild yet or remotely exploitable.

  • I am a little suspicious on the timing of continuously revealing those vulnerabilities, that do exist for much longer... Maybe I just wear my tin foil hat, but I thing the public expose of the issues is not random or innocent.

    Thanked by 1Janevski
  • LOL mitigation of this includes disabling Intel Hyperthreading https://access.redhat.com/security/vulnerabilities/L1TF-perf

    Third: Disabling Hyper-Threading
    The performance impact from disabling Hyper-Threading (HT) varies widely. Disabling HT reduces the number of available vCPUs by 50%, which reduces the scale of virtualized environments. The Red Hat products that use KVM (Red Hat Virtualization and Red Hat OpenStack) are affected, as are OpenShift-on-OpenStack environments.

    Red Hat’s performance testing on Intel hardware is consistent with Intel’s published data on Hyper-Threading. The performance impact when HT is disabled is dependent on many factors. Measured impact ranges from a +30% gain, to -50% loss and beyond. Most HT testing, however, showed losses in the 0-30% range.

    Disabling HT in environments with less than ~50% cpu utilization usually showed no performance impact. Disabling HT in environments with higher cpu utilization yields a serious performance drop. The amount of loss was usually dependent on the cpu utilization before HT was disabled.

  • Heh, this could be why Intel decided to disable HyperThreading on the new 9th gen processors on all lines except the i9.

    Or they just decided they wanted more money. Who am I to say?

  • An update from DO https://blog.digitalocean.com/a-message-about-l1tf/

    “Remediation efforts will be completed within a few weeks”

  • mkshmksh Member

    @Ole_Juul said:

    @LTniger said:
    No real world practical example is shown. 'probably vulnerable' doesn't cut it.

    I'm thinking the same. Pics or it didn't happen, as they say.

    The problem here is that those parties that likely invest to most time and resources into getting those pics are also the ones most unlikely to share them. There is a ton of money to be made and it is in using these exploits not informing people about them.

  • mksh said: The problem here is that those parties that likely invest to most time and resources into getting those pics are also the ones most unlikely to share them. There is a ton of money to be made and it is in using these exploits not informing people about them.

    You are quite right. I was thinking that perhaps there were people who had actually gotten hacked. They might be more interested in sharing.

  • @rm_ said:

    Foreshadow-NG might also be used to read information stored in other virtual machines running on the same third-party cloud, presenting a risk to cloud infrastructure.

    With the rate and scale at which these keep popping up, it seems quite possible that someday soon there's another vulnerability which renders multi-customer VPS hosting as a concept completely unviable (insecure), and that can't be fixed short of replacing the CPUs. I'd suggest everyone to keep at least one cheap dedi handy, and migrate the most sensitive stuff to it even today, not to mention when a doomsday scenario like that hits.

    At least it will be a slap on the wrist to anyone who actually believed that VPSes were secure lol

Sign In or Register to comment.