CNBC says Nvidia not affected by the leak. NO SHIT

[Drak3]

7 minutes ago, Cheddle said:

 

Is the Tegra X1 an ARM or an NVIDIA product?

Nvidia manufactured, and the final design changes are Nvidia's.

But it's based on ARM schematics.

[dalekphalm]

31 minutes ago, Cheddle said:

 

Is the Tegra X1 an ARM or an NVIDIA product?

Yes to both. 

 

ARM doesn’t manufacture any actual chips. They license the architecture out to others, who either make a straight up “clone”, or will modify the design to their own requirements. 

 

Examples of the latter are Nvidia Tegra-series chips, and Apple A-series chips. 

 

The Tegra X1 used ARM Cortex CPU cores, though I do believe they’ve made some modifications.

[Eduard the weeb]

Just because there both computer part maker don't mean there the same god damn company.

[Coaxialgamer]

I mean nvidia does make arm chips

[Coaxialgamer]

10 hours ago, dalekphalm said:

Think about what you just wrote.

 

"Arm x86-64" cores.

 

I think you meant "ARMv8-A 64/32" cores. The Switch has a Tegra X1 inside. The Tegra X1 has 4x Cortex A57 cores, and 4x Cortex A53 cores.

 

Both of those core types are ARMv8 64-bit CPU's.

 

x86 is a specific architecture type, used by Intel, AMD, and VIA. x86 is a CISC type architecture, while ARMv8 is a RISC type architecture.

 

Maybe you were thinking of NVIDIA's Project Denver, which supposedly could do real time x86 translations into ARMv8?

X86 is a risc architecture nowadays. And ARM isn't really RISC anyway, making the CISC vs RISC comparison meaningless. 

[8uhbbhu8]

CNBC. As always the source of the most important news available! /s

[Sniperfox47]

To be fair, while Nvidia's SoCs (i.e. Tegra chips) may be vulnerable, Nvidia's actual CPU cores (i.e. Denver) are, for the most part, not.

 

There's likely a modified attack you could do on Denver, but since they're not actually ARM, the ARM to Denver dynarec helps insulate them from the most dangerous parts of Specter.

 

Just to be clear, the A53/A57 cores in the X1 are designed by ARM. The Denver cores in Tegra K1 and Denver2 cores in the Tegra X2 are designed by Nvidia and don't really use the ARM ISA, despite running ARM code.

[dalekphalm]

12 hours ago, Sniperfox47 said:

To be fair, while Nvidia's SoCs (i.e. Tegra chips) may be vulnerable, Nvidia's actual CPU cores (i.e. Denver) are, for the most part, not.

 

There's likely a modified attack you could do on Denver, but since they're not actually ARM, the ARM to Denver dynarec helps insulate them from the most dangerous parts of Specter.

 

Just to be clear, the A53/A57 cores in the X1 are designed by ARM. The Denver cores in Tegra K1 and Denver2 cores in the Tegra X2 are designed by Nvidia and don't really use the ARM ISA, despite running ARM code.

Actually the X2 features 2x Denver cores, and 4x Cortex A57 cores.

 

So while the Denver cores may be immune, the A57 cores certainly wouldn't.

 

Also, with the K1, it depends on which variant you have. One variant has 4+1 Cortex A15 cores (T124 model). There's another variant that has 2x Denver cores (T132 model). The T124 model would therefore in theory be vulnerable, while the T132 model may or may not, depending on how the physical architecture actually works.

 

On 1/5/2018 at 11:46 PM, Coaxialgamer said:

X86 is a risc architecture nowadays. And ARM isn't really RISC anyway, making the CISC vs RISC comparison meaningless. 

Source?

[LAwLz]

4 hours ago, Pangea2017 said:

NVidia Tegra are still a deal. The focus have went from consumer electronic to embedded systems for example self driving cars. I belief GM, Tesla, Toyota and so on would not be happy to read in newspaper that there shiny new cars are unsafe.

