英特尔芯片漏洞事件

By: Laura Reeve, Mariana Dematte, Gaspard Etienne, Chloe Kaubisch

创建人:劳拉·里夫(Laura Reeve),玛丽安娜·德玛特(Mariana Dematte),加斯帕德·艾蒂安(Gaspard Etienne),克洛伊·考比施(Chloe Kaubisch)

Boston University CS558 Security News Project

波士顿大学CS558安全新闻项目

In May, Intel informed the public about a new class of vulnerabilities called Microarchitecture Data Sampling (MDS), and released a patch for those who affected by it. However, later in the same year Intel has come under fire for releasing a new patch for the same vulnerabilities that they claimed to have mitigated months ago. The story includes a few different research groups, each that discovered one category of MDS vulnerabilities and disclosed to Intel. At the center of this news is a group of researchers at Vrije Universiteit Amsterdam’s Security Group (VUSec), who discovered RIDL (Rogue In-Flight Data Load), a major vulnerability in Intel’s processors, and disclosed it to Intel in September 2018.

今年5月,英特尔向公众通报了一种称为微体系结构数据采样(MDS)的新型漏洞,并为受此漏洞影响的人们发布了一个补丁。 但是,同年晚些时候,英特尔因发布了一个新的补丁程序而受到抨击,这些补丁程序与他们几个月前声称已缓解的漏洞相同。 这个故事包括几个不同的研究小组,每个研究小组发现了一类MDS漏洞并向英特尔披露。 该新闻的重点是阿姆斯特丹弗里耶大学安全小组(VUSec)的一组研究人员,他们发现了RIDL(Rogue In-Flight Data Load),这是英特尔处理器的主要漏洞,并于2018年9月向英特尔披露。

After disclosing the new information to Intel, they received little feedback until four days prior to Intel’s public disclosure of their patch in May 2019. Upon revision of the patch, the researchers quickly realized that the patch would be insufficient and fail to cover all known vulnerabilities. Intel then requested that VUSec not disclose the findings to the public for another 6 months, and additionally asked them remove any mention of the unpatched vulnerabilities from a paper they had planned to present at an upcoming security conference. The research team reluctantly agreed in order to avoid the vulnerability becoming public without a viable fix and mitigate potential attacks.

在向英特尔披露了新信息之后,直到英特尔在2019年5月公开披露其补丁程序的四天之前,他们几乎没有收到反馈。研究人员对该补丁程序进行修订后很快意识到,该补丁程序将不足以弥补所有已知漏洞。 。 英特尔随后要求VUSec再过六个月不向公众披露调查结果,并要求他们从计划在即将举行的安全会议上发表的论文中删除对未修补漏洞的任何提及。 研究团队无奈地同意,以避免在没有可行修补程序的情况下使漏洞公开,并减轻潜在的攻击。

Later in the year, when the second patch was due to be released in November 2019, Intel repeated the same behaviour, asking for more time and yet another embargo. This time, the researchers refused to keep the existence of these vulnerabilities under wraps and went public. It was then that many news outlets, including Wired, The Verge, Tech Crunch, and the New York Times, picked up the story. Technical publications focused more on the details of the vulnerabilities, but both technical and non technical outlets focused their stories on the root problem: Intel was misleading the public.

在今年晚些时候,第二个补丁程序定于2019年11月发布时,英特尔重复了同样的行为,要求更多时间和另一次禁运。 这次,研究人员拒绝掩盖这些漏洞的存在,并公开发布。 那时,包括Wired,The Verge,Tech Crunch和《纽约时报》在内的许多新闻媒体都对此进行了报道。 技术出版物将重点更多地放在了漏洞的细节上,但是技术和非技术媒体都将其故事集中在根本问题上:英特尔误导了公众。

It is worth noting that most of the news are about RIDL and VUSec, since they were the main research group to disclose the information to the public. However, this is not the whole story: the MDS vulnerabilities stem from four different classes of vulnerabilities, the others of which were discovered by various groups of researchers at roughly at the same time as RIDL.

值得注意的是,大多数新闻都是关于RIDL和VUSec的,因为它们是向公众公开信息的主要研究小组。 但是,这还不是全部内容:MDS漏洞来自四类不同的漏洞,其中几类是在与RIDL大致同时的同时由各种研究人员发现的。

