|
:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
18/01/03 11:58
'중대한 보안 결함이 인텔 CPU 문제로 생겼는데.. 그 결함을 수정하면 속도가 느려지는 겁니다'
이 보안결함을 알면서도 속도를 위해서 저지른건지.. 몰랐던 건지는 알수 없으니 가라 뻥튀기일수도 있고, 아닐수도 있는 문제 라고 보시면 됩니다..
18/01/03 14:37
자세한 건 모르겠지만 캐시를 쓸 때 커널 메모리 정보가 노출되나 봐요.
그래서 캐시를 덜 쓰거나 보안 검사를 한 번 더 하는 식으로 해서 느려진 듯요.
18/01/03 11:57
시퓨 속도가 5~30% 느려졌습니다
시퓨 속도가 5~30% 느려졌습니다 시퓨 속도가 5~30% 느려졌습니다 ........보안 결함도 결함이지만 결함을 막으면 속도가 느려진다니 아니 이건 뭐... 몇세대에 걸친 CPU에<-스카이레이크 cpu인데 당연히 포함되겠죠? 젠장...
18/01/03 12:01
운영체제 기준으로 심각한 보안결함이라..
마소와 애플이 묻지마로 업데이트 할 수 있는 수준입니다. (운영체제 커널이 뚫리는 이슈라서요)
18/01/03 12:03
이미 윈도우10에서 조금씩 자체적으로 업데이트로 수정을하고있다는 소리를 들었습니다...
근데 개인유저들한텐 큰문제가 없어보이는게 게임성능하고는 관계가 없다는데 어떻게 될지 궁금하네요
18/01/03 12:17
폭스바겐 게이트랑 똑같은 결함이네요.
"환경에 영향을 줄 수 있는 배기가스 조작을 없애면 연비가 저하됩니다." 유일한 차이라면 의도적인 것과 그렇지 않은 것?
18/01/03 12:17
올라오는 글들을 보니 가상화 쪽에 성능저하가 심각하다는 것 같네요.. 아마 서버쪽에서는 큰 문제가 될것 같고, 개인 사용자는 안드로이드 에뮬이 느려지려나..
18/01/03 12:46
(수정됨) 대강 눈팅해보니, 의도적인거 같진 않고, 그냥 말 그대로 버그가 있었는데 그 버그를 소프트웨어로 커버치다보니 system call속도가 팍 떨어지는거 같네요.
요새 가상화를 많이하다보니, cpu에서 아예 가상화 관련 기능을 지원하는데, 그중 Memory Mapping 쪽에 버그가 있어서, 한 장비에 두 가상화 인스턴스가 떠있을때, 한 인스턴스가 다른 인스턴스의 메모리를 침범할 수 있는 버그가 있는거 같습니다. 그래서 mapping 테이블을 하드웨어로 처리하지 못하고 소프트웨어로 처리하다보니 이 과정에서 성능저하가 생긴거같네요. 그래서 각 소프트웨어가 연산 비중이 어떤지에 따라 영향력이 다를 수 밖에 없고, 특히 System call등이 많으면 성능이 엄청 떨어지나보네요. 이건 clock을 오버한다고 될 수준이 아니고... 극단적으로 비유하자면, 자동차에 결함이 있어서, 사거리 지날때는 차를 밀어서 가야만 하는 상황이라고나 할까나. 고속화도로나 고속도로만 주구장창 타는 사람들은 상관없겠지만, 어떤 사람들은 치명적으로 느리겠죠. 이건 아마존같이 cloud 서비스 제공하는 쪽에서 완전 맨붕일거같아요. 자기들에게 치명적인 보안적 결함이라 패치안할 순 없는데, 성능에 너무 치명적이라...
18/01/03 12:59
웹서핑을 해 보니 이거 정말 심각한 문제군요.
ME 펌웨어의 보안 취약점은 [전원이 꺼진 상태에서도 피해를 당할 수 있는 문제]라고 합니다. ME의 동작을 CPU에서도, OS에서도 알아채지 못하기 때문에 당연히 사용자도 알아챌 수가 없다고 하고요. 후덜덜하네요. 전원이 꺼졌는데도 피해를 당할 수 있다고 하면 거의 괴담이라고 치부할 정도의 수준인데 이게 사실이라니...
18/01/03 13:04
보니까 I7 -3770S (아이비브릿지)역시 해당 패치가 되면 37%정도 성능이 떨어진다고 하니 샌디나 아이비 역시 안심 못할거 같네요
18/01/03 13:21
현재 알려진 바로는 아이비브릿지부터 펜티엄 계열을 제외한 모든 인텔 CPU 가 해당된다고 합니다.
불멸의 샌디 4.5G 밈이 다시 슬금슬금 올라오고 있습니다.
18/01/03 13:40
아직까지 샌디에 대한 테스트 결과가 없어서 그렇게 알려진 걸수도 있습니다. 일단 아이비브릿지는 영향이 있는 것으로 확인이 되었고, 그 이전 세대에 대해서까지는 좀 더 정확한 결과를 기다려봐야 할 것 같습니다.
18/01/03 13:20
이번 커피레이크가 보드도 새로 나오고... 8700k 살까 했는데 고민되네요; 암드에 비해 인텔을 선호하는데, 개인사용자가 암드로 갈 메리트가 있는 수준의 문제인가요?
18/01/03 13:21
(수정됨) 커널 메모리 리키지랍니다. 메모리 덤프하면 패스워드니 각종 데이터를 볼수 있기 때문에 패치가 필요하구요 그래서...
These Kernel Page Table Isolation patches move the kernel into a completely separate address space, so it’s not just invisible to a running process, it’s not even there at all. Really, this shouldn’t be needed, but clearly there is a flaw in Intel’s silicon that allows kernel access protections to be bypassed in some way. 밑에 이유때문에 컴퓨터가 느려집니다 The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel’s overhead, and slows down the computer. AMD는 안전하답니다 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. 현 상황은 There is presently an embargoed security bug impacting apparently all contemporary [Intel] CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualisation environments including Amazon EC2 and Google Compute Engine... 현재 64bit ARM 아카텍쳐에서도 비슷한 버그가 발견되어서 리눅스 패치가 나왔다는데요. 이거는 현재 자세한걸 찾기가 힘드네요
18/01/03 13:27
아... 파일 인/아웃쪽 이라길래 일반사용자는 큰 문제 없겠지 라고 생각했는데 에뮬레이터도 영향을 받는다네요.
컴퓨터가 소전머신이된지 오래인데...ㅠ.ㅠ
18/01/03 13:27
라이젠5 1600으로 최근에 나름 매우 좋은 컴퓨터 사양 맞춰났다가 커피레이브 소식듣고 조금 후회했었는데...
전화위복이 될려나 싶네여
18/01/03 13:44
(수정됨) 전문적인 내용뿐 막쓰는 일반사용자에게 어떤 피해(?)손실(?)이 있는지 알수가 없네요.
흔하게 겜이 느려진다, 부팅속도가 느려진다 뭐 이런 내용...
18/01/03 13:47
이거 글만 보면 엄청 큰일처럼 느껴지는데(그 동안의 보안 문제를 통한 사회적 비용, PC성능 저하에 따른 비용)..
지금이라도 AMD 주식을 사야할까요? 크크
18/01/03 15:47
커널 문제라면 캐쉬 성능과 관련이 있기 때문에 게임 성능 영향이 없을 수는 없습니다.
현재 게이밍 성능은 코어 성능이 어느 정도 이상이면 그 다음에는 캐쉬/메모리 성능 따라갑니다. 그게 0.1% 냐 10% 냐 의 문제죠. 10% 이상이면 게이머들 이번에 나오는 라이젠 2세대로 대량 넘어갈 가능성이 있기 때문에...
18/01/03 16:02
저는 가상화와 관련된 이슈로만 보고 있어서 영향이 작은 수준(1% 미만)이 되지 않을까 생각하고 있습니다.
만약 10%를 상회하는 성능 감소가 있다면 말씀하신대로 라이젠 2세대로 많이 넘어가게 되서 AMD의 부흥을 다시 볼 수 있게 되겠네요. 흐흐
18/01/03 17:30
좀 둘러보니 패치 이후에는 가상화와 상관 없이 모든 시스템 콜의 성능이 영향을 받을 수 밖에 없습니다. 게임도 그래픽쪽 말고는 성능 저하가 이뤄질 수 밖에 없는것 같네요.
18/01/03 14:57
https://www.clien.net/service/board/park/11616880
패치후 시스템콜 성능이 30% 깎이는게 아니라 30%가 된다는데요?
18/01/03 15:49
벤치마크에 따르면 인코딩/렌더링 성능은 크게 깎이지 않는 것 같습니다.
오히려 CPU 코어 주구장창 갈구는 쪽은 관련 없고, 임기응변이 필요한 (캐쉬 성능) 분야가 영향이 많은 걸로 보입니다.
18/01/03 15:49
???: 문제가 된 제품들 중 2015년부터 판매된 해당 상품들에 한해서 2018년 1년간 패치된 동일 상품으로 교환시 기준 소비자가의 30% 할인된 금액으로 교환할 수 있도록 조치하겠습니다...
18/01/03 16:29
파일 읽기 쓰기가 느려진다고 하던데
게임 로딩이 느려지는거 아닌가요?; 그리고 동영상 재생 같은건 어떤가요?; 4K 같은 초고화질 볼때 cpu 점유율이 확 높아지진 않으려나요;
18/01/03 16:33
처리가능한 IOPS는 낮아지더라도
어차피 게임은 벌크로딩이 기본이고 실상 최대성능으로 SSD를 갈구는 워크로드 자체가 거의 없습니다.
18/01/03 17:44
저도 커널개발자는 아니라 자세히는 모르지만 OS시간의 기억을 더듬어서 정리 해 보겠습니다. 일단 현대 OS는 모두 커널영역과 유저모드로 나누어져 동작합니다. 보통 작업은 유저모드로 진행되지만 파일 입출력 같은 시스템 접근을 할때는 시스템콜을 하게 되고 여기서 커널영역으로 전환됩니다. 커널영역은 유저모드의 메모리를 볼 수 있지만 유저모드는 커널영역 메모리에 뭐가 있는지 못봐야 보안이 유지됩니다. 여기서는 유저영역은 커널 영역 메모리 주소는 알 수 있지만 접근하려 하면 권한 에러가 납니다. 이게 원래 하드웨어적으로 지원되는 기능이고 (실제로 시스템콜을 내부에는 cpu에게 이제 커널모드로 바꼈음을 알려주는 코드가 있습니다) 기존 OS들은 이 가정 아래 프로그램이 되었는데 인텔 CPU에서는 사실 이게 안되던 상황 (이정도로 나이브한건지 아니면 특정한 조건 아래서 안되는건지는 잘 모르겠습니다). 그래서 OS 패치 내용은 실제 커널 코드를 완전히 격리시켜 버리는 겁니다. 그래서 유저영역이 커널의 메모리 주소 자체를 모르게 한다는 것 같습니다. 성능저하가 일어나는 원인은 커널영역으로 전환->커널 코드를 불러와야됨->커널코드의 메모리 주소는 유저코드와 너무 멀어서 캐시미스가 남 이런 과정으로 보입니다.
18/01/03 17:46
윈도우는 9일 강제패치, 리눅스는 적용된 상황에서의 벤치입니다.
pcid 있는 커피, 카피레이크는 큰 영향은 일단은 없어보입니다. http://m.ruliweb.com/pc/board/1003/read/2146417
18/01/03 18:35
지금 최악의 상황이 될 사람들은 인텔에 NVMe SSD 쓰는 사람들이라는군요.
Sata3은 그나마 나은데 이건 SSD 성능이 절반 이상 떨어질거로 예상된다고 하네요.
18/01/03 19:53
이런 문제가 있는걸 알고 있었으믄 그 가격에 팔아먹으믄 안되는건데...
그동안도 비싸게 받는다는 생각이 있었는데 실상은 더 심한 상황이었네요.
18/01/03 20:49
꺼라위키(https://namu.wiki/w/2018%EB%85%84%20%EC%9D%B8%ED%85%94%20CPU%20%EB%B3%B4%EC%95%88%20%EB%B2%84%EA%B7%B8%20%EC%9C%A0%EC%B6%9C)에 설명이 올라와 있는데, 이 설명대로라면 가상화랑은 상관없는 문제로 패치는 반드시 이루어져야 하며, 상황은 심각해 보입니다. 신뢰도는 꺼라위키 신뢰도를 감안해주시고, 내용은 아래와 같습니다.
"cpu가 코드를 실행할 때 성능을 높이기 위해서 branch predictor를 사용하는데 이 branch predictor에 user mode와 kernel 모드를 구별할 수 있는 기능이 없어서 만약 user가 system call을 하는 코드 실행 직후 커널 공간 메모리를 접근하는 코드를 넣게 코드를 만든 후 system call을 하면 branch predictor가 system call이 실행되면서 커널 모드로 바뀌는 동안 실행되면서 미리 그 코드를 실행할 수도 있는데 이때 커널 모드로 커널 공간도 접근할 수가 있게 됩니다. 따라서 충분한 시간만 주어지고 여러 테스트를 거치면 100% 커널 공간 메모리를 읽어오고 분석해서 커널의 모든 정보를 얻을 수 있게 됩니다. 이번 패치는 인텔 cpu는 user 페이지 테이블과 커널 페이지 테이블을 공유해서 사용하고 또 대부분의 os가 커널 공격을 쉽게 하지 못하게 하기 위해서 메모리 테이블을 랜덤하게 배치하는데 그 메모리 테이블을 버그를 이용해서 미리 읽으면 커널의 메모리 배치를 손쉽게 알 수 있어서 해커가 훨씬 수월하게 커널 메모리 공간 분석을 수행할 수 있는 것을 user와 kernel의 페이지 테이블을 분리시킴으로써 메모리 공간 분석을 어렵게 하려는 것이 목적입니다. 페이지 테이블이 분리되면 그만큼 cache의 hit율이 떨어지고 system call을 할 때마다 그만큼 성능이 저하됩니다. 성능은 system call을 많이 하는 프로그램일 수록 저하되며 모든 프로그램이 영향을 받습니다." 요컨데 system call 수행을 위해 ring 0로 모드 변경이 이루어진 상황에서 OOE 때문에 user op가 실행될 수 있는 문제이며, 페이지 테이블을 공유한다는 얘기가 좀 부정확한데 정확하게는 페이지 테이블 Offset 변경을 통해 speculative하게 커널 메모리를 얻어 올 수 있는 문제로 보입니다. 위 문제 해결을 위해서 나온 이번 패치 이름이 KPTI(Kernel Page Table Isolation)인 것을 보아 페이지 테이블 디렉토리 부터 완벽하게 분리한 것 같은데 이러면 page translation 관련한 cache 효율이 매우 낮아질 거라서 문제가 생기고, TLB invalidate를 줄여 page translation 효율이 높인 PCID가 적용된 최신 cpu의 경우는 위의 패치 영향을 좀 덜 받는 것 같습니다. 더불어 AMD의 경우 speculative memory reference가 막혀 있어 위의 버그에서 자유로운 것 같구요.
18/01/03 21:45
궁금한게 있는데 해결방법이 없는건가요?
지금 한다는 패치가 임시방편으로 일단 막고 수정을 하려는건가요 아니면 정말 저거 말곤 답이 없는 상황인건가요
18/01/03 22:16
궁극적인 해결방법은
1. AMD 처럼 speculative memory reference가 불가능하도록 한다. 2. branch predictor에서 ring 0 (VM의 경우 ring 1까지)로 모드 변경이 이루어졌을 때 user mode op가 OOE 가 되지 않도록 한다. 두 개인데 모두 다 소프트웨어 패치로 해결될 수 있는 상황은 아닙니다. 1번의 경우는 명령어 셋을 수정해야 하는데 하위호환 때문에 불가능할 거고 (근데 또 micro op 문제라면 해결이 가능할 것 같기도 하네요. 어차피 거의 같은 명령어 셋 쓰는 amd에 문제가 없는 것 보면...), 결국 2번인데 OOE 관련 최적화 알고리즘이 더 복잡해진다는 얘기라서, 차기 cpu에서도 가능할지 의문이네요.
18/01/04 00:08
저는 지금 조립하려다가 메인보드랑 CPU 반품했어요
그래서 조립을 못한다는.. 베그 풀세트 준비중인데 흙흙 담주에 해외출장가서 하루 해보고 3주동안 못할듯 합니다. 빨리와라 라데온.. 아오이 소라도 결혼 소식도 지난주 조립한 8700K로 보셨겠네요.
|
||||||||||