Just look up what mainstream media coverage Jeep have had to deal with in 2015.

Tesla cars also have Tegra chips inside them.

 

 

2 minutes ago, dalekphalm said:

Also, with the K1, it depends on which variant you have. One variant has 4+1 Cortex A15 cores (T124 model). There's another variant that has 2x Denver cores (T132 model). The T124 model would therefore in theory be vulnerable, while the T132 model may or may not, depending on how the physical architecture actually works.

I wouldn't be surprised if Denver is vulnerable to some (modified) variant of Spectre. It will probably be quite hard to do though because of the code morphing. I doubt it will be investigated either. Probably not a big enough target.

[zheega]

nVidia is releasing their Spectre vulnerability update bulletin;  https://nvidia.custhelp.com/app/answers/detail/a_id/4611/related/1

 

Affected products and operating systems: everything and everything.

 

Quote

• Variant 1 (CVE-2017-5753): Mitigations are provided with the security update included in this bulletin. NVIDIA expects to work together with its ecosystem partners on future updates to further strengthen mitigations.

Quote

• Variant 2 (CVE-2017-5715): NVIDIA’s initial analysis indicates that the NVIDIA GPU Display Driver is potentially affected by this variant. NVIDIA expects to work together with its ecosystem partners on future updates for this variant.

Quote

• Variant 3 (CVE-2017-5754): At this time, NVIDIA has no reason to believe that the NVIDIA GPU Display Driver is vulnerable to this variant.

Updated drivers expected soon.

[Tech_Dreamer]

Facts First .

[Coaxialgamer]

14 hours ago, dalekphalm said:

 

Source?

Look it up, it's fairly well known at this point. 

X86 uses long,  complex, variable lenght instructions ( CISC). That makes it hard to do pipelining and use superscalar / OoOE. To make use of those features, intel created some sort of translation layer in hardware. Ever since the pentium pro (p6 architecture) and k5,  x86 instruction are broken down into simple, RISC micro OPS for the core to execute, which can be sent out if order and easily pipelined or executed in parralel. 

L1 Cache is broken into data and instructions caches, a hallmark of harvard (RISC). 

 

This was done to improve performance while maintaining compatibility with the x86 ISA. 

 

ARM is considered a RISC ISA, but features hallmarks of CISC, including multi cycle instructions and microcode. 

X86 also has these, so it can't be considered truly RISC either despite the RISC core. 

 

In fact, no ISA truly adheres to the original RISC or CISC concepts, making them hybrids of sorts.

 

[zheega]

New nVidia driver is out.

 

Quote

 

"Fixed CVE-2017-575"

Computer systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

 

 

 

 

No CVE-2017-5753 or CVE-2017-5715 fixes yet

 

http://www.guru3d.com/news-story/download-geforce-390-65-whql-driver.html

[dalekphalm]

6 hours ago, Coaxialgamer said:

Look it up, it's fairly well known at this point. 

X86 uses long,  complex, variable lenght instructions ( CISC). That makes it hard to do pipelining and use superscalar / OoOE. To make use of those features, intel created some sort of translation layer in hardware. Ever since the pentium pro (p6 architecture) and k5,  x86 instruction are broken down into simple, RISC micro OPS for the core to execute, which can be sent out if order and easily pipelined or executed in parralel. 

L1 Cache is broken into data and instructions caches, a hallmark of harvard (RISC). 

 

This was done to improve performance while maintaining compatibility with the x86 ISA. 

 

ARM is considered a RISC ISA, but features hallmarks of CISC, including multi cycle instructions and microcode. 

X86 also has these, so it can't be considered truly RISC either despite the RISC core. 

 

In fact, no ISA truly adheres to the original RISC or CISC concepts, making them hybrids of sorts.

 

Don't claim something and then tell me to look it up. We both know that's not how it works. If you make a claim, it's your responsibility to back it up.

 

With that in mind, you might well be correct, but I'm still going to need a source for that.

[Coaxialgamer]