Focusing a bit more on the technical aspect of the vulnerability: MDS is a broad superclass that encompasses RIDL, ZombieLoad, and Fallout, all of which were discovered in Intel processors by researchers in the past year and a half. They all stem from a core issue with the way Intel processors handle and store data, which allows an adversary to access private data. The main target of the attack are the buffers within the chip, where most of the memory that is being transferred between processors or used by a process goes through. However, these buffers are not protected from any attack, since they work on the assumption that no untrusted code can access the information on them.

更多地关注漏洞的技术方面:MDS是一个广泛的超类,包括RIDL,ZombieLoad和Fallout,在过去的一年半中,研究人员在英特尔处理器中发现了所有这些超类。 它们全都源于英特尔处理器处理和存储数据的方式的核心问题,该问题使对手可以访问私有数据。 攻击的主要目标是芯片内的缓冲区,处理器之间正在传输的或进程使用的大部分内存都经过该缓冲区。 但是,这些缓冲区不受任何攻击的保护,因为它们假定没有不受信任的代码可以访问有关它们的信息,因此它们无法工作。

The vulnerabilities and attacks are based on “speculative execution” optimization strategy, where the processor starts processing tasks that have not been defined as needed or unneeded. If the task is seen as unneeded extra work, it is discarded, but if the task is seen as necessary, the processor got a speed up from already executing that task. Most modern CPUs do this process by using multiple threads to execute the possible code blocks. After the conditional expression has been evaluated the thread corresponding to that condition is taken and the other threads are discarded. The issue that arose with the intel processors with this vulnerability is that this information was not discarded correctly, allowing adversaries to collect any information that was not part of the program to flow through a side channel.

漏洞和攻击基于“推测执行”优化策略,在该策略中,处理器开始处理尚未根据需要或不需要定义的任务。 如果该任务被视为不需要的额外工作,则将其丢弃,但是如果该任务被视为必要,则处理器将从已经执行该任务的速度中受益。 大多数现代CPU通过使用多个线程来执行可能的代码块来执行此过程。 在对条件表达式求值之后,将采用与该条件相对应的线程,并丢弃其他线程。 具有此漏洞的intel处理器引起的问题是,此信息未正确丢弃,从而使对手可以收集不属于程序一部分的任何信息,以流经旁通道。

The different attacks follow the same general intuition, but they each target different buffers within the chip.

不同的攻击遵循相同的常识,但是它们各自针对芯片内的不同缓冲区。

RIDL targets the line fill buffer of processes when two processes are running on the same hardware. When the data is accessed by the victim process, the attacker can use the given information to make guesses and access the victim’s part of the buffer, and access that data. After the attacker discovers the location of the information on the buffer, they can continue accessing it while the victim’s processes are in progress, giving the attacker access to all the information that the victim is seeing and requesting in real time. This is generally impossible, as different processes live in different address spaces and cannot directly access any other process’s data except if expressly allowed by the operating system. With this vulnerability, one can use a side channel to bypass the operating system completely and interact with the leftover data of the other process. This means that the attacker will gain access to everything from current browser page to SSH keys and passwords. When using only a single thread, this attack can be prevented with the tweak of low level chip code, which was mostly mitigated by Intel on the first patch. When multithreading, a security measure that the user can take is disabling Intel HyperThreading on their machines. Intel has currently not patched the multithreaded version of this vulnerability.

当两个进程在同一硬件上运行时, RIDL会以进程的行填充缓冲区为目标。 当受害者进程访问数据时,攻击者可以使用给定的信息进行猜测,并访问受害者的缓冲区部分,然后访问该数据。 攻击者发现缓冲区中信息的位置后,他们可以在受害者的进程正在进行时继续访问它,从而使攻击者可以实时访问受害者正在查看和请求的所有信息。 通常这是不可能的,因为不同的进程位于不同的地址空间中,并且除非操作系统明确允许,否则无法直接访问任何其他进程的数据。 有了此漏洞,一个人可以使用辅助通道完全绕过操作系统,并与另一个进程的剩余数据进行交互。 这意味着攻击者将获得从当前浏览器页面到SSH密钥和密码的所有访问权限。 当仅使用单个线程时,可以通过对底层芯片代码进行微调来防止这种攻击,这在第一个补丁程序中主要由Intel缓解。 使用多线程时,用户可以采取的一项安全措施是在其计算机上禁用Intel HyperThreading。 英特尔当前尚未修补此漏洞的多线程版本。

