조회 수 569 추천 수 0 댓글 0

단축키

Prev이전 문서

Next다음 문서

단축키

Prev이전 문서

Next다음 문서

Extra Form

인텔 Ice Lake에서는 이 과정을 최적화하기 위해서 FSRM(Fast Short Repeat Move)을 도입했습니다. 특정 조건을 만족한다면(복사할 메모리 길이가 작은 경우에 최적화됨) rep movsb 명령의 실행 속도를 벡터화된 메모리 복사 수준으로 개선하는 기능이죠. 그런데 FSRM 구현에 버그가 있어서 mov 연산을 수행할 때 예상하지 못한 행동을 한다거나 시스템을 충돌시킬 수 있는 등의 문제가 발견되었습니다. 보안 취약점에 영향을 받는 CPU는 다음과 같습니다.

 

  • Ice Lake
  • Rocket Lake
  • Tiger Lake
  • Raptor Lake
  • Alder Lake
  • Sapphire Rapids

대강 10세대-13세대라고 보시면 됩니다.

 

현재 보안 취약점들은 인텔에서 마이크로코드로 패치했습니다. 바이오스나 OS 업그레이드를 통해서 마이크로코드가 적용될 예정입니다

 

인텔 : https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html

 

 

 

 

 

We have a CPU mystery! We found a way to cause some processors to enter a glitch state where the normal rules don’t apply, but what does that mean…?

If you’re interested what can go wrong inside modern CPUs, read on!

Introduction

If you’ve ever written any x86 assembly at all, you’ve probably used rep movsb. It’s the idiomatic way of moving memory around on x86. You set the sourcedestinationdirection and the count - then just let the processor handle all the details!

lea rdi, [rel dst]
lea rsi, [rel src]
std
mov rcx, 32
rep movsb

The actual instruction here is movsb, the rep is simply a prefix that changes how the instruction works. In this case, it indicates that you want this operation repeated multiple times.

There are lots of other prefixes too, but they don’t all apply to every instruction.

Prefix Decoding

An interesting feature of x86 is that the instruction decoding is generally quite relaxed. If you use a prefix that doesn’t make sense or conflicts with other prefixes nothing much will happen, it will usually just be ignored.

This fact is sometimes useful; compilers can use redundant prefixes to pad a single instruction to a desirable alignment boundary.

Take a look at this snippet, this is exactly the same code as above, just a bunch of useless or redundant prefixes have been added:

            rep lea rdi, [rel dst]
             cs lea rsi, [rel src]
       gs gs gs std
          repnz mov rcx, 32
rep rep rep rep movsb

Perhaps the most interesting prefixes are rexvex and evex, all of which change how subsequent instructions are decoded.

Let’s take a look at how they work.

The REX prefix

The i386 only had 8 general purpose registers, so you could specify which register you want to use in just 3 bits (because 2^3 is 8).

The way that instructions were encoded took advantage of this fact, and reserved just enough bits to specify any of those registers.

Simple 2-byte instructions that use modr/m might be encoded like this, for example mov eax, ebx.

This is an 8-bit opcode, 2 bit addressing mode (labeled m), and 3 bits each for the source (s) and destination (d).

Well, this is a problem, because x86-64 added 8 additional general purpose registers. We now have sixteen possible registers..that’s 2^4, so we’re going to need another bit! 😆

The solution to this is the rex prefix, which gives us some spare bits that the next instruction can borrow.

When we’re talking about rex, we usually write it like this:

rex.rxb

rex is a single-byte prefix, the first four bits are mandatory and the remaining four bits called bxr and w are all optional. If you see rex.rb that means only the r and b bits are set, all the others are unset.

These optional bits give us room to encode more general purpose registers in the following instruction.

The rex prefix can lend the next instruction extra bits to use for operands, so now we can encode all 16 possible general purpose registers!

Now we’re fine until someone adds another register! 😂

Encoding Rules

So now we know that rex increases the available space for encoding operands, and that useless or redundant prefixes are usually ignored on x86. So… what should this instruction do?

rex.rxb rep movsb

The movsb instruction doesn’t have any operands - they’re all implicit - so any rex bits are meaningless, right?

If you guessed that the processor will just silently ignore the rex prefix, you would be correct!

Well… except on machines that support a new feature called fast short repeat move! We discovered that a bug with redundant rex prefixes could interact with this feature in an unexpected way and introduce a serious vulnerability, oops 🙂