11 minutes ago, dalekphalm said:

Don't claim something and then tell me to look it up. We both know that's not how it works. If you make a claim, it's your responsibility to back it up.

 

With that in mind, you might well be correct, but I'm still going to need a source for that.

here you go. The problem is that there isn't a single link to point to , which is why i asked to look it up , buti'll try .

from wikipedia https://en.wikipedia.org/wiki/X86

Quote

When introduced, in the mid-1990s, this method was sometimes referred to as a "RISC core" or as "RISC translation", partly for marketing reasons, but also because these micro-operations share some properties with certain types of RISC instructions. However, traditional microcode (used since the 1950s) also inherently shares many of the same properties; the new method differs mainly in that the translation to micro-operations now occurs asynchronously. Not having to synchronize the execution units with the decode steps opens up possibilities for more analysis of the (buffered) code stream, and therefore permits detection of operations that can be performed in parallel, simultaneously feeding more than one execution unit.

from http://sunnyeves.blogspot.fr/2009/07/intel-x86-processors-cisc-or-risc-or.html

Quote

Sometimes when you think that you know where things are heading, there will be a ground breaking invention that would change the entire scenario. One such seminal invental in the form of the introduction of high performance substrate (HPS) by the famous microarchitecture guru, Yale Patt. Although I am tempted to explain HPS in detail, I would rather consider it to be out of the scope of this blogpost. A very simple (not necessarily accurate) description would be that Patt succeeded in converting the CISC instruction to multiple RISC-like instructions or micro-ops.

Intel demonstrated its fast finger by implementing this in its P6 architecture. As any successful, innovative company, Intel is always good at adapting to the new wave. It did it by jumping from its memory business to microprocessor back in eighties and now it did it again by using HPS. Intel’s first IA-32-to-micro-op decoder featured in Pentium Pro. P6 architecture contained three parallel decoders to simultaneously decode the CISC instructions to micro-ops resulting in a deeply pipelined execution (see figure). Sometimes this instruction decoding hardware can become extremely complex. But as the feature size reduced at very fast rate, Intel did not face any significant performance issue with this approach.

 

from stackoverflow https://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors

Quote

Starting with Pentium Pro (P6 microarchitecture), Intel redesigned it's microprocessors and used internal RISC core under the old CISC instructions. Since Pentium Pro all CISC instructions are divided into smaller parts (uops) and then executed by the RISC core. At the beginning it was clear for me that Intel decided to hide new internal architecture and force programmers to use "CISC shell". Thanks to this decision Intel could fully redesign microprocessors architecture without breaking compatibility, it's reasonable. However I don't understand one thing, why Intel still keeps an internal RISC instructions set hidden for so many years? Why wouldn't they let programmers use RISC instructions like the use old x86 CISC instructions set? If Intel keeps backward compatibility for so long (we still have virtual 8086 mode next to 64 bit mode), Why don't they allow us compile programs so they will bypass CISC instructions and use RISC core directly? This will open natural way to slowly abandon x86 instructions set, which is deprecated nowadays (this is the main reason why Intel decided to use RISC core inside, right?). Looking at new Intel 'Core i' series I see, that they only extends CISC instructions set adding AVX, SSE4 and others.

 

[dalekphalm]

4 minutes ago, Coaxialgamer said:

here you go

from wikipedia https://en.wikipedia.org/wiki/X86

from http://sunnyeves.blogspot.fr/2009/07/intel-x86-processors-cisc-or-risc-or.html

 

from stackoverflow https://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors

 

Thanks! I'm going to read through all the links you provided (At least until my eyes start dying from reading too much lol).

[Coaxialgamer]

Just now, dalekphalm said:

Thanks! I'm going to read through all the links you provided (At least until my eyes start dying from reading too much lol).

problem was that there isn't a single link ( or even a couple ) that i could point to . Otherwise i would have in my original post .

The whole RISC vs CISC thing is extremely blurry , to the point that no architecture is truly one or the other.