Video by RIDL researchers capturing data from another process using JavaScript and WebAssembly
RIDL研究人员的视频使用JavaScript和WebAssembly从另一个过程捕获数据

Fallout is another vulnerability discovered by research groups, and it was actually made possible by the patches for Meltdown. This vulnerability targets the store buffers; more specifically, it attacks the fact that the store buffers don’t check for permissions before accessing memory. The attack is based on the behaviour of the Write Transient Forwarding (WTF) function on the system. When an address needs to be read from memory, the CPU must check the store buffer for writes on that same address. However, if there is no match for the address, WTF is called to handle the partial address matching. That means that if the lower bits of the wrong address match a previous load, the processor assumes that it is the same physical location and reads from there. This can be exploited by sending a wrong address that will partially match to something. From there the attacker is able to find information that they need to attack the system. The example given on the paper was an attack that used WTF to discover where the AES context is on the address and then get the encryption key.

辐射是研究小组发现的另一个漏洞,实际上是通过Meltdown补丁使之成为可能的。 此漏洞的目标是存储缓冲区。 更具体地说,它攻击了以下事实:存储缓冲区在访问内存之前不检查权限。 攻击是基于系统上的写瞬态转发(WTF)功能的行为。 当需要从内存中读取地址时,CPU必须检查存储缓冲区以查找对该相同地址的写入。 但是,如果地址不匹配,则调用WTF来处理部分地址匹配。 这意味着,如果错误地址的低位与先前的负载匹配,则处理器将假定它是相同的物理位置并从那里读取数据。 可以通过发送错误的地址来部分利用该地址,从而利用该地址。 攻击者可以从那里找到攻击系统所需的信息。 本文中给出的示例是一种攻击,该攻击使用WTF来发现AES上下文在地址上的位置,然后获取加密密钥。

ZombieLoad was discovered by a group of researchers at Graz University of Technology and is identified by two variants. ZombieLoad v1, like many other MDS attacks, exploits how speculative execution normally works within micro-architectural structures to infer data that is being processed in the CPU. ZombieLoad was feared as the worst of the MDS attacks because of the amount of data it was able to retrieve. Microcode updates by Intel provided protections against speculative execution attacks to counteract MDS attacks. Attacks such as RIDL and Fallout would not work in single threaded applications running on new lines of processors from Intel. The same researchers then published a second variant of ZombieLoad, nicknamed ZombieLoad v2. This variant could be executed on any Intel’s CPU which supports the Intel TSX instruction-set extension. The research team has said that this instruction-set extension is available by default in all Intel CPUs sold since 2013. Even the ones Intel claimed had protections against speculative execution attacks baked in at the hardware level. The Zombieload v2 attack exploits the Intel Synchronization Extensions (TSX) Asynchronous Abort (TAA) operation that occurs when there is a conflict between read operations inside a CPU. Read conflicts for TAA operations leaks data about what’s being processed inside an Intel CPU. This data in turn can be exploited in the same manner as the original ZombieLoad variant.

ZombieLoad是由格拉茨工业大学的一组研究人员发现的,并有两种变体。 与许多其他MDS攻击一样,ZombieLoad v1利用推测性执行通常在微体系结构中的工作原理来推断正在CPU中处理的数据。 人们担心ZombieLoad是最严重的MDS攻击,因为它能够检索的数据量很大。 英特尔的微码更新提供了针对投机执行攻击的防御措施,以抵消MDS攻击。 像RIDL和Fallout这样的攻击不适用于在英特尔新处理器系列上运行的单线程应用程序。 随后,同一位研究人员发布了ZombieLoad的第二个变体,绰号为ZombieLoad v2。 该变体可以在任何支持Intel TSX指令集扩展的Intel CPU上执行。 研究团队表示,自2013年以来,所有售出的Intel CPU均默认提供此指令集扩展。甚至Intel声称具有保护功能的组件,也可抵御在硬件级别引发的投机执行攻击。 Zombieload v2攻击利用了Intel同步扩展(TSX)异步中止(TAA)操作,该操作在CPU内的读取操作之间发生冲突时发生。 TAA操作的读取冲突会泄漏有关Intel CPU内部正在处理的数据。 反过来,可以使用与原始ZombieLoad变体相同的方式来利用此数据。

https://zombieloadattack.com/public/videos/demo_720.mp4

https://zombieloadattack.com/public/videos/demo_720.mp4