Fast Short Repeat Move

FSRM is a new feature introduced in Ice Lake that fixes some of the shortcomings of ERMS. Hopefully that clears up any confusion. 😆

Just kidding, let’s quickly look at ERMS.

The hard part of moving strings around efficiently is getting all the buffers aligned so you can use the widest possible stores available. You could do this in software, but if we do it in microcode then the processor can just transparently make your existing code faster for you.

This requires some expensive setup, but once that’s done you get vastly improved throughput. This feature is known as enhanced repeat move/store, ERMS.

If you have a processor with ERMS support, simple rep movsb operations can sometimes perform comparably with more complicated hand-tuned vector move operations.

However, there is a problem with ERMS. That initial setup is so expensive that it just isn’t worth it for very short strings. This is what FSRM is designed to solve, it handles the case of only moving 128 bytes or less and makes that faster too!

I’m not aware of any documentation that explains exactly how FSRM works, but you can check if you have a processor that supports it by looking at the flags line in /proc/cpuinfo:

flags       : fpu vme de pse tsc msr pae mce cx8 [...] fsrm

Some of the processors that have this feature include:

  • Ice Lake
  • Rocket Lake
  • Tiger Lake
  • Raptor Lake
  • Alder Lake
  • Sapphire Rapids

Note: This list may not be comprehensive, please see Intel advisory INTEL-SA-00950 for a complete list.

Discovery

I’ve written previously about a processor validation technique called Oracle Serialization that we’ve been using. The idea is to generate two forms of the same randomly generated program and verify their final state is identical.

You can read more about Oracle Serialization in my previous writeup.

In August, our validation pipeline produced an interesting assertion. It had found a case where adding redundant rex.r prefixes to an FSRM optimized rep movs operation seemed to cause unpredictable results.

We observed some very strange behavior while testing. For example, branches to unexpected locations, unconditional branches being ignored and the processor no longer accurately recording the instruction pointer in xsave or call instructions.

Oddly, when trying to understand what was happening we would see a debugger reporting impossible states!

This already seemed like it could be indicative of a serious problem, but within a few days of experimenting we found that when multiple cores were triggering the same bug, the processor would begin to report machine check exceptions and halt.

We verified this worked even inside an unprivileged guest VM, so this already has serious security implications for cloud providers. Naturally, we reported this to Intel as soon as we confirmed this was a security issue.

Reproduce

We’re publishing all of our research today to our security research repository. If you want to reproduce the vulnerability you can use our icebreak tool, I’ve also made a local mirror available here.

$ ./icebreak -h
usage: ./icebreak [OPTIONS]
    -c N,M      Run repro threads on core N and M.
    -d N        Sleep N usecs between repro attempts.
    -H N        Spawn a hammer thread on core N.
icebreak: you must at least specify a core pair with -c! (see -h for help)

The testcase enters what should be an infinite loop, and unaffected systems should see no output at all. On affected systems, a . is printed on each successful reproduction.

$ ./icebreak -c 0,4
starting repro on cores 0 and 4
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................

In general, if the cores are SMT siblings then you may observe random branches and if they’re SMP siblings from the same package then you may observe machine checks.

If you do not specify two different cores, then you might need to use a hammer thread to trigger a reproduction.

Analysis

We know something strange is happening, but how microcode works in modern systems is a closely guarded secret. We can only theorize about the root cause based on observations.

μops

The CPU is split in two major components, the frontend and the backend. The frontend is responsible for fetching instructions, decoding them and generating μops to send to the backend for execution.

The backend executes instructions out of order, and uses a unit called the ROB, reorder buffer, to store and organize results.

We believe this bug causes the frontend to miscalculate the size of the movsb instruction, causing subsequent entries in the ROB to be associated with incorrect addresses. When this happens, the CPU enters a confused state that causes the instruction pointer to be miscalculated.

The machine can eventually recover from this state, perhaps with incorrect intermediate results, but becoming internally consistent again. However, if we cause multiple SMT or SMP cores to enter the state simultaneously, we can cause enough microarchitectural state corruption to force a machine check.

Questions

I’m sure some readers will have questions about what is possible in this unexpected “glitch” state. Well, so do we!

We know that we can corrupt the system state badly enough to cause machine check errors, and we’ve also observed threads interfere with execution of processes scheduled on SMT siblings.

