shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
가장 놀이, 즉 "가장 놀이"는 시나리오를 연기하고 다양한 관점을 탐구하는 것을 포함한다. 일부 연구는 가장 놀이가 아동 발달에 미치는 영향에 의문을 제기하지만, 다른 연구는 언어 사용, 타인의 관점에 대한 인식, 공감 및 지연된 만족과 같은 영역에서 자기 조절을 향상시킬 수 있다고 제안한다. 가장 놀이는 또한 문제 해결 및 의사소통과 같은 사회 기술을 향상시킬 수 있다. 놀이 기반 학습 경험은 양육자에게 아동 행동에 대한 귀중한 통찰력을 제공하여 필요한 경우 조기 개입을 가능하게 한다.
놀이 기반 학습 프로그램.
놀이 기반 학습 프로그램은 흥미로운 놀이 활동을 통해 아이들의 학습 경험을 향상시키는 다양한 교육적 접근 방식을 포함한다. 이러한 프로그램은 경청, 집중력, 의사소통, 자기 주도성 등과 같은 기술 개발을 강조한다.
확장 교육과정
확장 교육과정은 놀이 기반 학습을 통합하여 아이들의 학습 경험을 향상시키도록 설계되었다. 이 교육과정은 야외 신체 활동과 소그룹 실내 놀이를 결합하여 아이들의 발달을 촉진한다. 비평가들은 확장 교육과정에 대해 특히 읽기 및 쓰기 수업을 지연시키고 추가 자원이 필요하며 다양한 유형의 학습자에게 적합하지 않을 수 있다는 우려를 표명했다.
주목할 만한 놀이 기반 학습 프로그램
아동 발달에서 다양한 유형의 놀이의 이점.
자유 놀이.
자유 놀이는 아이들이 자신의 선호도에 따라 활동에 참여하며, 무엇을 어떻게 할지에 대해 스스로 선택하는 것으로 관찰된다. 이는 종종 자발적으로 발생하고 즐거우며 상상적 사고를 장려한다. 이러한 유형의 놀이는 일반적으로 성인이 부과하는 특정 규칙 없이 진행되어 아이들이 탐색하고, 창의성을 표현하며, 다양한 접근 방식을 실험할 자유를 누릴 수 있게 한다.
이러한 유형의 놀이는 아이들이 다양한 과제와 장애물을 독립적으로 해결하면서 창의성과 문제 해결 능력을 활용할 수 있도록 한다고 믿어진다. 또한 아이들에게 자신을 표현하고 상상적 시나리오에 참여할 기회를 제공하며, 잠재적으로 인지 발달을 촉진하고 또래들과의 긍정적인 사회적 상호작용을 촉진한다. 일부 연구는 자유 놀이가 전반적인 성장에 중요하다고 여겨지는 상상력과 사회 기술을 육성할 수 있다고 제안한다 (Weisberg, Hirsh-Pasek, and Golinkoff, 2013).
자유 놀이가 상상력을 어떻게 촉진할 수 있는지에 대한 예시는 다음과 같다.
일부 연구에 따르면 덜 특권층의 배경을 가진 아이들은 어휘 습득에서 놀이 학습의 이점을 얻을 수 있다 (Han, Moore, Vukelich, &amp; Buell, 2010).
연구에 따르면 아이들은 완전히 혼자 두는 것보다 독립적으로 탐험하는 동안 어느 정도 지도를 받을 때 학업 성과가 더 좋을 수 있다 (Alfieri, Brooks, Aldrich, &amp; Tenenbaum, 2010).
연구에 따르면 아이들은 놀이 활동에 참여할 때 도형과 같은 개념을 더 효과적으로 파악할 수 있다 (Fisher, Hirsh-Pasek, Newcombe, &amp; Golinkoff).
교사 주도 놀이.
이러한 유형의 놀이를 통해 교사는 새로운 개념과 기술을 가르치기 위한 구조화된 활동을 이끌 수 있다. 이는 아이들에게 귀중한 학습 기회, 팀워크, 지시 따르기, 그리고 협동 학습을 촉진한다.
상호 주도 놀이.
Hope-Southcott(2013)와 McLennan(2012)은 아이들과 교사 간의 놀이 활동에서의 협력을 수반하는 놀이 유형을 소개하며, 공유된 경험과 상호작용을 통해 학습을 촉진한다. 또한 의사소통, 협상, 의사결정 기술을 장려하는 동시에 긍정적인 교사-학생 관계와 또래 상호작용을 촉진한다.
상호 주도 놀이가 아이들과 성인 모두에게 유익한 예시는 다음과 같다.
성인들은 학습을 지원하기 위해 특정 장난감이나 재료로 놀이 환경을 조성한다. 예를 들어, 교사는 교실 활동을 위한 장난감을 선택하거나 박물관은 아이들이 탐험할 수 있는 전시물을 설계할 수 있다.
성인들은 "만약 ~한다면 어떻게 될까?"와 같은 질문을 통해 놀이 중에 아이들을 도울 수 있다. 이러한 질문은 아이들을 서두르지 않고 학습으로 부드럽게 이끌어준다.
성인들은 놀이 중에 새로운 사물을 도입하여 아이들의 호기심을 자극한다. 예를 들어, "이것을 사용하면 어떻게 될지 궁금하다"라고 말할 수 있다. 이는 아이들이 학습에 집중하면서 탐험할 수 있게 한다.
다양한 놀이 적응: 학습 및 발달 향상.
장애 아동의 요구에 맞춘 놀이 적응
교사는 다양한 방식으로 장애 또는 특수 아동의 요구에 맞춰 놀이를 적응시킬 수 있다. Sharifah &amp; Aliza (2013)에 따르면, 학생들의 특정 요구와 능력에 맞춰진 효과적인 수업 계획은 모든 학생의 교육 경험을 향상시킬 수 있다. 각 수업 주제와 학습 목표에 적합한 기술과 전략을 선택하는 것은 학생들의 다양한 요구를 지원한다. 시각 또는 촉각 자료와 같은 적절한 학습 보조 자료를 활용하는 것도 접근성과 참여를 개선할 수 있다. 연구자 Nor Azlinah (2010)는 협력 학습을 장려하면 학생들이 그룹으로 작업하고 사회적 상호작용의 이점을 얻을 수 있음을 발견했다.
장애 아동을 위한 놀이 기반 학습의 이점
놀이 기반 학습은 다양한 유형의 장애를 가진 아동에게 수많은 이점을 제공한다. 특히 자폐 스펙트럼 장애 아동의 인지 및 언어 발달을 지원한다. 놀이 기반 학습은 또한 학생들 간의 긍정적인 상호작용과 협력을 촉진하여 정서적 및 사회적 발달을 촉진한다. 다양한 접근 방식과 기술을 고려함으로써 교사는 학생들의 다양한 요구를 지원하는 포괄적인 학습 환경을 조성할 수 있다.
이러한 통찰력은 놀이가 장애 아동의 요구에 맞춰 어떻게 적응될 수 있는지, 그리고 놀이 기반 학습이 다양한 유형의 장애 아동에게 어떻게 도움이 되는지에 대한 개요를 제공한다.
병행 놀이 또는 병행 플레이(parallel play)는 사람들이 서로 옆에서 놀지만, 서로의 행동에 영향을 주려 하지 않는 놀이의 한 형태이다. 이는 일반적으로 24~30개월경에 시작되며, 아동기 내에 점차 사라진다. 이는 관찰자 놀이(onlooker play) 이후, 연합 놀이(associative play) 이전에 오는 파튼의 놀이 단계 중 하나이다.
관찰자는 아이들이 가끔 다른 아이들이 무엇을 하는지 보고 그에 따라 자신들의 놀이를 조절하는 것을 알아차릴 것이다. 아이들이 나이가 많을수록 이런 유형의 놀이에 참여하는 빈도는 줄어든다. 그러나 나이가 더 많은 유치원 아이들도 유치원 시기 내내 지속적이고 빈번한 활동인 병행 놀이에 참여한다. 병행 놀이의 이미지는 두 아이가 모래밭에서 나란히 놀면서 각자 자신의 놀이에 몰두하고 서로 상호작용하지 않는 모습이다. "이것은 유아 발달의 초기 단계로 간주되며, 자기중심적 행동과 '놀이 친구'의 활동과 탈중심화하고 협응할 수 없는 무능력이 특징이다."
교육에서 병행 놀이는 학생들이 두 명 또는 소그룹으로 나뉘어 같은 활동을 동시에 하는 활동을 묘사하기도 한다. 이는 모든 학생에게 적극적인 참여의 동등한 기회를 제공하고 노출을 줄인다 – 모든 학생이 놀고 있으므로 아무도 지켜보지 않는다. 이 단계는 아이가 상호작용적 놀이 행동과 상징적 의사소통에 참여할 수 있는 능력을 발달시킬 때 끝난다.
독립적인 코워킹은 병행 놀이의 업무 버전이다.
자폐인들은 종종 성인이 되어서도 다른 자폐인, 양육자 및 다른 사람들과 함께 병행 놀이에 참여한다.
밀드레드 파튼은 1932년에 2세에서 5세 아동의 또래 사회성을 연구한 최초의 학자 중 한 명이다. 파튼은 나이가 들면서 상호작용적 놀이가 극적으로 증가하는 것을 알아차리고 사회성 발달이 세 단계를 포함한다고 결론 내렸다. 병행 놀이는 어린 아이들에게서 관찰되는 세 가지 놀이 단계 중 첫 번째 단계이다. 다른 두 단계는 단순 사회적 놀이(함께 놀고 공유하기)와 마지막으로 협동 놀이(서로 다른 보완적 역할; 공유된 목적)를 포함한다. 파튼의 연구는 유치원 아이들이 두 명으로 구성된 그룹을 선호하고, 병행 놀이는 나이가 들수록 줄어들며, 대부분의 아이들이 같은 성별의 놀이 친구를 선택했고, 가장 흔한 병행 놀이 활동은 모래 놀이와 건설적인 작업이었다는 것을 나타냈다. 그녀의 연구에서 다른 발견으로는 I.Q. 수준이 거의 영향을 미치지 않았고, 형제자매는 서로 노는 것을 선호했으며, 가정 환경이 큰 요인이고, 소꿉놀이가 아이들 사이에서 가장 흔한 사회적 놀이 형태였다는 것이었다. 연구는 이러한 놀이 형태가 파튼이 제안한 순서대로 나타나지만, 나중에 나타나는 형태가 이전 형태를 대체하는 발달 순서를 형성하지는 않는다는 것을 나타낸다. 모든 유형은 유치원 시기 동안 공존한다. 비고츠키는 아동기 동안의 놀이가 아동의 근접 발달 영역을 만들고 지적 발달을 안내한다고 믿었다. 사회 경제적 지위는 연합 놀이에만 영향을 미치는 것으로 나타났는데, 연구에 사용된 낮은 사회 경제적 지위의 영국 아이들이 이 유형의 놀이를 선호했다. 이는 그 아이들이 장난감이 적고 장난감을 공유할 형제자매가 많았기 때문으로 설명될 수 있다.
발달 기술.
병행 놀이는 아이들이 언어 발달을 시작하고 사회적 관계를 형성하는 데 도움을 준다. 루빈 외(1976)는 "다른 아이들 옆에서 노는 아이들은 다른 아이들의 동반을 원할 수 있지만, 연합적 또는 협동적인 방식으로 놀기 위해 필요한 기술을 아직 갖지 못했을 수 있다"고 제안했다. 또한 아이의 개별적인 놀이를 통해 대근육과 소근육 운동 능력을 돕는다. 병행 놀이는 아이들이 다른 아이들 근처에서 노는 것을 배우기 때문에 자신감을 높일 수 있다. 아이들은 서로를 관찰하고 다른 아이들 옆에서 놀면서 새로운 기술을 사용하는 법을 배울 수 있다. 궁극적으로 이는 아이가 놀이 중 다른 아이들과 관계를 형성하는 사회적 발달로 이어진다. 병행 놀이는 아이의 개별적인 놀이를 통해 감정을 표현하는 것을 장려하는 데 유용할 수 있다. 아이는 점차 공유하는 법을 배우고 다른 사람의 감정을 인식하며, 놀이에서 문제를 조절하고 해결하는 시행착오를 통해 인과 관계를 배울 것이다.
"병행 놀이는 종종 아이들이 혼자 노는 아이에서 사회적 아이로 발달함에 따라 거치는 '단계'의 특성으로 간주된다." 아이들은 궁극적으로 그룹에 합류하기 위해 다양한 놀이 단계를 거칠 것이다. 2003년 &lt;Early Childhood Research Quarterly&gt;에 발표된 분석에 따르면, 다른 아이들이 병행 놀이에 참여하는 것을 즐겨 관찰하는 유치원 아이들은 더 높은 수준의 사회적 상호작용으로 전환하는 데 도움이 되는 미래 활동을 설계할 수 있다. 병행 놀이 활동은 소외되거나 거부된 아이들이 사회적 놀이 상태 간의 사회적 전환을 돕는 데 도움이 될 수 있다. 스미스는 병행 놀이를 선택적이며
"병행 놀이 후에 아이들은 주로 함께 놀거나 그룹 놀이에 참여했다." 이는 병행 놀이가 이러한 전환에 중요한 역할을 했다는 것을 시사한다.
웨이 펑(Wei Peng)과 줄리아 크라우즈(Julia Crouse)가 수행한 연구에 따르면, 병행 놀이는 게임, 특히 신체 활동을 포함하는 활동적인 비디오 게임을 더 효과적으로 설계하는 데 사용될 수 있다. 다른 사람들과 함께 노는 것이, 심지어 그들이 낯선 사람이라 할지라도, 혼자 노는 것보다 더 동기 부여가 되었고, 같은 물리적 공간 모드와 분리된 물리적 공간 모드 사이에는 협력과 경쟁에서 큰 차이가 없는 것으로 보인다. 또한 다른 사람들과 온라인으로 노는 것은 다른 사람들과 관계를 맺는 능력을 만들고, 분리된 공간에서의 병행 경쟁은 더 즐겁고, 더 많은 신체적 노력을 필요로 하며, 미래 놀이 동기를 높인다.
아이들은 양육 방식에 따라 낯선 존재에 대처하는 방식이 다르다. 옌스 B. 아젠도르프(Jens B. Asendorpf)는 병행 놀이를 아동의 대처 방식으로 언급하며, 낯선 또래와 놀고 싶어 하는 아이들이 이 방식을 선택한다고 설명한다. 이 대처 방식은 아이들이 편안함을 느껴 또래와 교류할 수 있을 때까지 멀리서 또래와 같은 활동에 참여할 수 있게 한다.
codice_1("read random"의 약자)는 인텔 온칩 하드웨어 난수 생성기에서 난수를 반환하는 명령어로, 온칩 엔트로피 소스에 의해 시드된다. 또한 인텔 시큐어 키 기술로도 알려져 있으며, 코드명은 불 마운틴이다. 인텔은 2012년경 이 기능을 도입했으며, AMD는 2015년 6월에 이 명령어에 대한 지원을 추가했다. (codice_1는 아이비브리지 프로세서에서 사용할 수 있으며 인텔 64 및 IA-32 명령어 집합 아키텍처의 일부이다.)
이 난수 생성기는 NIST SP 800-90A, FIPS 140-2, ANSI X9.82와 같은 보안 및 암호화 표준을 준수한다. 인텔은 또한 2012년 암호화 연구소(Cryptography Research Inc.)에 난수 생성기 검토를 요청했으며, 그 결과 "인텔 아이비브리지 디지털 난수 생성기 분석"이라는 논문이 나왔다.
codice_3는 codice_1와 유사하며 엔트로피 생성 하드웨어에 대한 하위 수준 액세스를 제공한다. codice_3 생성기 및 프로세서 명령어 codice_6는 인텔 브로드웰 CPU 및 AMD 젠 CPU에서 사용할 수 있다.
codice_7 명령어는 AMD 및 인텔 CPU에서 codice_1 명령어 지원 여부를 확인하는 데 사용할 수 있다. 지원되는 경우 CPUID 표준 함수 codice_9 호출 후 ECX 레지스터의 비트 30이 설정된다. AMD 프로세서는 동일한 테스트를 사용하여 이 기능을 확인한다. codice_3 가용성은 인텔 CPU에서 비슷한 방식으로 확인할 수 있다. codice_3가 지원되는 경우 CPUID 표준 함수 codice_12 호출 후 EBX 레지스터의 비트 18이 설정된다.
codice_1의 연산 코드는 codice_14이며, 그 뒤에 대상 레지스터를 지정하고 64비트 모드에서 REX 접두사와 선택적으로 결합되는 ModRM 바이트가 온다.
인텔 시큐어 키는 codice_1 명령어와 기본 난수 생성기 (RNG) 하드웨어 구현에 대한 인텔의 명칭으로, 개발 중에는 "불 마운틴"이라는 코드명을 가졌다. 인텔은 그들의 RNG를 "디지털 난수 생성기" 또는 DRNG라고 부른다. 이 생성기는 하드웨어 엔트로피 소스에서 생성된 256비트 원시 엔트로피 샘플 쌍을 가져와 고급 암호화 표준 (AES) (CBC-MAC 모드) 조건자에 적용하여 단일 256비트 조건화된 엔트로피 샘플로 줄인다. NIST SP 800-90A에 정의된 CTR DRBG라는 결정론적 난수 생성기는 조건자의 출력으로 시드되어 codice_1 명령어를 통해 요청하는 응용 프로그램에 암호학적으로 안전한 난수를 제공한다. 하드웨어는 시드 값을 변경하기 전에 최대 511개의 128비트 샘플을 발행한다. codice_3 연산을 사용하면 AES-CBC-MAC에서 조건화된 256비트 샘플에 액세스할 수 있다.
codice_3 명령어는 브로드웰 CPU에서 사용 가능한 다른 유사 난수 생성기를 시드하기 위해 인텔 시큐어 키에 추가되었다. codice_3 명령어의 엔트로피 소스는 자체 타이밍 회로에서 비동기적으로 실행되며 실리콘 내의 열 잡음을 사용하여 초당 3 GHz의 속도로 임의의 비트 스트림을 출력한다. 이는 codice_1에서 얻을 수 있는 유효 초당 6.4 기가비트보다 느리다(두 속도 모두 모든 코어와 스레드 간에 공유된다). codice_3 명령어는 임의의 너비의 소프트웨어 유사난수 생성기를 시드하는 데 사용되는 반면, codice_1는 단순히 고품질 난수를 요구하는 응용 프로그램에 사용된다. 암호화 보안이 필요하지 않은 경우 Xorshift와 같은 소프트웨어 PRNG가 일반적으로 더 빠르다.
인텔 코어 i7-7700K, 4500 MHz (45 × 100 MHz) 프로세서(카비레이크 마이크로아키텍처)에서 단일 codice_1 또는 codice_3 명령어는 피연산자 크기(16/32/64 비트)에 관계없이 110 ns, 즉 463 클럭 사이클이 소요된다. 이 클럭 사이클 수는 스카이레이크 또는 카비레이크 마이크로아키텍처를 사용하는 모든 프로세서에 적용된다. 실버몬트 마이크로아키텍처 프로세서에서는 각 명령어가 피연산자 크기에 관계없이 약 1472 클럭 사이클이 소요되며, 아이비브리지 프로세서에서는 codice_1가 최대 117 클럭 사이클이 소요된다.
AMD 라이젠 CPU에서 각 명령어는 16비트 또는 32비트 피연산자의 경우 약 1200 클럭 사이클, 64비트 피연산자의 경우 약 2500 클럭 사이클이 소요된다.
천체 물리학 몬테카를로 시뮬레이터는 쿼드 코어 인텔 i7-3740 QM 프로세서에서 codice_1를 사용하여 107개의 64비트 난수를 생성하는 시간을 조사했다. 그들은 codice_1의 C 구현이 C의 기본 난수 생성기보다 약 2배 느리고, 메르센 트위스터보다 약 20배 느리게 실행된다는 것을 발견했다. codice_1의 파이썬 모듈이 구축되었지만, 파이썬의 기본 난수 생성기보다 20배 느리다는 것이 밝혀졌다. 단, 유사난수와 CSPRNG 사이의 성능 비교는 할 수 없다.
2020년 6월 인텔이 발표한 마이크로코드 업데이트는 CrossTalk 취약점(아래 보안 문제 섹션 참조)을 완화하기 위해 설계되었으며, 추가 보안 제어로 인해 codice_1 및 codice_3의 성능에 부정적인 영향을 미친다. 완화 조치가 적용된 프로세서에서는 각 영향을 받는 명령어에 추가 지연 시간이 발생하고 코어 간 codice_1 또는 codice_3의 동시 실행이 효과적으로 직렬화된다. 인텔은 이러한 보안 검사를 완화하여 대부분의 시나리오에서 성능 영향을 줄이는 메커니즘을 도입했지만, 인텔 프로세서는 기본적으로 이 보안 완화를 적용하지 않는다.
비주얼 C++ 2015는 codice_1 및 codice_3 함수에 대한 내재적 래퍼 지원을 제공한다. GCC 4.6+ 및 클랭 3.2+는 플래그에 codice_35가 지정되었을 때 codice_1에 대한 내장 함수를 제공하며, 또한 codice_37를 설정하여 조건부 컴파일을 허용한다. 최신 버전은 codice_38를 추가로 제공하여 이러한 내장 함수를 인텔 C 컴파일러 버전 12.1+와 호환되는 함수로 래핑한다. 이 함수들은 매개변수가 가리키는 위치에 임의의 데이터를 쓰고 성공 시 1을 반환한다.
OpenSSL에서 codice_1 및 codice_3를 사용하여 암호학적으로 안전한 난수를 생성하는 것은 통신 보안을 돕는 하나의 옵션이다.
몬테카를로 시뮬레이터에서 codice_1의 과학적 적용이 성능 및 재현성을 중심으로 다른 난수 생성기와 비교하여 평가되었다. 그 결과 메르센 트위스터 대신 codice_1를 사용하는 것이 다른 결과를 제공하지 않지만 성능 및 재현성 측면에서 더 나쁘다는 결론이 나왔다.
2013년 9월, 뉴욕 타임스의 NSA가 암호화를 약화시키려는 노력을 폭로하는 기사에 대한 응답으로, 시어도어 초는 리눅스 커널의 codice_43에 codice_1를 사용하는 것에 대해 다음과 같이 공개적으로 게시했다.
리누스 토르발스는 리눅스 커널에서 codice_1 사용에 대한 우려를 일축하며, codice_43의 유일한 엔트로피 소스로 사용되지 않고, codice_1에서 받은 값과 다른 무작위성 소스를 결합하여 엔트로피를 향상시키는 데 사용된다고 지적했다. 그러나 디퓨즈 시큐리티의 테일러 혼비는 codice_1 명령어에 백도어가 도입되어 이를 사용하는 코드를 특별히 표적으로 삼는 경우 리눅스 난수 생성기가 불안정해질 수 있음을 입증했다. 혼비의 개념 증명 구현은 버전 3.13 이전의 수정되지 않은 리눅스 커널에서 작동한다. 이 문제는 2013년 리눅스 커널에서 완화되었다.
개발자들은 FreeBSD 커널을 codice_1와 VIA PadLock을 직접 사용하는 방식에서 다음과 같은 주석과 함께 변경했다. "FreeBSD 10의 경우, codice_1와 Padlock 백엔드를 되돌리고 제거하여 그 출력을 codice_43으로 직접 전달하는 대신 야로우에 공급할 것이다. 필요한 경우 인라인 어셈블리 또는 사용자 공간에서 OpenSSL을 사용하여 하드웨어 난수 생성기, 즉 codice_1, Padlock 등에 직접 액세스하는 것은 여전히 가능하지만, 우리는 더 이상 그들을 신뢰할 수 없다." FreeBSD /dev/random은 포르투나를 사용하며 RDRAND는 FreeBSD 11부터 시작되었다.
2020년 6월 9일, 암스테르담 자유 대학교 연구원들은 여러 인텔 프로세서의 codice_1에 영향을 미치는 CrossTalk(CVE-2020-0543)라는 부채널 공격을 발표했다. 그들은 하드웨어 디지털 난수 생성기(DRNG)의 출력이 모든 코어에서 공유되는 스테이징 버퍼에 저장된다는 것을 발견했다. 이 취약점은 영향을 받는 프로세서에서 실행되는 악성 코드가 동일한 프로세서의 다른 코어에서 실행되는 피해 응용 프로그램(인텔 SGX 엔클레이브 내에서 실행되는 응용 프로그램 포함)에서 codice_1 및 codice_3 명령어 결과를 읽을 수 있도록 허용했다. 연구원들은 단 한 번의 서명 작업 후에 별도의 CPU 코어에서 실행되는 SGX 엔클레이브에서 완전한 ECDSA 키를 추출하는 개념 증명 익스플로잇을 개발했다. 이 취약점은 공유 호스팅 환경과 같이 신뢰할 수 없는 코드가 신뢰할 수 있는 코드와 동일한 프로세서에서 함께 실행되는 시나리오에 영향을 미친다.
인텔은 CrossTalk 취약점을 특별 레지스터 버퍼 데이터 샘플링(SRBDS)이라고 부른다. 연구 결과에 따라 인텔은 이 문제를 완화하기 위한 마이크로코드 업데이트를 발표했다. 업데이트된 마이크로코드는 민감한 작업(특히 codice_1, codice_3, codice_58 명령어)이 완료되고 스테이징 버퍼가 덮어씌워질 때까지 코어 외부 액세스가 지연되도록 보장한다. SRBDS 공격은 MSR을 읽는 것과 같은 다른 명령어에도 영향을 미치지만, 인텔은 성능 문제와 해당 명령어 결과의 기밀성 필요성이 적다는 이유로 추가 보안 보호를 적용하지 않았다. 2012년에서 2019년 사이에 출시된 광범위한 인텔 프로세서(데스크탑, 모바일, 서버 프로세서 포함)가 영향을 받았다. 완화 자체는 영향을 받는 명령어 사용 시 성능에 부정적인 영향을 미쳤는데, 특히 멀티 스레드 응용 프로그램에서 병렬로 실행될 때 보안 검사로 인한 지연 시간 증가와 코어 간 영향을 받는 명령어의 효과적인 직렬화로 인해 더욱 그러했다. 인텔은 각 논리 프로세서의 codice_59 MSR을 통해 구성할 수 있는 옵트아웃 옵션을 도입하여 SGX 엔클레이브 외부에서 실행되는 명령에 대한 추가 보안 검사를 비활성화함으로써 성능을 향상시켰다.
무자리수 곱셈(Carry-less Multiplication, CLMUL)은 인텔과 AMD의 마이크로프로세서에 사용되는 X86 명령어 집합의 확장으로, 2008년 3월 인텔이 제안했고 2010년 초에 발표된 인텔 웨스트미어 프로세서에서 사용할 수 있게 되었다. 수학적으로 이 명령어는 비트열 formula_1이 다항식 formula_2을 나타내는 유한체 GF(2)에 대한 다항식 곱셈을 구현한다. CLMUL 명령어는 또한 전통적인 명령어 집합보다 훨씬 더 효율적으로 밀접하게 관련된 더 큰 유한체 GF(2k)의 곱셈을 구현할 수 있게 해준다.
이 명령어들의 한 가지 용도는 유한체 GF(2k) 곱셈에 의존하는 갈루와/카운터 모드에서 블록 암호화 애플리케이션의 속도를 향상시키는 것이다. 또 다른 적용 분야는 CRC 값의 빠른 계산인데, 여기에는 Zlib 및 pngcrush에서 LZ77 슬라이딩 윈도우 DEFLATE 알고리즘을 구현하는 데 사용되는 CRC 값도 포함된다.
ARMv8에도 CLMUL 버전이 있다. SPARC는 그들의 버전을 "XOR 곱셈"을 의미하는 XMULX라고 부른다.
새로운 명령어.
이 명령어는 두 개의 64비트 값에 대한 128비트 무자리수 곱셈을 계산한다. 대상은 128비트 XMM 레지스터이다. 소스는 다른 XMM 레지스터 또는 메모리일 수 있다. 즉시 피연산자는 128비트 피연산자의 어느 절반이 곱해지는지를 지정한다. 즉시 피연산자의 특정 값을 지정하는 니모닉도 정의되어 있다.
EVEX 벡터화 버전(VPCLMULQDQ)은 AVX-512에서 볼 수 있다.
CLMUL 명령어 집합을 갖춘 CPU.
CLMUL 명령어 집합의 존재 여부는 중 하나를 테스트하여 확인할 수 있다.
LZ77과 LZ78은 1977년과 1978년 아브라함 렘펠과 야코브 지브가 논문으로 발표한 두 가지 비손실 데이터 압축 알고리즘이다.
이들은 각각 렘펠-지브 1 (LZ1)과 렘펠-지브 2 (LZ2)로도 알려져 있다. 이 두 알고리즘은 LZW, LZSS, LZMA 및 기타 여러 변형의 기초를 형성한다. 학술적 영향 외에도 이 알고리즘은 GIF 및 이동식 네트워크 그래픽과 ZIP에서 사용되는 DEFLATE 알고리즘을 포함하여 여러 유비쿼터스 압축 체계의 기반을 형성했다.
둘 다 이론적으로는 사전 기반 부호화 방식이다. LZ77은 압축 중에 슬라이딩 윈도우를 유지한다. 이는 나중에 LZ78이 구성한 명시적 사전과 동등하다는 것이 밝혀졌지만, 전체 데이터가 압축 해제될 때만 동등하다.
LZ77은 이전에 본 문자를 슬라이딩 윈도우를 통해 인코딩하고 디코딩하므로 압축 해제는 항상 입력의 시작 부분에서 시작해야 한다. 개념적으로 LZ78 압축 해제는 전체 사전이 미리 알려져 있다면 입력에 대한 임의 접근을 허용할 수 있다. 그러나 실제로는 토큰이 출력될 때마다 새 구문을 생성하여 인코딩 및 디코딩 중에 사전이 생성된다.
이 알고리즘은 2004년에 IEEE 마일스톤으로 지정되었다. 2021년 야코브 지브는 이들의 개발에 참여한 공로로 IEEE 명예의 메달을 수상했다.
이론적 효율성.
이 알고리즘들을 소개한 두 논문 중 두 번째 논문에서는 이들을 유한 상태 기계로 정의된 인코더로 분석한다. (확률적 앙상블이 아닌) 개별 시퀀스에 대해 정보 엔트로피와 유사한 측정값이 개발된다. 이 측정값은 달성할 수 있는 데이터 압축비에 대한 경계를 제공한다. 그런 다음 시퀀스 길이가 무한대로 증가함에 따라 이 경계를 달성하는 모든 시퀀스에 대해 유한 비손실 인코더가 존재함을 보여준다. 이러한 의미에서 이 체계에 기반한 알고리즘은 점근적으로 최적의 인코딩을 생성한다. 이 결과는 피터 쇼어의 노트에서와 같이 더 직접적으로 증명될 수 있다.
형식적으로는 (정리 13.5.2).
유사한 정리들이 LZ 알고리즘의 다른 버전에도 적용된다.
LZ77.
LZ77 알고리즘은 압축되지 않은 데이터 스트림에 이전에 존재하는 단일 데이터 복사본에 대한 참조로 데이터의 반복적인 발생을 대체하여 압축을 달성한다. 일치하는 부분은 길이-거리 쌍이라고 불리는 두 개의 숫자로 인코딩되며, 이는 "다음 길이 문자 각각은 압축되지 않은 스트림에서 정확히 거리만큼 뒤에 있는 문자와 같다"는 진술과 동일하다. (거리는 때때로 오프셋이라고도 불린다.)
일치하는 부분을 찾기 위해 인코더는 가장 최근 데이터의 일부, 예를 들어 지난 2 KB, 4 KB 또는 32 KB를 추적해야 한다. 이 데이터를 담는 구조를 슬라이딩 윈도우라고 부르며, 이 때문에 LZ77을 슬라이딩 윈도우 압축이라고도 한다. 인코더는 일치하는 부분을 찾기 위해 이 데이터를 유지해야 하며, 디코더는 인코더가 참조하는 일치하는 부분을 해석하기 위해 이 데이터를 유지해야 한다. 슬라이딩 윈도우가 클수록 인코더가 참조를 생성하기 위해 더 오래 전으로 검색할 수 있다.
길이-거리 쌍이 실제로 거리보다 긴 길이를 지정하는 것을 허용하는 것은 허용될 뿐만 아니라 자주 유용하다. 복사 명령으로서 이것은 혼란스러울 수 있다: "네 글자 뒤로 돌아가서 그 위치에서 열 글자를 현재 위치로 복사하시오." 단 네 글자만 버퍼에 있는데 어떻게 열 글자를 복사할 수 있는가? 한 번에 한 바이트씩 처리하면 이 요청을 처리하는 데 문제가 없다. 바이트가 복사될 때마다 복사 명령의 입력으로 다시 공급될 수 있기 때문이다. 복사-원본 위치가 초기 대상 위치에 도달하면 결과적으로 복사-원본 위치의 시작 부분에서 붙여넣어진 데이터를 공급받는다. 따라서 이 작업은 "주어진 데이터를 복사하여 맞을 때까지 반복적으로 붙여넣으시오"라는 진술과 동일하다. 이 유형의 쌍은 단일 데이터 복사본을 여러 번 반복하므로 런 렝스 부호화의 유연하고 쉬운 형태를 통합하는 데 사용될 수 있다.
다른 방식으로 보자면 다음과 같다. 인코딩하는 동안 검색 포인터가 검색 윈도우의 끝을 지나서 일치하는 쌍을 계속 찾으려면 오프셋 D에서 첫 번째 일치 항목부터 검색 윈도우 끝까지의 모든 문자가 입력과 일치해야 하며, 이들은 길이 LR의 단일 실행 단위를 구성하는 (이전에 본) 문자여야 하며, 이는 D와 같아야 한다. 그런 다음 검색 포인터가 검색 윈도우를 지나서 앞으로 진행하면서, 입력에서 실행 패턴이 반복되는 한, 검색 및 입력 포인터는 동기화되어 실행 패턴이 중단될 때까지 문자를 일치시킨다. 그러면 총 L 문자가 일치했고, L &gt; D이며, 코드는 [D, L, c]이다.
[D, L, c]를 디코딩할 때도 마찬가지로 D = LR이다. 첫 번째 LR 문자가 출력으로 읽힐 때, 이는 출력 버퍼에 추가된 단일 실행 단위에 해당한다. 이 시점에서 읽기 포인터는 해당 단일 버퍼링된 실행 단위의 시작 부분으로 int(L/LR) + (L mod LR ≠ 0일 경우 1)번만 돌아가서 LR 문자를 읽고(또는 마지막 반환 시 더 적은 수) 총 L 문자가 읽힐 때까지 반복하면 된다고 생각할 수 있다. 그러나 인코딩 프로세스를 반영하여 패턴이 반복적이므로 읽기 포인터는 총 L 문자가 출력으로 복사될 때까지 쓰기 포인터와 실행 길이 LR과 동일한 고정된 거리만큼 동기화되어 따라가기만 하면 된다.
위의 내용을 고려할 때, 특히 데이터 실행 압축이 지배적일 것으로 예상되는 경우, 윈도우 검색은 윈도우 끝에서 시작하여 뒤로 진행해야 한다. 실행 패턴이 존재한다면 먼저 발견되어 검색을 종료할 수 있기 때문이다. 현재 최대 일치 시퀀스 길이가 충족되면 절대적으로, 또는 충분한 길이가 충족되면 신중하게, 그리고 마지막으로 데이터가 더 최근이고 다음 입력과 더 잘 연관될 가능성이 있다는 단순한 이유 때문에 그렇게 해야 한다.
다음 의사 코드는 LZ77 압축 알고리즘의 슬라이딩 윈도우를 재현한 것이다.
while 입력이 비어 있지 않다면 do
match := 윈도우에서 시작하는 입력의 가장 긴 반복 일치
if 일치하는 부분이 존재한다면 then
d := 일치하는 부분 시작까지의 거리
l := 일치하는 부분의 길이
c := 입력에서 일치하는 부분 다음에 오는 문자
d := 0
l := 0
c := 입력의 첫 번째 문자
output (d, l, c)
윈도우 앞에서 l + 1 문자를 버린다.
s := 입력 앞에서 l + 1 문자를 꺼낸다.
s를 윈도우 뒤에 추가한다.
모든 LZ77 알고리즘은 정의상 동일한 기본 원리로 작동하지만, 길이-거리 쌍의 숫자 범위를 변경하고, 길이-거리 쌍에 사용되는 비트 수를 변경하고, 길이-거리 쌍과 리터럴(길이-거리 쌍의 일부가 아닌 자체로 인코딩된 원시 데이터)을 구별하는 방식에 따라 압축된 데이터를 인코딩하는 방식이 크게 달라질 수 있다. 몇 가지 예는 다음과 같다.
LZ78.
LZ78 알고리즘은 입력에서 토큰 시퀀스의 사전을 구축한 다음, 데이터 스트림에서 해당 시퀀스의 두 번째 및 이후 발생을 사전 항목에 대한 참조로 대체하여 순차 데이터를 압축한다. 여기서의 관찰은 반복되는 시퀀스의 수가 시퀀스의 무작위적이지 않은 특성을 잘 나타내는 척도라는 것이다. 이 알고리즘은 사전을 n진 트리로 표현하며, 여기서 n은 토큰 시퀀스를 형성하는 데 사용되는 토큰의 수이다. 각 사전 항목은 형식으로, 여기서 index는 이전에 본 시퀀스를 나타내는 사전 항목에 대한 색인이고, token은 이 항목을 사전에서 고유하게 만드는 입력의 다음 토큰이다. 알고리즘이 탐욕적이어서 고유한 토큰이 발견될 때까지는 아무것도 테이블에 추가되지 않는다는 점에 유의해야 한다. 알고리즘은 마지막 일치 색인 = 0 및 다음 사용 가능한 색인 = 1로 초기화한 다음, 입력 스트림의 각 토큰에 대해 사전을 검색하여 일치하는 부분을 찾는다: . 일치하는 부분이 발견되면 마지막 일치 색인이 일치하는 항목의 색인으로 설정되고, 아무것도 출력되지 않으며, 마지막 일치 색인은 지금까지의 입력을 계속 나타낸다. 일치하는 부분이 발견되지 않을 때까지 입력이 처리된다. 그런 다음 새 사전 항목이 생성된다: , 그리고 알고리즘은 마지막 일치 색인과 토큰을 출력한 다음, 마지막 일치 색인을 0으로 재설정하고 다음 사용 가능한 색인을 1 증가시킨다. 예를 들어, 토큰 시퀀스를 고려하면 다음과 같은 사전이 구성된다.
그리고 압축된 데이터의 출력 시퀀스는 가 된다. 마지막 A는 알고리즘이 다음에 무엇이 올지 알 수 없으므로 아직 표현되지 않는다는 점에 유의해야 한다. 실제로는 EOF 마커가 입력에 추가된다. 예를 들어 와 같이. 또한 이 경우 출력 가 원본 입력보다 길지만, 사전이 커질수록 압축률이 상당히 향상되며, 이진에서는 색인을 최소 비트 수 이상으로 표현할 필요가 없다는 점도 유의해야 한다.
압축 해제는 압축된 시퀀스에서 사전을 재구성하는 것으로 구성된다. 시퀀스 에서 첫 번째 항목은 항상 종결자 이며, 시퀀스에서 첫 번째 항목은 가 된다. 는 출력에 추가된다. 입력에서 두 번째 쌍은 이며, 사전에서 항목 번호 2, 를 생성한다. 토큰 "B"가 출력되고, 그 앞에 사전 항목 1이 나타내는 시퀀스가 붙는다. 항목 1은 'A' (그 뒤에 "항목 0" - 아무것도 없음)이므로 가 출력에 추가된다. 다음으로 는 사전의 다음 항목으로 추가되며, 가 되고, B (그 앞에 아무것도 없음)가 출력에 추가된다. 마지막으로 에 대한 사전 항목이 생성되고 가 출력되어 또는 공백과 EOF 마커를 제거한 가 된다.
LZW.
LZW는 모든 가능한 문자(기호) 또는 사전 초기화 에뮬레이션으로 미리 초기화된 사전을 사용하는 LZ78 기반 알고리즘이다. LZW의 주요 개선 사항은 일치하는 항목을 찾을 수 없는 경우 현재 입력 스트림 문자가 사전의 기존 문자열의 첫 번째 문자라고 가정하므로(사전이 모든 가능한 문자로 초기화되었기 때문에) 마지막 일치 색인만 출력된다는 것이다(이것은 이전 (또는 초기) 입력 문자에 해당하는 미리 초기화된 사전 색인일 수 있다). 구현 세부 사항은 LZW 문서를 참조하라.
BTLZ는 실시간 통신 시스템(원래 모뎀)에 사용하기 위해 개발된 LZ78 기반 알고리즘으로, CCITT/ITU에 의해 V.42bis로 표준화되었다. 트라이 구조 사전이 가득 차면, 사전이 변화하는 데이터에 계속 적응할 수 있도록 간단한 재사용/복구 알고리즘이 사용된다. 카운터는 사전을 순환한다. 새 항목이 필요하면 카운터는 리프 노드(종속 노드가 없는 노드)를 찾을 때까지 사전을 순환한다. 이 노드는 삭제되고 공간은 새 항목에 재사용된다. 이는 LRU 또는 LFU보다 구현이 간단하고 동등한 성능을 달성한다.
렘펠-지브-스토러-시만스키(Lempel–Ziv–Storer–Szymanski, LZSS)는 비손실 데이터 압축 알고리즘으로, LZ77의 파생형이며 1982년 제임스 A. 스토러와 토마스 시만스키가 만들었다. LZSS는 Journal of the ACM에 실린 "Data compression via textual substitution"(1982, pp. 928–951) 기사에서 설명되었다.
LZSS는 사전 기반 부호화 기술이다. 이는 기호 문자열을 동일한 문자열의 사전 위치 참조로 바꾸려고 시도한다.
LZ77과 LZSS의 주요 차이점은 LZ77에서는 사전 참조가 실제로 대체하는 문자열보다 길 수 있다는 것이다. LZSS에서는 길이가 "손익분기점"보다 작으면 이러한 참조가 생략된다. 또한 LZSS는 다음 데이터 덩어리가 리터럴(바이트)인지 오프셋/길이 쌍에 대한 참조인지 나타내는 1비트 플래그를 사용한다.
다음은 편의를 위해 줄 시작 부분에 문자 번호가 붙은 닥터 수스의 녹색 달걀과 햄의 시작 부분이다. 녹색 달걀과 햄은 책 자체는 170단어임에도 불구하고 50개의 고유한 단어만을 포함하고 있기 때문에 LZSS 압축을 설명하는 좋은 예이다. 따라서 단어는 반복되지만 연속적이지는 않다.
이 텍스트는 압축되지 않은 형태로 177바이트를 차지한다. 손익분기점을 2바이트(따라서 2바이트 포인터/오프셋 쌍)로 가정하고 한 바이트의 개행 문자를 가정하면, 이 텍스트는 LZSS로 압축되어 95바이트가 된다.
참고: 여기에는 다음 텍스트 덩어리가 포인터인지 리터럴인지를 나타내는 11바이트의 플래그는 포함되지 않았다. 이를 추가하면 텍스트는 106바이트가 되며, 이는 여전히 원래의 177바이트보다 짧다.
ARJ, RAR, ZOO, LHarc와 같은 많은 인기 있는 압축 프로그램은 LZ77 대신 LZSS를 주 압축 알고리즘으로 사용한다. 리터럴 문자와 길이-거리 쌍의 인코딩은 다양하며, 가장 일반적인 옵션은 허프먼 부호화이다. 대부분의 구현은 하루히코 오쿠무라가 1989년에 만든 퍼블릭 도메인 코드에서 파생되었다. 알레그로 라이브러리 버전 4는 LZSS 형식을 인코딩 및 디코딩할 수 있지만 버전 5에서는 이 기능이 제거되었다. 게임보이 어드밴스 BIOS는 약간 수정된 LZSS 형식을 디코딩할 수 있다. 애플의 macOS는 LZSS를 커널 코드의 압축 방식 중 하나로 사용한다.
인텔 소프트웨어 가드 익스텐션(Intel Software Guard Extensions, SGX)은 일부 인텔 중앙 처리 장치(CPU)에 내장된 신뢰 실행 환경을 구현하는 명령어 집합이다. 이를 통해 사용자 수준 및 운영체제 코드가 인클레이브(enclave)라고 불리는 보호된 개인 메모리 영역을 정의할 수 있다. SGX는 보안 원격 컴퓨팅, 보안 웹 브라우징 및 디지털 권리 관리(DRM) 구현에 유용하도록 설계되었다. 다른 응용 프로그램으로는 사유 알고리즘 및 암호화 키 숨기기가 있다.
SGX는 CPU가 메모리 일부(인클레이브)를 암호화하는 것을 포함한다. 인클레이브에서 생성된 데이터와 코드는 CPU 내에서 실시간으로 복호화되어 다른 코드, 즉 운영체제 및 기본 하이퍼바이저와 같은 더 높은 권한 수준에서 실행되는 코드에 의해 검사되거나 읽히는 것을 방지한다. 이는 많은 종류의 공격을 완화할 수 있지만, 부채널 공격으로부터는 보호하지 못한다.
2021년 인텔의 정책 변경으로 11세대 및 12세대 인텔 코어 프로세서에서 SGX가 사용 중단되었지만, 클라우드 및 엔터프라이즈용 인텔 제온에서는 계속 개발되고 있다.
SGX는 2015년에 스카이레이크 마이크로아키텍처 기반의 6세대 인텔 코어 마이크로프로세서와 함께 처음 도입되었다.
CPU의 SGX 지원은 CPUID "구조화 확장 기능 리프(Structured Extended feature Leaf)", EBX 비트 02에 표시되지만, 애플리케이션에서 사용하려면 바이오스/통합 확장 펌웨어 인터페이스 지원 및 선택적 활성화가 필요하며 이는 CPUID 비트에 반영되지 않는다. 이로 인해 애플리케이션의 기능 감지 로직이 복잡해진다.
SGX 에뮬레이션은 2014년에 QEMU 시스템 에뮬레이터의 실험 버전에서 추가되었다. 2015년 조지아 공과대학교 연구원들은 "OpenSGX"라는 오픈 소스 시뮬레이터를 발표했다.
SGX가 보안에 사용된 한 가지 예는 울프SSL의 암호화 알고리즘을 위한 데모 애플리케이션이었다.
인텔 골드몬트 플러스(제미니 레이크) 마이크로아키텍처도 인텔 SGX를 지원한다.
11세대와 12세대 인텔 코어 프로세서 모두에서 SGX는 "사용 중단"으로 표시되어 "클라이언트 플랫폼" 프로세서에서는 지원되지 않는다. 이로 인해 파워DVD와 같이 공식적으로 라이선스가 부여된 소프트웨어에서 울트라 HD 블루레이 디스크 재생 지원이 중단되었다.
SGX 취약점 목록.
프라임+프로브 공격.
2017년 3월 27일, 오스트리아 그라츠 공과대학교의 연구원들은 세분화된 타이머 대신 특정 CPU 명령어를 사용하여 캐시 DRAM 부채널을 악용함으로써 동일 시스템에서 실행되는 SGX 인클레이브로부터 RSA 키를 5분 이내에 획득할 수 있는 개념 증명을 개발했다. 이 유형의 공격에 대한 한 가지 대응책은 2017년 USENIX 보안 심포지엄에서 다니엘 그루스 등이 발표했다. 다른 공개된 대응책 중 하나로, 2017년 9월 28일에 컴파일러 기반 도구인 DR.SGX가 발표되었는데, 이는 다른 제안된 솔루션의 구현 복잡성을 제거하면서도 우수한 성능을 제공한다고 주장한다.
스펙터 유사 공격.
임페리얼 칼리지 런던의 LSDS 그룹은 스펙터 투기적 실행 보안 취약점을 안전한 인클레이브 공격에 적용할 수 있다는 개념 증명을 제시했다. 2018년 8월에 공개된 포어섀도 공격은 투기적 실행과 버퍼 오버플로를 결합하여 SGX를 우회한다. L1 터미널 폴트라고도 불리는 이 공격에 대한 보안 권고 및 완화책은 원래 2018년 8월 14일에 발표되었고 2021년 5월 11일에 업데이트되었다.
인클레이브 공격.
2019년 2월 8일, 오스트리아 그라츠 공과대학교 연구원들은 일부 경우 인클레이브 자체 내에서 악성 코드를 실행할 수 있음을 보여주는 연구 결과를 발표했다. 이 익스플로잇은 페이로드를 재구성하기 위해 프로세스 메모리를 스캔한 다음 시스템에서 코드를 실행할 수 있다. 논문은 인클레이브의 기밀하고 보호된 특성 때문에 바이러스 백신 소프트웨어가 그 안에 있는 악성 코드를 탐지하고 제거하는 것이 불가능하다고 주장한다. 인텔은 이 공격이 SGX의 위협 모델 범위를 벗어났으며, 사용자가 실행하는 코드가 신뢰할 수 있는 소스에서 온 것임을 보장할 수 없으며, 소비자에게 신뢰할 수 있는 코드만 실행하도록 촉구한다는 성명을 발표했다.
마이크로스코프 리플레이 공격.
최신 컴퓨터 아키텍처를 괴롭히는 부채널 공격이 확산되고 있다. 이러한 공격 중 다수는 코드 실행의 미세하고 비결정적인 변동을 측정하므로, 공격자는 비밀을 알아내기 위해 많은 측정값(수만 개일 수도 있음)이 필요하다. 그러나 마이크로스코프 공격은 악성 OS가 프로그램의 실제 구조와 상관없이 코드를 임의의 횟수만큼 재생할 수 있게 하여 수십 가지의 부채널 공격을 가능하게 한다. 2022년 7월, 인텔은 SGX 인클레이브 프로그래머가 이러한 유형의 이벤트를 처리할 핸들러를 작성할 수 있도록 AEX-Notify라는 리눅스 패치를 제출했다.
플런더볼트.
보안 연구원들은 인클레이브 내 실행에 타이밍 특정 결함을 주입하여 정보 유출을 초래할 수 있었다. 이 공격은 원격으로 실행될 수 있지만, 프로세서의 전압과 주파수에 대한 특권 제어에 접근해야 한다. 이 공격에 대한 보안 권고 및 완화책은 원래 2018년 8월 14일에 발표되었고 2020년 3월 20일에 업데이트되었다.
로드 값 주입(Load Value Injection)은 메모리에서 로드된 값을 대체하기 위해 프로그램에 데이터를 주입하는 것을 목표로 한다. 이 값은 오류가 발견되고 롤백되기 전까지 잠시 사용되며, 그 동안 LVI는 데이터 및 제어 흐름을 제어한다. 이 공격에 대한 보안 권고 및 완화책은 원래 2020년 3월 10일에 발표되었고 2021년 5월 11일에 업데이트되었다.
SGAxe.
2020년에 발표된 SGX 취약점인 SGAxe는 캐시에 대한 투기적 실행 공격을 확장하여 인클레이브의 내용을 유출한다. 이를 통해 공격자는 원격 인증에 사용되는 개인 CPU 키에 접근할 수 있다. 다시 말해, 위협 행위자는 인텔의 대응책을 우회하여 SGX 인클레이브의 기밀성을 침해할 수 있다. SGAxe 공격은 인텔이 서명한 SGX의 개인 인용 인클레이브에서 인증 키를 추출하여 수행된다. 공격자는 그 다음 임의의 SGX 인증 인용에 서명함으로써 합법적인 인텔 기계로 위장할 수 있다. 프로세서 데이터 유출 또는 캐시 이빅션(Cache Eviction)이라고도 불리는 이 공격에 대한 보안 권고 및 완화책은 원래 2020년 1월 27일에 발표되었고 2021년 5월 11일에 업데이트되었다.
ÆPIC 누출.
2022년 보안 연구원들은 고급 프로그래머블 인터럽트 컨트롤러(APIC)에서 취약점을 발견했는데, 이는 루트/관리자 권한을 가진 공격자가 L1 및 L2 캐시의 데이터 전송을 검사하여 APIC를 통해 암호화 키에 접근할 수 있도록 한다. 이 취약점은 X86 CPU에서 발견된 최초의 아키텍처 공격이다. 이는 시끄러운 부채널을 사용하는 스펙터 및 멜트다운과는 다르다. 이 익스플로잇은 현재 인텔 코어 10세대, 11세대, 12세대 및 제온 아이스 레이크 마이크로프로세서에 영향을 미친다.
개인 키 추출.
코드 서명은 인클레이브에만 있는 개인 키로 생성된다. 개인 키는 칩의 "퓨즈" 요소를 통해 인코딩된다. 이 과정에서 비트가 타버려 이진 값 0이 된다. 이 개인 키는 하드웨어에 인코딩되어 추출할 수 없다. 마크 에르몰로프(Mark Ermolov), 막심 고랴치(Maxim Goryachy), 드미트리 스클랴로프(Dmitry Sklyarov)는 https://github.com/chip-red-pill/glm-ucode#에서 SGX 개념의 신뢰성에 대한 주장을 반박했다.
SGX 악성 코드 주장.
SGX가 우수한 악성 코드 생성을 가능하게 하는지에 대한 오랜 논쟁이 있었다. 옥스퍼드 대학교 연구원들은 2022년 10월에 발표한 논문에서 악성 코드 개발을 위해 SGX를 오용할 경우 공격자에게 잠재적인 장단점을 고려했다. 연구원들은 SGX 생태계에서 악용될 수 있는 일시적인 제로데이 취약점이 있을 수 있지만, 신뢰 실행 환경(TEE)의 핵심 원칙과 설계 특징은 악성 코드를 야생의 악성 코드보다 약하게 만들며, TEE는 그렇지 않은 경우 악성 코드에 크게 기여하지 않는다고 결론 내렸다.
LZ4는 다음 뜻이 있다.
LZ4는 압축 및 압축 해제 속도에 초점을 맞춘 비손실 데이터 압축 알고리즘이다. 이는 바이트 지향 압축 방식인 LZ77 계열에 속한다.
LZ4 알고리즘은 속도와 압축률 간의 좋은 절충점을 제공하는 것을 목표로 한다. 일반적으로 유사한 LZO 알고리즘보다 압축률이 더 낮고(즉, 나쁘고), LZO는 다시 DEFLATE와 같은 알고리즘보다 나쁘다. 그러나 LZ4의 압축 속도는 LZO와 유사하며 DEFLATE보다 몇 배 빠르며, 압축 해제 속도는 LZO보다 훨씬 빠르다.
LZ4는 사전 일치 단계(LZ77)만 사용하며, 다른 일반적인 압축 알고리즘과는 달리 이를 엔트로피 부호화 단계(예: DEFLATE의 허프먼 부호화)와 결합하지 않는다.
LZ4 알고리즘은 데이터를 일련의 시퀀스로 표현한다. 각 시퀀스는 두 개의 4비트 필드로 나뉜 1바이트 토큰으로 시작한다. 첫 번째 필드는 출력으로 복사될 리터럴 바이트 수를 나타낸다. 두 번째 필드는 이미 디코딩된 출력 버퍼에서 복사할 바이트 수를 나타낸다 (0은 최소 일치 길이인 4바이트를 나타낸다). 두 비트 필드 중 하나에서 15 값은 길이가 더 크며 길이에 추가될 추가 바이트 데이터가 있음을 나타낸다. 이러한 추가 바이트에서 255 값은 또 다른 바이트가 추가될 것임을 나타낸다. 따라서 임의의 길이는 255 값을 포함하는 일련의 추가 바이트로 표현된다. 리터럴 문자열은 토큰과 문자열 길이를 나타내는 데 필요한 추가 바이트 뒤에 온다. 그 다음에는 출력 버퍼에서 얼마나 뒤로 복사를 시작할지를 나타내는 오프셋이 온다. 일치 길이의 추가 바이트(있는 경우)는 시퀀스의 끝에 온다.
압축은 스트림 또는 블록 단위로 수행할 수 있다. 최적의 일치를 찾는 데 더 많은 노력을 기울임으로써 더 높은 압축률을 달성할 수 있다. 이는 더 작은 출력과 더 빠른 압축 해제를 모두 가능하게 한다.
LZ4는 두 가지 프레임 형식을 가지고 있다. 이전 형식은 매우 제한적이었고 외부 파일 끝 신호에 의존했는데, 이는 리눅스 Initramfs에서 제로 패딩을 처리하기 위한 해결책이 필요하다는 문제로 나타났다. 새로운 형식은 훨씬 더 유연하며 자체적인 프레임 끝 마커를 가지고 있다. 이는 Zstd 프레임 형식과 디자인이 유사하다.
얀 콜레의 C로 된 참조 구현은 BSD 라이선스에 따라 라이선스된다. 자바, C#, 러스트, 파이썬을 포함한 다양한 언어로 포트 및 바인딩이 존재한다. 아파치 하둡 시스템은 이 알고리즘을 빠른 압축을 위해 사용한다. LZ4는 리눅스 커널 3.11에도 네이티브로 구현되었다. FreeBSD, Illumos, 리눅스의 ZFS, ZFS-OSX의 ZFS 파일 시스템 구현은 즉석 압축을 위한 LZ4 알고리즘을 지원한다. 리눅스는 3.19-rc1부터 SquashFS에 LZ4를 지원한다. LZ4는 얀 콜레의 최신 Zstd 명령줄 유틸리티와 7-Zip-zstd라는 7-Zip 포크에서도 지원된다.
전향 변환(Move-to-front transform, MTF 변환)은 데이터 압축 기술인 엔트로피 부호화의 성능을 향상시키기 위해 설계된 데이터(일반적으로 바이트 스트림)의 인코딩이다. 효율적으로 구현될 경우, 데이터 압축 알고리즘에 추가 단계로 포함될 만큼 충분히 빠르다.
이 알고리즘은 1980년 가 "책 스택(book stack)"이라는 이름으로 처음 발표했다. 이후 1986년 J.K. 벤틀리 등이 재발견했으며, 이는 설명 노트에 명시되어 있다.
주요 아이디어는 데이터의 각 심볼이 "최근 사용된 심볼" 스택에서의 해당 인덱스로 대체된다는 것이다. 예를 들어, 동일한 심볼의 긴 시퀀스는 동일한 수의 0으로 대체되는 반면, 오랫동안 사용되지 않은 심볼이 나타나면 큰 숫자로 대체된다. 따라서 최종적으로 데이터는 일련의 정수로 변환된다. 데이터가 많은 지역 상관관계를 나타내면 이 정수들은 작은 경향이 있다.
정확한 설명을 제공해 보겠다. 간단화를 위해 데이터의 심볼이 바이트라고 가정한다.