The main focus of the lay press has been Intel’s failure to responsibly disclose their issues to the public. The sequence of events behind the patches that VUSec revealed has brought to light several ethical concerns, namely corporate responsibility to customers, transparency, and appropriate security engineering. Intel had full knowledge of the above classes of insecurities since they were disclosed to them by several independent research groups in early 2018. Ideally, at this point in time, Intel would have performed a thorough root cause analysis, found the core of these problems, fixed them in an appropriate amount of time, and released a patch to the public when it was safe to do so. Instead, Intel repeatedly misled their users by implying that each successive patch covered all known vulnerabilities. As a result, there were long stretches of time during which users thought they were secure, while Intel and the groups of researchers involved knew that they were not. While it is undoubtedly appropriate for a company to keep an insecurity under wraps while it is being patched, Intel repeatedly failed to address the problem in its entirety, despite having ample information and time to do so. Additionally, during this time (September 2018 — November 2019, in the case of RIDL), despite the best efforts of Intel and VUSec, information about the MDS vulnerabilities leaked. While there were no known MDS exploits during this time, there easily could have been, leaving users not only vulnerable but unaware.

外行新闻的主要焦点是英特尔未能以负责任的态度向公众披露他们的问题。 VUSec揭示的补丁程序背后的事件序列揭示了一些道德问题,即公司对客户的责任,透明度和适当的安全工程。 自从2018年初几个独立的研究小组向他们披露了上述不安全因素后,英特尔就对它们进行了充分的了解。理想情况下,在此时,英特尔将进行彻底的根本原因分析,找出这些问题的根源,在适当的时间内修复它们,并在安全的情况下向公众发布补丁。 相反,英特尔暗示每个后续补丁都涵盖了所有已知漏洞,从而一再误导用户。 结果,在很长一段时间内,用户认为他们是安全的,而英特尔和相关研究人员知道他们并非安全。 虽然毫无疑问,公司在进行补丁修补时要掩盖不安全因素,但尽管有足够的信息和时间来解决问题,但英特尔反复未能整体解决该问题。 此外,在此期间(对于RIDL,在2018年9月至2019年11月),尽管英特尔和VUSec尽了最大努力,但有关MDS漏洞的信息还是泄漏了。 尽管在此期间没有已知的MDS漏洞利用,但很容易就已经存在,从而使用户不仅易受攻击,而且无意识。

The New York Times interviewed several members of the research team, and VUSec also wrote their own post in addition to the RIDL paper, extensively detailing the sequence of events and their ongoing concerns. Something brought up again and again was their assertion that Intel had not, and continues not to respond responsibly to the MDS vulnerabilities disclosed to them. For one, Intel did not communicate well with them between September 2018 and May 2019, only releasing the full details of the patch four days prior to its release, and apparently overlooking some of the proof of concept exploits that had been provided to them. Essentially, according to VUSec, instead of addressing the heart of the problem, which could potentially require redesigning the entire processor, Intel has been patching these issues as they crop up. A member of the team describes being frustrated by Intel’s inability to extrapolate on proof-of-concept exploits to find others beyond those that had been directly disclosed to them — the concern being that there are almost certainly more undiscovered vulnerabilities, and Intel’s failure to exhaustively look for and fix these vulnerabilities leads to incomplete patches like those released in May and November.

《纽约时报》采访了研究团队的几名成员,除了RIDL论文外,VUSec还写了自己的文章,详细介绍了事件发生的顺序及其持续存在的问题。 他们一次又一次提出了自己的主张,即英特尔没有,并且继续对所披露的MDS漏洞不负责任地作出回应。 一方面,英特尔在2018年9月至2019年5月之间与他们的沟通不佳,仅在补丁发布前四天发布了补丁的全部细节,并且显然忽略了已提供给他们的一些概念验证漏洞。 从本质上讲,根据VUSec的说法,英特尔没有解决可能会要求重新设计整个处理器的问题核心,而是一直在解决这些问题。 团队的一名成员对英特尔无法推断概念验证漏洞的发现感到沮丧,因为该漏洞无法找到直接披露给他们的漏洞–担心的是几乎肯定还有更多未被发现的漏洞,以及英特尔未能彻底穷举查找并修复这些漏洞会导致补丁程序不完整,例如5月和11月发布的补丁程序。