However, we simply don’t know if we can control the corruption precisely enough to achieve privilege escalation. I suspect that it is possible, but we don’t have any way to debug μop execution!

If you’re interested in studying this, then we would love to get your input!

Credit

This bug was independently discovered by multiple research teams within Google, including the silifuzz team and Google Information Security Engineering. The bug was analyzed by Tavis Ormandy, Josh Eads, Eduardo Vela Nava, Alexandra Sandulescu and Daniel Moghimi.

Solution

Intel have published updated microcode for all affected processors. Your operating system or BIOS vendor may already have an update available!

Workaround

If you can’t update for some reason, you could disable fast strings via the IA32_MISC_ENABLE model specific register.

This will cause a significant performance penalty, and should not be used unless absolutely necessary.


0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
List of Articles
번호 분류 제목 글쓴이 조회 수 날짜
공지 뉴스 구글 최신 뉴스 file 덕후냥이 1458 2024.12.12
공지 일반 샤오미 BE6500 라우터 실사용 후기 (Wi-Fi 7 + 2.5G 스위치 기능까지 ㄷㄷ) 4 덕후냥이 1025 2025.06.28
공지 🚨(뉴비필독) 전체공지 & 포인트안내 22 무명의덕질 29094 2024.11.04
공지 URL만 붙여넣으면 끝! 임베드 기능 무명의덕질 23135 2025.01.21
1500 정보 마이크론 2023회계연도 2분기 실적 발표 file 덕후냥이 1827 2023.03.30
1499 정보 사파이어 래피드의 AMX를 사용해 스테이블 디퓨전 성능을 10배 향상 file 덕후냥이 1578 2023.03.30
1498 정보 AMD/인텔 메인보드 가격이 최근 2년 반 사이에 35~40% 증가 덕후냥이 1551 2023.03.30
1497 정보 바이든 미국 대통령, PCB 생산을 위해 국방물자생산법을 발동 덕후냥이 1710 2023.03.30
1496 정보 인텔 데이터센터 / AI 인베스터 웨비나. 차세대 제온의 계획 file 덕후냥이 1820 2023.03.30
1495 정보 Puget Systems의 2022년 하드웨어 동향 file 덕후냥이 1624 2023.03.30
1494 정보 MSI A620 메인보드가 유럽에 87유로로 등록 file 덕후냥이 1523 2023.03.30
1493 정보 지포스 RTX 4060 Ti/4060 출시일 덕후냥이 1373 2023.03.30
1492 정보 TCL CSOT 초슬림 베젤 디스플레이 양산 중 file 덕후냥이 1432 2023.03.30
1491 정보 화웨이 토크밴드 B7, 스마트밴드+이어셋 file 덕후냥이 2224 2023.03.30
1490 정보 레노버, LOQ이라는 게이밍 브랜드를 도입 file 덕후냥이 1915 2023.03.30
1489 정보 지포스 RTX 4060 Ti의 박스 탬플릿 유출 file 덕후냥이 1819 2023.03.30
1488 정보 필립스, 44.5인치 듀얼 QHD 커브드 디스플레이 file 덕후냥이 1818 2023.03.30
1487 정보 DRAM 평균 판매 가격이 올해 2분기에 10~15% 하락 file 덕후냥이 1645 2023.03.30
1486 정보 NVIDIA, AI를 써서 최대 30배 빠르게 칩 설계를 최적화하는 AutoDMP file 덕후냥이 1996 2023.03.30
1485 정보 트위터, 개발자용 API의 세로운 요금 체계 발표 file 덕후냥이 1723 2023.03.31
1484 정보 머스크 등 전문가 1000명 'AI 개발 잠정 중단' 촉구 덕후냥이 1684 2023.03.31
1483 정보 AMD 라이젠9-5세대 7950X 라파엘 스파이더 차트를 확인해보세요! file 덕후냥이 1804 2023.04.02
1482 정보 AMD APU가 특별한 이유!! (세잔, 르누아르, 피카소, 레이븐릿지) file 덕후냥이 1653 2023.04.02
1481 정보 ASUS, ROG Hero, ROG Strix 및 TUF Gaming의 새로운 X670E 메인보드 3종 발표 file 덕후냥이 2165 2023.04.02
Board Pagination Prev 1 2 3 4 5 ... 75 Next
/ 75