While Intel claims that there have been no known attacks exploiting this vulnerability, it is possible that this is not 100% true, since the attacks of this type do not leave a mark. Given the numerous ethical problems with Intel’s response to the discovery of MDS vulnerabilities, one major question remains: how do we hold Intel legally accountable for their lack of action taken against threats to their users?

尽管英特尔声称没有利用此漏洞的已知攻击,但可能并非100%正确,因为这种类型的攻击没有留下任何痕迹。 鉴于英特尔对发现MDS漏洞的React存在许多道德问题,一个主要问题仍然存在:我们应如何对英特尔缺乏针对用户威胁采取的行动追究法律责任?

There is no clear-cut answer to this issue, as liability for security flaws is often seen on a case-by-case basis. Other than backlash from upset researchers and users, Intel did not face any legal repercussions for their dismissal of the problems. There is currently no legislation for companies handling vulnerability in a timely manner. However, there should be some level of accountability for companies who are given notice of vulnerabilities. They should not wait for the problems to be exploited, but should rather respond and fix the issues as soon as possible. Although it’s true that software will always have potential security holes and we don’t necessarily think that these companies should be strictly liable, these companies should be held accountable for negligence.

对于该问题没有明确的答案,因为通常会逐案考虑对安全漏洞的责任。 除了遭到沮丧的研究人员和用户的强烈反对外,英特尔因解雇这些问题没有受到任何法律影响。 当前没有针对公司及时处理漏洞的法律。 但是,对于被告知存在漏洞的公司,应该进行一定程度的问责。 他们不应等待问题被利用,而应尽快做出响应并解决问题。 尽管确实有软件总是存在潜在的安全漏洞,并且我们不一定认为这些公司应严格承担责任,但应该对这些公司承担过失责任。

In the US, there are many different standards for liability that companies or individuals can be held to, but we will look at two options: strict liability and negligence. Strict liability means that an entity will be held responsible for negative effects of their product or service even if they did all they could do to prevent these outcomes. (https://www.personalinjury.com/topic/negligence-vs-strict-liability). Strict liability is often applied for inherently dangerous products and services; excavating, explosives, and construction are a few examples. Negligence, on the other hand, is when a company or individual fails to exercise reasonable care and caution. We see it brought up in everything from unsafe products, to neglecting people in one’s care, to dangerous use of equipment. If there were any attacks due to these vulnerabilities, Intel should have been held liable, but even without attacks, they’re still neglecting to fix issues that could have very serious consequences for their users.

在美国,公司或个人可以遵循许多不同的责任标准,但我们将研究两种选择:严格责任和过失。 严格责任意味着实体将为自己的产品或服务的负面影响负责,即使他们竭尽所能防止这些结果。 ( https://www.personalinjury.com/topic/negligence-vs-strict-liability )。 严格责任通常适用于固有的危险产品和服务; 挖掘,炸药和建筑就是几个例子。 另一方面,过失是指公司或个人未能给予合理的照顾和谨慎。 从不安全的产品到忽视人们的照顾,再到危险的设备使用,我们看到了它的出现。 如果由于这些漏洞而有任何攻击,英特尔应该承担责任,但是即使没有攻击,他们仍然忽略修复可能对其用户造成严重后果的问题。

If there existed a negligence standard that tech companies were held to, it would prevent problems like this one, in which a company is warned of an issue, but does not respond appropriately because they’re hedging their bets. The lack of accountability when it comes to vulnerabilities allows these companies to be negligent without any repercussions as long as nothing goes awry. There are many cases in which individuals and companies have gotten into legal trouble due to negligence even before something goes wrong and tech companies should be held to these same standards. Rather than waiting for more vulnerabilities to be discovered, they should do their due diligence and exhaustively search for all instances of it, completely redesigning their product if necessary.

如果存在一个技术公司必须遵守的疏忽标准,它将防止出现此类问题,在这种情况下,公司会被警告出现问题,但由于他们在押注自己的赌注而不会做出适当的回应。 漏洞方面缺乏责任感,只要这些问题不解决,这些公司就可以毫不犹豫地疏忽大意。 在很多情况下,个人和公司甚至在出现问题之前就因疏忽而陷入法律纠纷,因此高科技公司应遵循相同的标准。 他们应该等待尽职调查并详尽搜索所有实例,而不是等待发现更多漏洞,并在必要时完全重新设计其产品。

This incident highlights one of the growing questions that we have with technology companies: how, and to what extent, do we hold them accountable for problems like these? There is no clear answer to this question, but it is simple to see that Intel was extremely negligent despite having the resources and time to fix the patches and notify users.

此事件凸显了我们与技术公司之间日益增长的问题之一:我们如何以及在多大程度上让他们对此类问题负责? 这个问题尚无明确答案,但很容易看出英特尔尽管有足够的资源和时间来修复补丁并通知用户,却极度疏忽。

This work was done without any outside collaboration.

这项工作无需任何外部合作即可完成。

Resources and Citations

资源和引文

https://mdsattacks.com/#ridl-ng

https://mdsattacks.com/#ridl-ng

https://www.techradar.com/news/intel-chip-security-flaw

https://www.techradar.com/news/intel-chip-security-flaw

https://www.nytimes.com/2019/11/12/technology/intel-chip-fix.html

https://www.nytimes.com/2019/11/12/technology/intel-chip-fix.html

https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/

https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/

https://www.vusec.net/

https://www.vusec.net/

https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling

https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling

https://zombieloadattack.com/zombieload.pdf

https://zombieloadattack.com/zombieload.pdf

https://mdsattacks.com/

https://mdsattacks.com/

翻译自: https://medium.com/@gaspardmicheletienne/intel-chip-security-flaw-3f851a572edb

英特尔芯片漏洞事件


http://www.taodudu.cc/news/show-3491103.html

相关文章:

  • G65SC802 与 G65SC816 指令集(按字母顺序排列) (转)
  • react学习小记
  • 服务器 16路直连 英特尔,16核超猛神U:Intel Xeon D-1587性能测试
  • 深入浅出学习 TypeScript 语言
  • 9S12汇编指令【HCS12】
  • Vue新搭档TypeScript快速入门实践
  • 在线 html 改成jsx,JSX · TypeScript中文网 · TypeScript——JavaScript的超集
  • 65C02指令集,寻址模式及其指令编码
  • NASM 全部指令「第一部分」
  • 关于win10系统如何调用debug查看CPU汇编指令和内存
  • 体系结构实验(1)—— 计算机性能评测
  • c语言进位加汇编指令,共同学习hcs08的汇编指令,快速掌握
  • 6800指令集
  • 硬件服务器processor是什么,服务器 CPU 8 Intel Core Processor (Haswell, no TSX) 指标说明...
  • 【转帖】超能课堂(186) CPU中的那些指令集都有什么用?
  • vue3.0实践之写tsx语法实例
  • 如何查看CPU指令集
  • Haswell多线程技术揭秘:Intel TSX扩展
  • Daily Life 01
  • 深圳免费停车场大全
  • 香港首条免费WiFi街道:逾90%试用者满意网速
  • unity Shader Lab(cg hlsl glsl)着色器入门教程 以及 vs2019 支持unity shader语法(更新中2019.9.5)
  • 边缘计算,5G时代新风口
  • 结构体NSPoint、NSRect、与NSSize或CG开头的详解
  • 2018 前端性能检查表
  • MaterialDesign系列文章(十一)Google2018年大会新出的控件汇总集合
  • Unity2018+cardboard 360度全景视频实现
  • 郑州大学2018年数据库复试试题
  • 2018-8-10-win10-uwp-气泡
  • DDCTF2018逆向 黑盒

英特尔芯片漏洞事件_英特尔芯片安全漏洞相关推荐

  1. 英特尔cpu发布时间表_英特尔10nm芯片开始大规模出货,先进制程时间表浮出水面...

    多年延期之后,英特尔终于宣布其 10nm 芯片产品开始大量出货. 近日,英特尔公布了公司 2019 年 Q3 财报.在财报会议中,英特尔透露了这一消息.具体而言,英特尔已有晶圆厂开始大批量生产 10n ...

  2. 英特尔凌动处理器_英特尔Daniel Rodriguez:驾驭2020云网融合浪潮 | 5G on IA

    本博客文章作者:Daniel Rodriguez 英特尔公司副总裁兼网络平台事业部总经理 释放跨云.网络和边缘数据的力量,为新业务的增长带来了巨大机遇.这是一个持续由新技术浪潮驱动的过程,并受到网络云 ...

  3. 英特尔10nm难产原因_英特尔宣称10nm“ Tiger Lake”笔记本电脑处理器将“跨越式发展”...

    英特尔10nm难产原因 At its 2020 Architecture Day event, the chip maker claimed its 10-nanometer process tech ...

  4. 英伟达TX2烧录系统_英伟达的DPU,是想在数据中心奇袭英特尔?

    热点追踪 / 深度探讨 / 实地探访 / 商务合作 最近几年,经常关注科技圈的朋友们总会发现,每次遇到厂商有重大发布,就总能看到"颠覆"."极致"." ...

  5. linux系统英伟达gpu驱动卸载_英伟达显卡驱动程序被发现强制捆绑 官方已火速撤回驱动下载链接...

    英伟达本周推出新版本驱动程序为多数游戏带来性能提升,不少玩家看到性能提升就果断选择下载新版进行安装. 不过有些意外的是这个版本的驱动程序强制捆绑各个组件,原本这些组件在用户选择自定义时是可以手动取消的 ...

  6. 英特尔显卡linux管理_英特尔二号人物被解雇:7nm全面落后,芯片还要外包代工...

    贾浩楠 发自 凹非寺 量子位 报道 | 公众号 QbitAI 昨天,英特尔宣布解雇二号人物.芯片业务主要负责人Murthy Renduchintala. 同时还全面重整了技术业务的架构. 原因,是英特 ...

  7. 英特尔显卡linux管理_英特尔 11 代酷睿大揭秘:这次全是大招

    英特尔在今年九月份正式推出了第 11 代酷睿移动处理器,这次英特尔将 10 纳米 SuperFin 工艺全面带到移动处理器上,同时还有全新的 Willow Cove 内核.Iris Xe 显卡.全新的 ...

  8. 英特尔cpu发布时间表_英特尔第11代桌面CPU将会支持PCIe4.0,Z490主板或可支持PCIe4.0...

    Hello大家好,我是兼容机之家的小牛. PCIe4.0在AMD平台上的X570芯片组中早已应用了,但是英特尔这边还没有一点动静,英特尔甚至还声称PCIe4.0没有用.不过终究架不住真香定律,近日,有 ...

  9. 英特尔凌动处理器_英特尔刷新Atom Denverton低功耗服务器CPU产品线

    外媒 CNX-Software 报道称,英特尔刚刚推出了凌动(Atom)C3000 系列 Denverton 处理器的刷新版本.作为 2016 年首次亮相的产品线,其主要被低功耗服务器主板和无风扇网络 ...

最新文章

  1. 你是否对它有一种责任感
  2. 用户管理之用户的查询获取
  3. 适合初学者的Python小游戏开发,不仅有趣还能巩固自己所学知识
  4. 打印html5中Canvas的方法
  5. IBM为世博会服务支持建立快速反应通道
  6. 一个简单案例教你如何用Typescript写Vuex
  7. JVM 调优实战--内存溢出的定位和MAT分析
  8. iOS-高仿支付宝手势解锁(九宫格)
  9. QQ空间登录参数分析Firefox+Firebug
  10. 顶级摄影师的磨皮美白利器Portraiture,支持搭配微设证件大师使用
  11. 2022年阿里云服务器租用价格表(最新收费标准及活动价格表)
  12. 中国移动----5G简介
  13. 公众号被关注后怎么发送多条自动回复消息?可以插入外链吗?
  14. Ueditor详细配置说明文档
  15. 如何选择自己心仪的U盘
  16. 自我激励--相信自己,付诸行动
  17. 通过 kubeadm 安装 k8s 1.14.1版本(master 单节点版)
  18. 乐视网改名新乐视;酷骑单车创始人否认解散团队;日本称今年捕杀177头鲸为研究丨价值早报
  19. MyCms 自媒体 CMS 系统 v2.6,SEO 优化升级
  20. 基于python的毕业设计学生兼职平台

热门文章

  1. jQuery(购物Demo)
  2. Bootstrap 方法。(统计学)
  3. 为啥c语言一亚索就无法运行,蓝鸥C语言学习第十一天
  4. 查看电脑系统(系统型号、显卡型号、声卡型号)等等
  5. (数据结构)二叉排序树的插入、删除
  6. 零基础:21天搞定Python分布爬虫视频教程直接下载
  7. python 创建后台守护进程
  8. 简单爱c语言音乐程序代码,Ubuntu下实现歌词解析,
  9. Spring Boot 如何使用 JUL 进行日志记录
  10. 什么是@Component,@Component的作用是什么