KR20190029501A - 메타데이터 프로세싱 기술 - Google Patents
메타데이터 프로세싱 기술 Download PDFInfo
- Publication number
- KR20190029501A KR20190029501A KR1020187020288A KR20187020288A KR20190029501A KR 20190029501 A KR20190029501 A KR 20190029501A KR 1020187020288 A KR1020187020288 A KR 1020187020288A KR 20187020288 A KR20187020288 A KR 20187020288A KR 20190029501 A KR20190029501 A KR 20190029501A
- Authority
- KR
- South Korea
- Prior art keywords
- tag
- metadata
- rule
- instruction
- memory
- Prior art date
Links
- 238000012545 processing Methods 0.000 title claims abstract description 528
- 238000005516 engineering process Methods 0.000 title abstract description 4
- 238000000034 method Methods 0.000 claims abstract description 499
- 230000015654 memory Effects 0.000 claims description 1001
- 230000008569 process Effects 0.000 claims description 217
- 238000012546 transfer Methods 0.000 claims description 111
- 230000001960 triggered effect Effects 0.000 claims description 56
- 239000002131 composite material Substances 0.000 claims description 50
- 239000004744 fabric Substances 0.000 claims description 44
- 230000004044 response Effects 0.000 claims description 42
- 230000009471 action Effects 0.000 claims description 39
- 230000001404 mediated effect Effects 0.000 claims description 10
- 230000015572 biosynthetic process Effects 0.000 claims 2
- 238000003786 synthesis reaction Methods 0.000 claims 2
- 238000013475 authorization Methods 0.000 description 65
- 230000006399 behavior Effects 0.000 description 53
- 230000007246 mechanism Effects 0.000 description 39
- 239000000872 buffer Substances 0.000 description 35
- 230000000875 corresponding effect Effects 0.000 description 34
- 238000005457 optimization Methods 0.000 description 31
- 238000013507 mapping Methods 0.000 description 25
- 230000002829 reductive effect Effects 0.000 description 25
- 230000006870 function Effects 0.000 description 23
- 238000001193 catalytic steam reforming Methods 0.000 description 21
- 239000003086 colorant Substances 0.000 description 21
- 230000000694 effects Effects 0.000 description 20
- 230000003068 static effect Effects 0.000 description 19
- 239000013598 vector Substances 0.000 description 19
- 238000012795 verification Methods 0.000 description 19
- 101100138677 Arabidopsis thaliana NPF8.1 gene Proteins 0.000 description 17
- 101150059273 PTR1 gene Proteins 0.000 description 17
- 101100262635 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) UBR1 gene Proteins 0.000 description 17
- 238000003780 insertion Methods 0.000 description 17
- 230000037431 insertion Effects 0.000 description 17
- 238000004088 simulation Methods 0.000 description 17
- 238000003860 storage Methods 0.000 description 17
- 238000011068 loading method Methods 0.000 description 16
- 101100031674 Arabidopsis thaliana NPF8.3 gene Proteins 0.000 description 15
- 101100235787 Schizosaccharomyces pombe (strain 972 / ATCC 24843) pim1 gene Proteins 0.000 description 15
- 238000006243 chemical reaction Methods 0.000 description 15
- 238000013461 design Methods 0.000 description 15
- 101150114015 ptr-2 gene Proteins 0.000 description 15
- 230000002123 temporal effect Effects 0.000 description 15
- 238000004422 calculation algorithm Methods 0.000 description 14
- 150000001875 compounds Chemical class 0.000 description 14
- 238000012986 modification Methods 0.000 description 14
- 230000004048 modification Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 13
- 238000011156 evaluation Methods 0.000 description 13
- 238000004040 coloring Methods 0.000 description 12
- 238000002955 isolation Methods 0.000 description 12
- 230000000670 limiting effect Effects 0.000 description 12
- 230000008859 change Effects 0.000 description 11
- DGLFSNZWRYADFC-UHFFFAOYSA-N chembl2334586 Chemical compound C1CCC2=CN=C(N)N=C2C2=C1NC1=CC=C(C#CC(C)(O)C)C=C12 DGLFSNZWRYADFC-UHFFFAOYSA-N 0.000 description 11
- 230000006835 compression Effects 0.000 description 11
- 238000007906 compression Methods 0.000 description 11
- 230000001965 increasing effect Effects 0.000 description 11
- 238000000926 separation method Methods 0.000 description 11
- 239000000243 solution Substances 0.000 description 11
- 108091006146 Channels Proteins 0.000 description 10
- 230000008901 benefit Effects 0.000 description 10
- 101000686491 Platymeris rhadamanthus Venom redulysin 1 Proteins 0.000 description 9
- 238000004458 analytical method Methods 0.000 description 9
- 238000013459 approach Methods 0.000 description 9
- 230000000644 propagated effect Effects 0.000 description 9
- 238000010200 validation analysis Methods 0.000 description 9
- 230000001133 acceleration Effects 0.000 description 8
- 238000009826 distribution Methods 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 7
- 238000002474 experimental method Methods 0.000 description 7
- 238000007726 management method Methods 0.000 description 6
- 238000013519 translation Methods 0.000 description 6
- 230000014616 translation Effects 0.000 description 6
- 238000003491 array Methods 0.000 description 5
- 230000001186 cumulative effect Effects 0.000 description 5
- 239000000284 extract Substances 0.000 description 5
- 239000003999 initiator Substances 0.000 description 5
- 230000000873 masking effect Effects 0.000 description 5
- 238000013508 migration Methods 0.000 description 5
- 230000005012 migration Effects 0.000 description 5
- 238000012549 training Methods 0.000 description 5
- WNEODWDFDXWOLU-QHCPKHFHSA-N 3-[3-(hydroxymethyl)-4-[1-methyl-5-[[5-[(2s)-2-methyl-4-(oxetan-3-yl)piperazin-1-yl]pyridin-2-yl]amino]-6-oxopyridin-3-yl]pyridin-2-yl]-7,7-dimethyl-1,2,6,8-tetrahydrocyclopenta[3,4]pyrrolo[3,5-b]pyrazin-4-one Chemical compound C([C@@H](N(CC1)C=2C=NC(NC=3C(N(C)C=C(C=3)C=3C(=C(N4C(C5=CC=6CC(C)(C)CC=6N5CC4)=O)N=CC=3)CO)=O)=CC=2)C)N1C1COC1 WNEODWDFDXWOLU-QHCPKHFHSA-N 0.000 description 4
- 230000001276 controlling effect Effects 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 230000014509 gene expression Effects 0.000 description 4
- 238000002347 injection Methods 0.000 description 4
- 239000007924 injection Substances 0.000 description 4
- 239000003607 modifier Substances 0.000 description 4
- 230000009467 reduction Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000001052 transient effect Effects 0.000 description 4
- 101100264195 Caenorhabditis elegans app-1 gene Proteins 0.000 description 3
- 102100035431 Complement factor I Human genes 0.000 description 3
- 101150089655 Ins2 gene Proteins 0.000 description 3
- 101100072652 Xenopus laevis ins-b gene Proteins 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 239000012634 fragment Substances 0.000 description 3
- 230000001939 inductive effect Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 238000011012 sanitization Methods 0.000 description 3
- 230000006886 spatial memory Effects 0.000 description 3
- 230000000153 supplemental effect Effects 0.000 description 3
- 101100434927 Caenorhabditis elegans prmt-5 gene Proteins 0.000 description 2
- 206010028980 Neoplasm Diseases 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 201000011510 cancer Diseases 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000007123 defense Effects 0.000 description 2
- 238000007667 floating Methods 0.000 description 2
- 238000011010 flushing procedure Methods 0.000 description 2
- 238000005242 forging Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000009191 jumping Effects 0.000 description 2
- 230000036210 malignancy Effects 0.000 description 2
- 230000008450 motivation Effects 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000007789 sealing Methods 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 235000020042 tonto Nutrition 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- UKGJZDSUJSPAJL-YPUOHESYSA-N (e)-n-[(1r)-1-[3,5-difluoro-4-(methanesulfonamido)phenyl]ethyl]-3-[2-propyl-6-(trifluoromethyl)pyridin-3-yl]prop-2-enamide Chemical compound CCCC1=NC(C(F)(F)F)=CC=C1\C=C\C(=O)N[C@H](C)C1=CC(F)=C(NS(C)(=O)=O)C(F)=C1 UKGJZDSUJSPAJL-YPUOHESYSA-N 0.000 description 1
- BYHQTRFJOGIQAO-GOSISDBHSA-N 3-(4-bromophenyl)-8-[(2R)-2-hydroxypropyl]-1-[(3-methoxyphenyl)methyl]-1,3,8-triazaspiro[4.5]decan-2-one Chemical compound C[C@H](CN1CCC2(CC1)CN(C(=O)N2CC3=CC(=CC=C3)OC)C4=CC=C(C=C4)Br)O BYHQTRFJOGIQAO-GOSISDBHSA-N 0.000 description 1
- CYJRNFFLTBEQSQ-UHFFFAOYSA-N 8-(3-methyl-1-benzothiophen-5-yl)-N-(4-methylsulfonylpyridin-3-yl)quinoxalin-6-amine Chemical compound CS(=O)(=O)C1=C(C=NC=C1)NC=1C=C2N=CC=NC2=C(C=1)C=1C=CC2=C(C(=CS2)C)C=1 CYJRNFFLTBEQSQ-UHFFFAOYSA-N 0.000 description 1
- 101150053844 APP1 gene Proteins 0.000 description 1
- 238000012935 Averaging Methods 0.000 description 1
- 102100030154 CDC42 small effector protein 1 Human genes 0.000 description 1
- 241000219357 Cactaceae Species 0.000 description 1
- 101000794295 Homo sapiens CDC42 small effector protein 1 Proteins 0.000 description 1
- 101100189105 Homo sapiens PABPC4 gene Proteins 0.000 description 1
- 241000665848 Isca Species 0.000 description 1
- 241001024304 Mino Species 0.000 description 1
- 101000686495 Platymeris rhadamanthus Venom redulysin 2 Proteins 0.000 description 1
- 102100039424 Polyadenylate-binding protein 4 Human genes 0.000 description 1
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 240000003243 Thuja occidentalis Species 0.000 description 1
- ATJFFYVFTNAWJD-UHFFFAOYSA-N Tin Chemical compound [Sn] ATJFFYVFTNAWJD-UHFFFAOYSA-N 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000002547 anomalous effect Effects 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- ONTQJDKFANPPKK-UHFFFAOYSA-L chembl3185981 Chemical compound [Na+].[Na+].CC1=CC(C)=C(S([O-])(=O)=O)C=C1N=NC1=CC(S([O-])(=O)=O)=C(C=CC=C2)C2=C1O ONTQJDKFANPPKK-UHFFFAOYSA-L 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- VPWFPZBFBFHIIL-UHFFFAOYSA-L disodium 4-[(4-methyl-2-sulfophenyl)diazenyl]-3-oxidonaphthalene-2-carboxylate Chemical compound [Na+].[Na+].[O-]S(=O)(=O)C1=CC(C)=CC=C1N=NC1=C(O)C(C([O-])=O)=CC2=CC=CC=C12 VPWFPZBFBFHIIL-UHFFFAOYSA-L 0.000 description 1
- 238000005315 distribution function Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000001747 exhibiting effect Effects 0.000 description 1
- 238000011049 filling Methods 0.000 description 1
- 238000005206 flow analysis Methods 0.000 description 1
- 239000003292 glue Substances 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000000146 jump and return pulse sequence Methods 0.000 description 1
- 238000012005 ligant binding assay Methods 0.000 description 1
- 230000004807 localization Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000005291 magnetic effect Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000006386 neutralization reaction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 238000011002 quantification Methods 0.000 description 1
- WPPDXAHGCGPUPK-UHFFFAOYSA-N red 2 Chemical compound C1=CC=CC=C1C(C1=CC=CC=C11)=C(C=2C=3C4=CC=C5C6=CC=C7C8=C(C=9C=CC=CC=9)C9=CC=CC=C9C(C=9C=CC=CC=9)=C8C8=CC=C(C6=C87)C(C=35)=CC=2)C4=C1C1=CC=CC=C1 WPPDXAHGCGPUPK-UHFFFAOYSA-N 0.000 description 1
- 238000007670 refining Methods 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000004432 silane-modified polyurethane Substances 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 230000002459 sustained effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- VLCQZHSMCYCDJL-UHFFFAOYSA-N tribenuron methyl Chemical compound COC(=O)C1=CC=CC=C1S(=O)(=O)NC(=O)N(C)C1=NC(C)=NC(OC)=N1 VLCQZHSMCYCDJL-UHFFFAOYSA-N 0.000 description 1
- 238000009966 trimming Methods 0.000 description 1
- 230000003313 weakening effect Effects 0.000 description 1
- 230000036642 wellbeing Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30072—Arrangements for executing specific machine instructions to perform conditional operations, e.g. using predicates or guards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30101—Special purpose registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3867—Concurrent instruction execution, e.g. pipeline, look ahead using instruction pipelines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1052—Security improvement
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/40—Specific encoding of data in memory or cache
- G06F2212/402—Encrypted data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/45—Caching of specific data in cache memory
- G06F2212/452—Instruction code
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Databases & Information Systems (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Storage Device Security (AREA)
- Executing Machine-Instructions (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Retry When Errors Occur (AREA)
- User Interface Of Digital Computer (AREA)
- Stored Programmes (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Multi Processors (AREA)
Abstract
프로세서상에서 실행되는 코드에 대해 임의의 수의 보안 정책을 인코딩하는데 사용할 수 있는 메타데이터 처리를 위한 기술이 설명된다. 메타데이터는 시스템의 모든 워드에 추가될 수 있으며 메타데이터 처리 유닛은 데이터 흐름과 병행하여 작동하여 임의의 정책 세트를 시행하는데 사용될 수 있다. 일 양태에서, 메타데이터는 광범위한 메타데이터 처리 정책에 적용 가능하도록 무한하고 소프트웨어 프로그래머블한 것으로 특징지을 수 있다. 기술 및 정책은 예를 들어, 안전, 보안 및 동기화를 비롯한 광범위한 용도를 갖는다. 또한, RISC-V 아키텍처에 기초한 실시예에서는 메타데이터 처리와 관련하여 양태 및 기술이 설명된다.
Description
관련 출원에 대한 상호 참조
본 출원은 2015년 12월 17일자로 출원된 SOFTWARE DEFINED METADATA PROCESSING(소프트웨어 정의 메타데이터 처리)의 미국 가출원 제 62/268,639 호 및 2016년 5월 31일자로 출원된 SOFTWARE DEFINED METADATA PROCESSING의 미국 가출원 제 15/168,689 호에 대한 우선권을 주장하며, 이들 가출원은 모두 전체적으로 본 출원에서 참조로 포함된다.
배경
본 출원은 일반적으로 데이터 처리에 관한 것으로, 특히 메타데이터 처리를 위한 프로그래머블 유닛(programmable unit)에 관한 것이다.
오늘날의 컴퓨터 시스템은 안전하게 지키기가 어렵다고 두루 알려져 있다. 예를 들어, 통상의 프로세서 아키텍처는 버퍼 오버플로우(buffer overflow), 포인터 위조(pointer forging) 등과 같이, 더 높은 레벨의 추상화를 위반하는 다양한 거동을 가능하게 한다. 프로그래밍 언어와 하드웨어 간의 틈새를 좁히는 것은 소프트웨어에 맡길 수 있고, 소프트웨어에서는 빈틈없는 추상화를 시행하는 비용이 종종 너무 높다고 생각된다.
최근의 일부 노력으로 실행 동안 메타데이터를 전파하여 안전 위반 및 악의적인 공격이 발생할 때 이를 잡아 내는 정책을 시행하는 가치를 입증하였다. 이러한 정책은 소프트웨어에서 시행될 수 있지만, 정책을 배포하는 것을 단념하게 하거나 수준이 낮게 근사화하게 만드는, 예컨대 성능 및/또는 비용에 있어서, 전형적으로 높고 바람직하지 않은 오버헤드를 유발하여 보호를 더 적게 하게 한다. 고정된 정책을 위한 하드웨어 지원은 허용 가능한 수준으로 오버헤드를 줄일 수 있고 예컨대 악의적인 코드 또는 멀웨어 공격에 의해 수행될 수 있는 원하지 않는 대부분의 코드 위반을 예방할 수 있다. 예를 들어, 인텔은 최근에 경계 검사 및 격리를 위한 하드웨어를 발표하였다. 이것들은 오늘날의 많은 공격을 완화해 주지만, 시스템을 완벽하게 보호하려면 메모리 안전과 격리 이상의 것이 필요할 것이다. 공격은 임의의 남아 있는 형태의 취약성을 악용하기 위해 빠르게 진화한다.
따라서 이렇게 끊임없이 변화하는 환경에 신속하게 적응될 수 있는 유연한 보안 아키텍처가 필요하다. 이러한 아키텍처가 최소한의 오버헤드로 소프트웨어-정의 메타데이터 처리(software-defined metadata processing)를 지원하도록 하는 것이 바람직하다. 이러한 아키텍처는 일반적으로 메타데이터에 할당된 비트 수에 가시적인 엄격한 제한을 두지 않고 임의의 수와 유형의 정책을 일반적으로 지원하고 시행하도록 확장 가능한 것이 바람직하다. 메타데이터는 실행 동안 전파되어 정책을 시행하고 예를 들어 악의적인 코드 또는 멀웨어 공격과 같은 그러한 정책의 위반을 잡아낼 수 있다.
본 명세서에 설명된 기술의 일 양태에 따르면, 명령어를 처리하는 방법은: 메타데이터 처리를 위해, 연관된 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 현재 명령어를 포함하는 코드 실행 도메인(code execution domain)으로부터 격리된 메타데이터 처리 도메인(metadata processing domain)에서 수행됨 -; 메타데이터 처리 도메인에서, 메타데이터 태그 및 현재 명령어에 따라, 현재 명령어에 대해 규칙이 규칙 캐시 내에 존재하는지를 결정하는 단계 - 상기 규칙 캐시에는 허용된 동작을 정의하는 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙이 포함됨 -; 및 현재 명령어에 대해 어떠한 규칙도 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 메타데이터 처리 도메인에서 규칙 캐시 미스 처리(rule cache miss processing)를 수행하는 단계를 포함하고, 규칙 캐시 미스 처리를 수행하는 단계는: 현재 명령어의 실행이 허용되는지를 결정하는 단계; 현재 명령어가 코드 실행 도메인에서 실행되도록 허용된다고 결정하는 것에 응답하여, 현재 명령어에 대한 새로운 규칙을 발생하는 단계; 레지스터에 기입하는 단계; 및 레지스터에 기입하는 것에 응답하여, 새로운 규칙을 규칙 캐시에 삽입하는 단계를 포함한다. 현재 명령어에 대한 규칙을 선택하는데 사용되는 제 1 메타데이터는 메타데이터 처리에 의해 사용되는 복수의 제어 상태 레지스터의 제 1 부분에 저장될 수 있으며, 복수의 제어 상태 레지스터의 제 1 부분은 현재 명령어에 대한 복수의 메타데이터 태그를 메타데이터 처리 도메인에 전달하는데 사용될 수 있고, 복수의 메타데이터 태그는 메타데이터 처리 도메인에서 데이터로서 사용될 수 있다. 레지스터는 메타데이터 처리에 의해 사용되는 복수의 제어 상태 레지스터 중 제 1 제어 상태 레지스터일 수 있으며, 복수의 제어 상태 레지스터의 제 1 부분은 메타데이터 처리 도메인으로부터 규칙 캐시로 복수의 메타데이터 태그를 전달하는데 사용될 수 있다.복수의 메타데이터 태그는 현재 명령어에 대한 것일 수 있다. 새로운 규칙은 다른 메타데이터 태그를 제 1 제어 상태 레지스터에 기입하는 것에 응답하여 규칙 캐시에 삽입될 수 있고, 다른 메타데이터 태그는 현재 명령어의 결과에 배치될 수 있으며, 결과는 목적지 레지스터 또는 메모리 위치 중 어느 것일 수 있다. 복수의 제어 상태 레지스터는: 다른 모든 발생된 메타데이터 태그가 도출되는 초기 메타데이터 태그를 포함하는 부트스트랩 태그 제어 상태 레지스터(bootstrap tag control status register); 디폴트 메타데이터 태그를 특정하는 디폴트 태그 제어 상태 레지스터(default tag control status register); 공개적(public) 및 신뢰성 없음(untrusted)으로 분류된 명령어 및 데이터에 태깅하는데 사용되는 공개적 신뢰성 없는 메타데이터 태그를 특정하는 공개적 신뢰성 없는 제어 상태 레지스터(public untrusted control status register); opgroup에 관한 정보 및 상이한 opcode에 대한 케어(care) 정보를 포함하는 테이블에 기입된 데이터를 포함하는 opgroup 값 제어 상태 레지스터(opgroup value control status register); opgroup 값 제어 상태 레지스터의 데이터가 기입되는 테이블 내의 위치를 특정하는 opgroup 어드레스 제어 상태 레지스터(opgroup address control status register); 및 펌프플러시 제어 상태 레지스터(pumpflush control status register) 중 임의의 하나 이상을 포함할 수 있고, 펌프플러시 제어 상태 레지스터로의 기입은 규칙 캐시의 플러싱(flushing)을 트리거한다. 복수의 제어 상태 레지스터는 메타데이터 처리의 현재 모드를 나타내는 태그 모드 제어 상태 레지스터(tag mode control status register)를 포함할 수 있다. 태그 모드 제어 상태 레지스터는 하나 이상의 정의된 정책의 규칙이 메타데이터 처리에 의해 시행되지 않는 메타데이터 처리가 연계 해제되는(disengaged) 때를 표시할 수 있다. 태그 모드 제어 상태 레지스터는 메타데이터 처리의 현재 모드를 나타내는 허용된 상태들의 정의된 세트 중 하나로 설정될 수 있다. 허용된 상태는: 오프 상태, 메타데이터 처리가 모든 결과에 디폴트를 기입하는 상태 및 메타데이터 처리가 연계되며 명령어가 하나 이상의 특정된 권한 레벨에서 코드 도메인에서 실행될 때 동작함을 표시하는 상태 중 어느 것을 포함할 수 있다. 규칙 캐시 미스 처리는 메타데이터 처리가 연계 해제되는 허용된 상태들의 정의된 세트 중 제 1상태에서 수행될 수 있다. 허용된 상태는 명령어가 사용자 권한 레벨에서 코드 도메인에서 실행될 때만 메타데이터 처리가 연계됨을 표시하는 제 1 상태; 명령어가 사용자 또는 슈퍼바이저 권한 레벨에서 코드 도메인에서 실행될 때만 메타데이터 처리가 연계됨을 표시하는 제 2 상태; 명령어가 사용자, 슈퍼바이저 또는 하이퍼바이저 권한 레벨에서 코드 도메인에서 실행될 때만 메타데이터 처리가 연계됨을 표시하는 제 3 상태; 및 명령어가 사용자, 슈퍼바이저, 하이퍼바이저 또는 머신 권한 레벨에서 코드 도메인에서 실행될 때 메타데이터 처리가 연계됨을 표시하는 제 4 상태를 포함할 수 있다. 메타데이터 처리가 연계되거나 또는 연계 해제되는지는 코드 도메인에서 실행되는 코드의 현재 권한 레벨과 조합하여 태그 모드 제어 상태 레지스터의 현재 태그 모드에 따라 결정될 수 있고, 하나 이상의 정의된 정책의 규칙은 메타데이터 처리가 연계 해제될 때 시행되지 않을 수 있으며, 규칙은 메타데이터 처리가 연계될 때 시행될 수 있다. 테이블에는 명령어 세트의 opcode를 대응하는 opgroup 및 비트 벡터 정보에 매핑하는 정보가 포함될 수 있다. opgroup은 메타데이터 처리 도메인에 의해 유사하게 취급되는 연관된 opcode들의 그룹을 나타낼 수 있다. 비트 벡터 정보는 메타데이터 처리 도메인에 대해 특정 입력 및 출력이 opcode를 처리하는 것과 관련하여 사용되는지를 나타낼 수 있다. 테이블은 최대 허용 가능한 opcode 비트 수 미만의 opcode 비트의 제 1 부분을 사용하여 인덱싱될 수 있으며, 최대 수는 명령어 세트의 opcode의 비트 수의 상한을 나타낼 수 있다. 복수의 제어 상태 레지스터의 제 1 부분은 만일 있다면, 현재 명령어에 대한 추가 opcode 비트를 포함하는 확장된 opcode 제어 상태 레지스터를 포함할 수 있고, 현재 명령어는 가변 길이 opcode를 갖는 명령어 세트에 포함될 수 있으며, 명령어 세트의 각 opcode는 추가 opcode 비트를 임의로 포함할 수 있으며, 확장된 opcode 제어 상태 레지스터는 만일 있다면, 현재 명령어에 대한 추가 opcode 비트를 포함한다. 테이블을 사용하여 매핑된 각각의 opcode의 경우, 각각의 opcode 에 대응하는 결과 비트 벡터가 존재하고, 결과 비트 벡터는 만일 있다면, 확장된 opcode 제어 상태 레지스터의 추가 opcode 비트의 어떤 부분이 메타데이터 처리를 위해 상기 각 opcode와 함께 사용되는지를 나타낼 수 있다. 현재 명령어는 단일 메타데이터 태그와 연관된 메모리의 단일 워드에 저장된 다수의 명령어 중 하나이며, 상기 단일 메타데이터 태그는 단일 워드에 포함된 다수의 명령어와 연관될 수 있다. 복수의 제어 상태 레지스터는 단일 워드에 저장된 다수의 명령어 중 어느 것이 현재 명령어인지를 표시하는 서브명령어 제어 상태 레지스터를 포함할 수 있다. 단일 메타데이터 태그는 단일 워드 내의 다수의 명령어 각각에 대해 상이한 메타데이터 태그를 포함하는 제 1 메모리 위치를 가리키는 제 1 포인터일 수 있다. 다수의 명령어 중 제 1 명령어에 대해 제 1 메모리 위치에 저장된 적어도 제 1 메타데이터 태그는 제 1 명령어에 대한 메타데이터 태그 정보를 포함하는 제 2 메모리 위치를 가리키는 제 2 포인터를 포함할 수 있다. 제 1 명령어에 대한 메타데이터 태그 정보는 복잡한 구조체를 포함할 수 있다. 복잡한 구조체는 적어도 하나의 스칼라 데이터 필드 및 제 3 메모리 위치를 가리키는 적어도 하나의 포인터 필드를 포함할 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 비일시적 컴퓨터 판독 가능한 매체는 실행될 때 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하고, 명령어를 처리하는 방법은: 메타데이터 처리를 위해, 연관된 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 메타데이터 처리는 현재 명령어를 포함하는 코드 실행 도메인(code execution domain)으로부터 격리된 메타데이터 처리 도메인(metadata processing domain)에서 수행됨 -; 메타데이터 처리 도메인에서, 메타데이터 태그 및 현재 명령어에 따라, 현재 명령어에 대해 규칙이 규칙 캐시 내에 존재하는지를 결정하는 단계 - 규칙 캐시에는 허용된 동작을 정의하는 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙이 포함됨 -; 및 현재 명령어에 대해 어떠한 규칙도 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 메타데이터 처리 도메인에서 규칙 캐시 미스 처리(rule cache miss processing)를 수행하는 단계를 포함하고, 규칙 캐시 미스 처리를 수행하는 단계는: 현재 명령어의 실행이 허용되는지를 결정하는 단계; 현재 명령어가 코드 실행 도메인에서 실행되도록 허용된다고 결정하는 것에 응답하여, 현재 명령어에 대한 새로운 규칙을 발생하는 단계; 레지스터에 기입하는 단계; 및 레지스터에 기입하는 것에 응답하여, 새로운 규칙을 규칙 캐시에 삽입하는 단계를 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 프로세서; 및 프로세서에 의해 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고, 명령어를 처리하는 방법은: 메타데이터 처리를 위해, 연관된 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 메타데이터 처리는 현재 명령어를 포함하는 코드 실행 도메인(code execution domain)으로부터 격리된 메타데이터 처리 도메인(metadata processing domain)에서 수행됨 -; 메타데이터 처리 도메인에서, 메타데이터 태그 및 현재 명령어에 따라, 현재 명령어에 대해 규칙이 규칙 캐시 내에 존재하는지를 결정하는 단계 - 규칙 캐시에는 허용된 동작을 정의하는 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙이 포함됨 -; 및 현재 명령어에 대해 어떠한 규칙도 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 메타데이터 처리 도메인에서 규칙 캐시 미스 처리(rule cache miss processing)를 수행하는 단계를 포함하고, 규칙 캐시 미스 처리를 수행하는 단계는:
현재 명령어의 실행이 허용되는지를 결정하는 단계; 현재 명령어가 코드 실행 도메인에서 실행되도록 허용된다고 결정하는 것에 응답하여, 현재 명령어에 대한 새로운 규칙을 발생하는 단계; 레지스터에 기입하는 단계; 및 레지스터에 기입하는 것에 응답하여, 새로운 규칙을 규칙 캐시에 삽입하는 단계를 포함한다. 프로세서는 축소 명령어 집합 컴퓨팅 아키텍처(reduced instruction set computing architecture)의 파이프라인 프로세서일 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 명령어를 처리하는 방법은: 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인(metadata processing domain)에서 수행되는 메타데이터 처리를 위한 현재 명령어를 수신하는 단계; 및 현재 명령어에 대한 메타데이터와 관련하여 메타데이터 처리 도메인에 의해, 하나 이상의 정책들의 세트에 따라 현재 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 현재 명령어는 제 1 루틴의 스택 프레임의 제 1 위치에 액세스하고, 현재 명령어 및 스택 프레임의 위치는 연관된 메타데이터 태그를 가지며, 하나 이상의 정책들의 세트는 스택 보호를 제공하며 제 1 루틴의 스택 프레임의 저장 위치를 포함하는 스택 저장 위치로의 부적절한 액세스를 방지하는 스택 보호 정책을 포함한다. 스택 보호 정책은 제 1 루틴의 스택 프레임의 제 1 위치에 액세스하는 현재 명령어의 메타데이터 처리에서 사용되는 제 1 규칙을 포함할 수 있다. 제 1 규칙은 제 1 위치가 제 1 루틴의 스택 위치이며 현재 명령어가 제 1 루틴에 포함되어 있음을 표시하는 메타데이터를 제 1 위치가 가졌다면 현재 명령어의 실행을 허용할 수 있다. 현재 명령어는 제 1 루틴의 특정 호출 인스턴스에 의해 사용될 수 있으며, 스택 보호 정책은 현재 명령어의 메타데이터 처리에 사용되는 제 1 규칙을 포함할 수 있다. 제 1 규칙은 현재 명령어가 제 1 루틴에 포함되며 또한 제 1 루틴의 특정 호출 인스턴스에 의해 사용되기도 하면 현재 명령어의 실행을 허용할 수 있다. 제 1 규칙은 제 1 루틴의 특정 호출 인스턴스에 의한 현재 명령어의 실행을 허용할지를 결정하기 위해, 프로그램 카운터와 연관되어 있으며 인가 및 능력 중 임의의 것을 나타내는 메타데이터를 검사하는 것을 포함할 수 있다. 스택 보호 정책은 객체 레벨 보호 - 단일 스택 프레임 내의 상이한 객체는 상이한 컬러 메타데이터 태그를 가짐 - 및 다수의 서브 객체를 포함하는 계층적 객체에 대한 계층적 객체 보호 중 임의의 보호를 제공할 수 있고, 단일 스택 프레임의 다수의 서브 객체 각각은 상이한 메타데이터를 갖는다. 방법은 새로운 루틴 호출을 위한 새로운 스택 프레임을 생성하는 단계; 및 엄격한 객체 초기화(strict object initialization) 또는 느린 객체 컬러화(lazy-object-coloring)에 따라 새로운 스택 프레임의 메모리 위치를 태깅하거나 컬러화하는 단계를 포함할 수 있고, 엄격한 객체 초기화는 새로운 스택 프레임에 정보를 저장하기 전에 새로운 스택 프레임의 각각의 메모리 위치에 초기에 태깅하는 하나 이상의 규칙의 메타데이터 처리를 트리거하는 하나 이상의 명령어를 실행하는 초기화 처리를 수행하는 것을 포함하며, 느린 객체 컬러화는 특정 메모리 위치에 데이터를 저장하는 명령어에 응답하여 트리거되는 규칙의 메타데이터 처리와 관련하여 새로운 스택 프레임의 특정 메모리 위치에 태깅한다. 하나 이상의 정책은 특정 리턴 위치로의 리턴이 특정 호출에 후속하여 이루어진 때만 유효하다는 것을 보장하는 동적 제어 흐름 무결성 정책(dynamic control flow integrity policy)의 시행을 위한 규칙들의 세트를 포함할 수 있다. 제 1 위치는 리턴 명령어를 포함하는 호출된 루틴에 제어를 이전하는 호출 명령어를 포함할 수 있으며, 제 2 위치는 제 2 명령어를 포함할 수 있고, 상기 제 2 위치는 호출된 루틴의 리턴 명령어를 실행한 결과로서 제어가 이전된 리턴 타깃 위치를 나타낼 수 있다. 방법은 호출 명령어를 포함하는 제 1 위치를 제 1 코드 태그로 태깅하는 단계; 리턴 타깃 위치를 나타내는 제 2 위치를 제 2 코드 태그로 태깅하는 단계; 제 1 코드 태그로 태깅된 호출 명령어에 대한 세트의 제 1 규칙의 메타데이터 처리를 수행하는 단계 - 제 1 코드 태그로 태깅된 호출 명령어에 대한 제 1 규칙의 메타데이터 처리는 리턴 어드레스 레지스터가 제 2 위치에 대한 유효 리턴 어드레스를 포함하고 있음을 나타내는 유효 리턴 어드레스 태그로 리턴 어드레스 레지스터에 태깅하는 단계를 포함하고, 호출 명령어의 실행은 제 2 위치로 리턴하는 능력을 나타내기 위해 리턴 어드레스 레지스터상의 태그를 업데이트함 -; 리턴 어드레스 레지스터가 유효 리턴 어드레스로 능력 태그로 태깅되어 있으면 리턴 어드레스 레지스터에 저장된 리턴 어드레스로 제어를 이전하라는 리턴 명령어의 실행을 허용하는, 호출된 루틴의 리턴 명령어에 대한 세트의 제 2 규칙의 메타데이터 처리를 수행하는 단계 - 제 2 규칙은 리턴 어드레스 레지스터의 유효 리턴 어드레스 능력 태그를 리턴 명령어의 런타임 실행에 뒤이은 다음 명령어에 사용되는 프로그램 카운터 태그에 전파함 -; 및 리턴 명령어의 런타임 실행을 따르는 제 2 명령어에 대한 세트의 제 3 규칙의 메타데이터 처리를 수행하는 단계를 포함할 수 있고, 제 3 규칙의 메타데이터 처리는 제 2 명령어가 제 2 코드 태그와 동일한 코드 태그를 갖고 있으면, 그리고 프로그램 카운터 태그가 유효 리턴 어드레스 능력 태그이면, 제 2 명령어의 실행을 허용하고, 제 3 규칙은 제 2 명령어의 런타임 실행에 뒤이은 다음 명령어에 사용되는 프로그램 카운터 태그를 클리어한다.
본 명세서에서의 기술의 다른 양태에 따르면, 명령어를 처리하는 방법은: 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되는 메타데이터 처리를 위한 현재 명령어를 수신하는 단계; 및 현재 명령어에 대한 메타데이터와 관련하여 메타데이터 처리 도메인에 의해, 하나 이상의 정책들의 세트에 따라 현재 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 하나 이상의 정책은 완전한 시퀀스의 제 1 명령어로부터 완전한 시퀀스의 마지막 명령어까지의 특정된 순서의 완전한 명령어 시퀀스의 실행을 시행하는 한 세트의 규칙을 포함한다. 방법은 제 1 공유된 물리적 페이지를 제 1 프로세스의 제 1 가상 어드레스 공간에 매핑하는 단계; 및 제 1 공유된 물리적 페이지를 제 2 프로세스에 대한 제 2 가상 어드레스 공간에 매핑하는 단계를 포함할 수 있고, 상기 제 1 공유된 물리적 페이지는 복수의 메모리 위치를 포함하고, 복수의 메모리 위치 각각은 메타데이터 처리 도메인에서 규칙 처리와 관련하여 사용되는 복수의 글로벌 메타데이터 태그 중 하나와 연관된다. 복수의 글로벌 메타데이터 태그는 적어도 제 1 프로세스 및 제 2 프로세스를 포함하는 다수의 프로세스에 의해 공유되는 메타데이터 태그들의 세트를 나타낼 수 있으며, 메타데이터 처리 도메인에 의해 제 1 프로세스 및 제 2 프로세스 둘 모두에 대해 동일한 정책이 시행될 수 있다. 메타데이터 처리 도메인에 의한 동일한 정책의 시행은 제 1 프로세스가 제 2 프로세스에 대한 동일한 정책에 의해 그렇지 않았다면 허용되지 않은 동작을 수행할 수 있게 하는 메타데이터를 사용할 수 있으며, 프로그램 카운터는 연관된 프로그램 카운터 태그를 가질 수 있으며, 연관된 프로그램 카운터 태그의 상이한 값은 동일한 정책의 규칙에 의해 사용되어 제 1 프로세스로 하여금 제 2 프로세스에 대한 동일한 정책에 의해 그렇지 않았다면 허용되지 않은 동작을 수행할 수 있게 할 수 있다. 방법은 애플리케이션의 할당 루틴에 의해 제 1 처리를 수행하여 애플리케이션에 대한 현재 컬러를 사용하여 애플리케이션에 대한 다음 컬러를 발생하는 단계를 더 포함할 수 있고, 애플리케이션에 대한 현재 컬러는 애플리케이션에 대한 애플리케이션-특정 컬러 시퀀스의 현재 상태를 나타내고, 다음 컬러는 애플리케이션에 대한 애플리케이션-특정 컬러 시퀀스의 다음 상태를 나타내며, 현재 컬러는 제 1 원자상의 제 1 메타데이터 태그에 저장된다. 제 1 처리는 제 1 하나 이상의 명령어를 실행하는 단계를 포함할 수 있고, 제 1 하나 이상의 명령어는 메타데이터 처리 도메인에 의해 하나 이상의 규칙을 사용하는 메타데이터 처리를 트리거하고, 메타데이터 처리 도메인에 의한 하나 이상의 규칙을 사용하는 메타데이터 처리는 현재 컬러를 사용하여 다음 컬러를 발생하며, 다음 컬러를 제 1 원자의 제 1 메타데이터 태그에 저장함으로써 애플리케이션에 대한 애플리케이션-특정 컬러 시퀀스의 현재 상태를 업데이트한다. 제 1 하나 이상의 명령어는 애플리케이션의 할당 루틴에 포함될 수 있으며, 제 1 원자는 레지스터 및 메모리 위치 중 어느 것일 수 있다. 애플리케이션-특정 컬러 시퀀스는 애플리케이션에 의해 사용하는데 이용 가능한 상이한 컬러의 무한한 시퀀스일 수 있다. , 다음 컬러는 애플리케이션에 의해 사용되는 하나 이상의 메모리 위치 각각에 대해 태그 값으로서 저장될 수 있고, 하나 이상의 메모리 위치는 할당 루틴에 의해 할당될 수 있다. 규칙들의 세트는 제 1 규칙 및 제 2 규칙을 포함할 수 있으며, 완전한 명령어 시퀀스는 제 1 명령어 및 제 2 명령어를 포함할 수 있으며, 제 2 명령어는 제 1 명령어 바로 뒤이어 실행될 수 있다. 방법은 제 1 명령어에 대한 제 1 규칙의 메타데이터 처리를 수행하는 단계 - 제 1 규칙의 메타데이터 처리는 제 1 명령어의 런타임 실행에 뒤이은 다음 명령어에 사용되는 프로그램 카운터의 프로그램 카운터 태그를 특수 태그 값으로 설정하는 단계를 포함함 -; 및 제 2 명령어에 대한 제 2 규칙의 메타데이터 처리를 수행하는 단계를 포함할 수 있고, 제 2 규칙의 메타데이터 처리는 제 2 명령어에 대한 프로그램 카운터의 프로그램 카운터 태그가 특수 태그와 동일한 때만 제 2 명령어의 실행이 허용됨을 보장하는 단계를 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 비일시적 컴퓨터 판독 가능한 매체는 실행될 때 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하고, 명령어를 처리하는 방법은: 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되는 메타데이터 처리를 위한 현재 명령어를 수신하는 단계; 및 현재 명령어에 대한 메타데이터와 관련하여 메타데이터 처리 도메인에 의해, 하나 이상의 정책들의 세트에 따라 현재 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 현재 명령어는 제 1 루틴의 스택 프레임의 제 1 위치에 액세스하고, 현재 명령어 및 스택 프레임의 위치는 연관된 메타데이터 태그를 가지며, 하나 이상의 정책들의 세트는 스택 보호를 제공하며 제 1 루틴의 스택 프레임의 저장 위치를 포함하는 스택 저장 위치로의 부적절한 액세스를 방지하는 스택 보호 정책을 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 프로세서; 및 프로세서에 의해 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고, 명령어를 처리하는 방법은: 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되는 메타데이터 처리를 위한 현재 명령어를 수신하는 단계; 및 현재 명령어에 대한 메타데이터와 관련하여 메타데이터 처리 도메인에 의해, 하나 이상의 정책들의 세트에 따라 현재 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 현재 명령어는 제 1 루틴의 스택 프레임의 제 1 위치에 액세스하고, 현재 명령어 및 스택 프레임의 위치는 연관된 메타데이터 태그를 가지며, 하나 이상의 정책들의 세트는 스택 보호를 제공하며 제 1 루틴의 스택 프레임의 저장 위치를 포함하는 스택 저장 위치로의 부적절한 액세스를 방지하는 스택 보호 정책을 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독 가능한 매체로서, 명령어를 처리하는 방법은: 명령어를 처리하는 방법은: 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되는 메타데이터 처리를 위한 현재 명령어를 수신하는 단계; 및 현재 명령어에 대한 메타데이터와 관련하여 메타데이터 처리 도메인에 의해, 하나 이상의 정책들의 세트에 따라 현재 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 하나 이상의 정책은 완전한 시퀀스의 제 1 명령어로부터 완전한 시퀀스의 마지막 명령어까지의 특정된 순서의 완전한 명령어 시퀀스의 실행을 시행하는 규칙들의 세트를 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 프로세서; 및 프로세서에 의해 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고, 명령어를 처리하는 방법은: 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되는 메타데이터 처리를 위한 현재 명령어를 수신하는 단계; 및 현재 명령어에 대한 메타데이터와 관련하여 메타데이터 처리 도메인에 의해, 한 세트의 하나 이상의 정책에 따라 현재 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 하나 이상의 정책은 완전한 시퀀스의 제 1 명령어로부터 완전한 시퀀스의 마지막 명령어까지의 특정된 순서의 완전한 명령어 시퀀스의 실행을 시행하는 규칙들의 세트를 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 메타데이터 태그를 발생하여 사용하는 방법은: 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 사용되는 복수의 특정된 레지스터 중 제 1 특정된 레지스터에 부트스트랩 태그(bootstrap tag)를 저장하는 단계; 및 부트스트랩 태그로부터 하나 이상의 추가 메타데이터 태그를 도출하는 제 1 처리를 수행하는 단계를 포함하고, 제 1 처리는 메타데이터 처리 도메인 내의 하나 이상의 규칙의 메타데이터 처리를 트리거하는 코드 실행 도메인 내의 하나 이상의 명령어를 실행하는 것을 포함한다. 부트스트랩 태그는 메타데이터 처리 도메인에 의해 사용되는 모든 다른 메타데이터 태그가 도출되는 초기 시드 태그(seed tag)로서 사용될 수 있다. 부트스트랩 태그는 하드와이어(hardwired)되거나 판독 전용 메모리의 일부분에 저장될 수 있다. 저장 단계 및 제 1 처리는 메타데이터 처리 도메인 및 코드 실행 도메인을 포함하는 시스템을 부팅할 때 부트스트랩 프로그램의 제 1 코드 부분을 실행함으로써 수행되는 처리에 포함될 수 있다. 방법은 제 1 특정된 레지스터에 저장된 부트스트랩 태그로부터 디폴트 태그를 도출하는 단계; 디폴트 태그를 복수의 특정된 레지스터 중 제 2 특정된 레지스터에 저장하는 단계; 및 제 2 특정된 레지스터로부터 디폴트 태그를 코드 실행 도메인에 의해 사용되는 복수의 메모리 위치 각각에 대해 메타데이터 태그로서 기입하는 메타데이터 처리 도메인 내의 규칙의 메타데이터 처리를 트리거하는 명령어 시퀀스를 실행하는 단계를 포함할 수 있다. 제 1 처리는 부트스트랩 태그로부터 도출된 메타데이터 태그들의 초기 세트를 발생하는 것을 포함할 수 있고, 초기 세트의 메타데이터 태그 각각은 현재 명령어에 대해 어떠한 규칙도 규칙 캐시 내에 존재하지 않는 메타데이터 처리 도메인 내의 규칙 캐시 미스 처리를 트리거하는 코드 실행 도메인 내의 현재 명령어를 실행함으로써 발생될 수 있고, 규칙 캐시는 허용된 동작을 정의하는 메타데이터 처리 도메인에 의해 사용되는 메타데이터에 관한 규칙을 포함한다. 규칙 캐시 미스 처리는: 메타데이터 처리 도메인에서 실행되는 규칙 캐시 미스 핸들러(rule cache miss handler)에 의해, 현재 명령어에 대한 새로운 규칙을 계산하는 단계를 포함하고, 새로운 규칙은 메타데이터 태그의 초기 세트의 결과 메타데이터 태그를 포함한다. 초기 세트의 각각의 메타데이터 태그는 다른 메타데이터 태그를 도출하기 위해 추가로 사용될 수 있는 태그 발생기(tag generator)일 수 있다. 하나 이상의 특정된 명령어들의 제 1 세트의 실행은 하나 이상의 다른 메타데이터 태그의 시퀀스를 발생하는데 사용되는 태그 발생기로 표시된 각 메타데이터 태그를 발생하는 메타데이터 처리 도메인에서 규칙 및 규칙 캐시 미스 처리를 트리거할 수 있으며, 하나 이상의 특정된 명령어들의 제 2 세트의 실행은 추가의 메타데이터 태그를 더 발생하기 위해 사용될 수 없는 비-발생 태그(non-generating tag)로 표시된 각각의 메타데이터 태그를 발생하는 메타데이터 처리 도메인 내의 규칙 및 규칙 캐시 미스 처리를 트리거할 수 있다. 부트스트랩 프로그램은 확장된 권한, 능력 또는 인가를 태깅된 하나 이상의 명령어에 제공하기 위해, 지정된 코드 부분의 하나 이상의 명령어 상에 하나 이상의 특수 메타데이터 코드 태그를 기입하는 메타데이터 처리 도메인에서 처리된 규칙을 트리거하는 명령어를 더 포함할 수 있다. 지정된 코드 부분은 커널 코드(kernel code) 및 로더 코드(loader code) 중 하나 이상을 포함할 수 있다. 하나 이상의 특수 메타데이터 코드 태그는 메타데이터 태그들의 초기 세트 중의 제 1 메타데이터 태그로부터 도출되고, 제 1 메타데이터 태그는 특수 명령어 태그 발생기이다. 메타데이터 태그들의 초기 세트는: 명령어에 태깅하는데 사용되는 하나 이상의 코드 태그의 시퀀스를 발생하는데 사용되는 태그 발생기인 초기 명령어 메타데이터 태그; 하나 이상의 다른 malloc 태그 발생기(malloc tag generator)의 시퀀스를 발생하는데 사용되는 태그 발생기인 초기 malloc 메타데이터 태그 - 하나 이상의 다른 malloc 태그 발생기 각각은 할당된 메모리 셀 및 상이한 애플리케이션에 의해 사용되는 할당된 메모리 셀을 가리키는 포인터 중 어느 것을 컬러화하는 것과 관련하여 상이한 애플리케이션에 대한 하나 이상의 다른 메타데이터 태그의 시퀀스를 발생하는데 사용됨 -; 하나 이상의 다른 제어 흐름 무결성 태그 발생기(control flow integrity tag generator)의 시퀀스를 발생하는데 사용되는 태그 발생기인 초기 제어 흐름 무결성 태그 - 하나 이상의 다른 제어 흐름 무결성 태그 발생기 각각은 상이한 애플리케이션의 제어 이전 타깃에 태깅하는 것과 관련하여 상이한 애플리케이션에 대한 하나 이상의 다른 다른 메타데이터 태그의 시퀀스를 발생하는데 사용됨 -; 및 하나 이상의 다른 테인트 태그 발생기(taint tag generator)의 시퀀스를 발생하는데 사용되는 태그 발생기인 초기 테인트 태그 중 임의의 하나 이상을 포함할 수 있고, 하나 이상의 다른 테인트 태그 발생기 각각은 상이한 애플리케이션에 의해 사용되는 데이터 아이템을 데이터 아이템을 생성했거나 수정한 코드에 기초하여 메타데이터 테인트 태그로 태깅하는 것과 관련하여 상이한 애플리케이션에 대한 하나 이상의 다른 메타데이터 테인트 태그의 시퀀스를 발생하는데 사용된다. 메타데이터 처리 도메인에서 규칙의 다른 처리를 트리거하는 명령어를 실행함으로써 메타데이터 태그의 시퀀스가 발생될 수 있다. 다른 처리는 시퀀스 내의 현재 메타데이터 태그를 사용하여 시퀀스 내의 다음 메타데이터 태그를 발생하는 단계 - 현재 메타데이터 태그는 시퀀스의 현재 상태를 나타내며 원자와 연관된 메타데이터 태그로서 저장되고, 원자는 레지스터 또는 메모리 위치 중 어느 것임 -; 및 다음 메타데이터 태그를 원자와 연관된 메타데이터 태그로서 저장함으로써 시퀀스의 현재 상태를 업데이트하는 단계를 포함할 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 애플리케이션에 대한 제어 흐름 정보를 획득하는 방법은: 프로세서에 의한 실행을 위해 애플리케이션을 로드하는 로더를 실행하는 단계 - 상기 로더를 실행하는 단계는 메타데이터 처리 도메인에서 제 1 세트의 하나 이상의 규칙의 메타데이터 처리를 트리거하는 하나 이상의 명령어를 포함하는 제 1 코드 부분을 실행하는 단계를 포함하고, 제 1 세트의 하나 이상의 규칙의 메타데이터 처리는 메타데이터 처리 도메인에 액세스 가능하고 코드 실행 도메인에 액세스 불가능한 애플리케이션 메타데이터로서 애플리케이션에 대한 제어 흐름 정보를 수집하고 저장하는 단계를 포함함 -; 및 코드 실행 도메인에서 애플리케이션의 명령어를 실행하는 단계를 포함하고, 애플리케이션의 상기 명령어를 실행하는 상기 단계는 제어 흐름 정보의 적어도 일부분을 사용하여, 애플리케이션의 제어를 제 1 소스 위치로부터 제 1 타깃 위치로 이전할지를 결정하는 제어 흐름 정책의 제 2 세트의 규칙의 메타데이터 처리를 트리거한다. 제 1 타깃 위치는 제어를 제 1 타깃 위치로 이전하도록 허용된 한 세트의 하나 이상의 허용 가능한 소스 위치를 가질 수 있다. 애플리케이션에 대한 제어 흐름 정보를 수집하고 애플리케이션 메타데이터로서 저장하는 단계는 메타데이터 처리 도메인이 다른 처리를 수행하는 것을 더 포함할 수 있다. 다른 처리는 제 1 타깃 위치를 하나 이상의 허용 가능한 소스 위치들의 세트를 식별하는 제 1 메타데이터로 태깅하는 단계를 포함할 수 있고, 제 1 메타데이터는 애플리케이션 메타데이터의 제어 흐름 정보의 일부로서 저장된다. 애플리케이션의 제 1 명령어는 제 1 소스 위치로부터 제 1 타깃 위치로 제어를 이전할 수 있으며, 제 1 명령어는 제 1 메타데이터를 사용하여 제 1 소스 위치가 제 1 타깃 위치로 제어를 이전하도록 허용된 하나 이상의 허용 가능한 소스 위치들의 세트에 포함되는지를 결정함으로써 제 1 명령어의 실행을 허용할지를 결정하는 제어 흐름 정책의 하나 이상의 규칙의 메타데이터 처리를 트리거할 수 있다. 다른 처리는 또한 세트의 각각의 허용 가능한 소스 위치를 고유 소스 메타데이터 태그로 태깅하는 단계를 포함할 수 있다. 각각의 허용 가능한 소스 위치의 각각의 고유 소스 메타데이터 태그는 애플리케이션에 대한 소스 메타데이터 태그의 제 1 시퀀스에 포함될 수 있고, 제 1 시퀀스는 제어 흐름 발생기 태그로부터 발생된 소스 메타데이터 태그의 고유 시퀀스일 수 있다. 제어 흐름 발생기 태그는 초기 부트스트랩 태그로부터 도출된 초기 제어 흐름 발생기 태그로부터 발생될 수 있다. 초기 제어 흐름 발생기 태그는 복수의 추가 제어 흐름 발생기 태그를 발생하는데 사용될 수 있고, 추가 제어 흐름 발생기 태그 각각은 상이한 애플리케이션에 대한 고유 소스 메타데이터 태그의 시퀀스를 발생하는데 사용될 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 비일시적 컴퓨터 판독가능한 매체는 실행될 때, 메타데이터 태그를 발생하여 사용하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독 가능한 매체로서, 메타데이터 태그를 발생하여 사용하는 방법은: 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 사용되는 복수의 특정된 레지스터 중 제 1 특정된 레지스터에 부트스트랩 태그(bootstrap tag)를 저장하는 단계; 및 부트스트랩 태그로부터 하나 이상의 추가 메타데이터 태그를 도출하는 제 1 처리를 수행하는 단계를 포함하고, 제 1 처리는 메타데이터 처리 도메인에서 하나 이상의 규칙의 메타데이터 처리를 트리거하는 하나 이상의 명령어를 코드 실행 도메인에서 실행하는 단계를 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 프로세서; 및 실행될 때, 메타데이터 태그를 발생하여 사용하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고, 메타데이터 태그를 발생하여 사용하는 방법은: 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 사용되는 복수의 특정된 레지스터 중 제 1 특정된 레지스터에 부트스트랩 태그(a bootstrap tag)를 저장하는 단계; 및 부트스트랩 태그로부터 하나 이상의 추가 메타데이터 태그를 도출하는 제 1 처리를 수행하는 단계를 포함하고, 제 1 처리는 메타데이터 처리 도메인에서 하나 이상의 규칙의 메타데이터 처리를 트리거하는 하나 이상의 명령어를 코드 실행 도메인에서 실행하는 단계를 포함한다.
본 명세서에서의 기술의 다른 양태에 따르면, 비일시적 컴퓨터 판독가능한 매체는 실행될 때, 애플리케이션에 대한 제어 흐름 정보를 획득하는 방법을 수행하는 저장된 코드를 포함하고, 애플리케이션에 대한 제어 흐름 정보를 획득하는 방법은: 프로세서에 의한 실행을 위해 애플리케이션을 로드하는 로더를 실행하는 단계 - 로더를 실행하는 단계는 메타데이터 처리 도메인에서 제 1 세트의 하나 이상의 규칙의 메타데이터 처리를 트리거하는 하나 이상의 명령어를 포함하는 제 1 코드 부분을 실행하는 단계를 포함하고, 제 1 세트의 하나 이상의 규칙의 메타데이터 처리는 메타데이터 처리 도메인에 액세스 가능하고 코드 실행 도메인에 액세스 불가능한 애플리케이션 메타데이터로서 애플리케이션에 대한 제어 흐름 정보를 수집하고 저장하는 단계를 포함함 -; 및 코드 실행 도메인에서 애플리케이션의 명령어를 실행하는 단계를 포함하고, 애플리케이션의 명령어를 실행하는 단계는 제어 흐름 정보의 적어도 일부분을 사용하여, 애플리케이션의 제어를 제 1 소스 위치로부터 제 1 타깃 위치로 이전할지를 결정하는 제어 흐름 정책의 제 2 세트의 규칙의 메타데이터 처리를 트리거한다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 프로세서; 및 실행될 때, 애플리케이션에 대한 제어 흐름 정보를 획득하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고, 애플리케이션에 대한 제어 흐름 정보를 획득하는 방법은: 프로세서에 의한 실행을 위해 애플리케이션을 로드하는 로더를 실행하는 단계 - 로더를 실행하는 단계는 메타데이터 처리 도메인에서 제 1 세트의 하나 이상의 규칙의 메타데이터 처리를 트리거하는 하나 이상의 명령어를 포함하는 제 1 코드 부분을 실행하는 단계를 포함하고, 제 1 세트의 하나 이상의 규칙의 메타데이터 처리는 메타데이터 처리 도메인에 액세스 가능하고 코드 실행 도메인에 액세스 불가능한 애플리케이션 메타데이터로서 애플리케이션에 대한 제어 흐름 정보를 수집하고 저장하는 단계를 포함함 -; 및 코드 실행 도메인에서 애플리케이션의 명령어를 실행하는 단계를 포함하고, 애플리케이션의 명령어를 실행하는 단계는 제어 흐름 정보의 적어도 일부분을 사용하여, 애플리케이션의 제어를 제 1 소스 위치로부터 제 1 타깃 위치로 이전할지를 결정하는 제어 흐름 정책의 제 2 세트의 규칙의 메타데이터 처리를 트리거한다.
본 명세서에서의 기술의 다른 양태에 따르면, 태깅된 데이터 소스와 태깅되지 않은 데이터 소스 사이에서 프로세서-중재된 데이터 이전을 수행하는 방법은: 프로세서상에서, 태깅되지 않은 데이터 소스로부터 제 1 데이터를 로드하는 제 1 명령어를 실행하는 단계 - 태깅되지 않은 데이터 소스는 연관된 메타데이터 태그를 갖지 않는 메모리 위치를 포함함 -; 제 1 하드웨어에 의해, 제 1 데이터가 신뢰성이 없고 공개적 데이터 소스(public data source)로부터 온 것임을 나타내는 제 1 메타데이터 태그로 제 1 데이터를 태깅하는 단계 - 제 1 메타데이터 태그를 갖는 제 1 데이터는 제 1 버퍼에 저장됨 -; 및 프로세서상에서, 제 1 하나 이상의 규칙을 사용하는 메타데이터 처리를 트리거하는 제 1 코드를 실행하는 단계를 포함하고, 제 1 하나 이상의 규칙을 사용하는 메타데이터 처리는 제 1 데이터가 신뢰성 있음을 나타내는 제 2 메타데이터 태그를 갖도록 제 1 데이터를 재태깅하는 재태깅을 수행한다. 제 2 메타데이터 태그는 제 1 데이터가 공개적 소스로부터 온 것임을 추가로 나타낼 수 있다. 제 2 메타데이터 태그를 갖는 제 1 데이터는 연관된 메타데이터 태그를 각각 갖는 메모리 위치를 포함하는 태깅된 데이터 소스인 메모리에 저장될 수 있다. 메모리는 하나 이상의 신뢰성 있는 데이터 소수로부터의 데이터를 포함하는 신뢰성 있는 메모리일 수 있다. 메타데이터 처리는 제 1 코드를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행될 수 있다. 제 1 하나 이상의 규칙은 허용된 동작을 정의하는 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙일 수 있다. 제 1 코드는 하나 이상의 명령어를 포함할 수 있으며 하나 이상의 명령어 각각은 상기 각각의 명령어가 제 1 데이터를 재태깅하여 제 2 메타데이터 태그를 갖게 하는 하나 이상의 규칙을 호출하는 인가를 갖는 것을 나타내는 특수 명령어 태그를 가질 수 있다. 제 1 메타데이터 태그를 갖는 제 1 데이터는 암호화될 수 있으며, 방법은 프로세서상에서 하나 이상의 명령어를 실행함으로써, 제 1 메타데이터 태그를 갖는 제 1 데이터를 암호 해독하고, 제 1 메타데이터 태그를 갖는 제 1 데이터의 암호 해독된 형태를 발생하는 단계; 및 프로세서상에서 하나 이상의 추가 명령어를 실행함으로써 입증 처리(validation processing)를 수행하는 단계를 포함할 수 있고, 상기 입증 처리는 디지털 서명을 사용하여 제 1 데이터의 암호 해독된 형태가 유효하다는 것을 보장하고, 상기 재태깅은 제 1 데이터의 성공적인 입증 처리 이후에 수행된다. 제 2 메타데이터 태그를 갖는 제 1 데이터는 태깅된 메모리의 제 1 메모리 위치에 암호 해독된 형태로 저장될 수 있으며, 방법은 제 1 데이터를 암호화하여 제 1 데이터를 암호화된 형태로 생성하고 제 1 데이터에 따라 디지털 서명을 발생하는 단계 - 상기 암호화 및 발생 단계는 프로세서상에서 추가 코드를 실행함으로써 수행됨 -; 및 프로세서상에서, 제 1 데이터의 암호화된 형태를 태깅된 메모리의 제 1 메모리 위치로부터 태깅되지 않은 메모리의 목적지 위치에 저장하는 제 2 명령어를 실행하는 단계를 포함할 수 있고, 제 1 데이터의 암호화된 형태는 연관된 메타데이터 태그 없이 목적지 위치에 저장되며, 제 2 메타데이터 태그는 제 1 데이터의 암호화된 형태를 목적지 위치에 저장하기 전에 제 2 하드웨어에 의해 제거된다. 제 1 시점에서, 제 1 데이터는 태깅되지 않은 메모리 부분의 제 1 위치에 저장될 수 있으며, 제 2 시점에서, 제 1 데이터가 신뢰성 없고 공개적 데이터 소스로부터 온 것임을 나타내는 제 1 메타데이터 태그를 갖는 제 1 데이터는 태깅된 메모리 부분의 제 2 위치에 저장될 수 있다. 태깅되지 않은 메모리 부분 및 태깅된 메모리 부분은 동일한 메모리 제어기에 의해 서비스되는 동일한 메모리에 포함되며, 제 2 메타데이터 처리 규칙은 프로세서로 하여금 데이터가 공개적인 것을 나타내는 연관된 메타데이터 태그를 갖는 데이터를 태깅되지 않은 메모리 부분에 기입하는 동작만을 수행하게 할 수 있으며, 태깅되지 않은 데이터에 대해 동작하는 외부의 태깅되지 않은 소스로부터의 직접 메모리 동작은 동일한 메모리의 태깅되지 않은 메모리 부분에 액세스하는 것만 허용될 수 있다. 제 2 메타데이터 처리 규칙의 적어도 일부는 프로세서로 하여금 데이터가 공개적이고 부가적으로 신뢰성 없음을 나타내는 연관된 메타데이터 태그를 갖는 데이터를 태깅되지 않은 메모리 부분에 기입하는 동작만을 수행하게 할 수 있다. 태깅되지 않은 데이터 소스는 태깅되지 않은 데이터 소스만을 포함하는 제 1 인터커넥트 패브릭에 연결될 수 있고, 제 2 메타데이터 태그를 갖는 제 1 데이터는 태깅된 데이터 소스만을 포함하는 제 2 데이터 소스 인터커넥트 패브릭에 연결된 메모리의 위치에 저장될 수 있다. 제 2 프로세서는 제 1 인터커넥트 패브릭에 연결될 수 있으며 태깅되지 않은 데이터 소스로부터의 태깅되지 않은 데이터를 사용하여 다른 명령어를 실행할 수 있다. 다른 명령어는 메타데이터 처리를 수행하지 않고 그리고 메타데이터에 관한 규칙을 사용하지 않고 실행되어 허용 가능한 동작을 시행할 수 있고, 제 2 프로세서에 의한 다른 명령어의 실행은 제 1 인터커넥트 패브릭의 태깅되지 않은 데이터 소스로부터의 데이터를 판독하는 것 및 제 1 인터커넥트 구조체의 태깅되지 않은 데이터 소스에 데이터를 기입하는 것 중 임의의 것을 포함하는 하나 이상의 동작을 수행하는 것을 포함할 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 프로세서; 및 하나 이상의 태깅된 메모리 - 하나 이상의 태깅된 메모리의 각각의 메모리 위치는 연관된 메타데이터 태그를 가짐 -; 제 1 태깅되지 않은 메모리를 포함하는 하나 이상의 태깅되지 않은 메모리 - 하나 이상의 태깅되지 않은 메모리의 메모리 위치는 연관된 메타데이터 태그를 갖지 않음 -; 명령어와 관련하여 허용된 동작을 정의하는, 메타데이터 처리를 수행하는데 사용되는 메타데이터에 관한 규칙을 포함하는 규칙 캐시 - 프로세서에 의해 현재 명령어를 실행하기 전에, 규칙 캐시의 하나 이상의 규칙을 사용하는 메타데이터 처리가 수행되어 현재 명령어의 실행이 허용되는지를 결정함 -; 프로세서에 의해 실행될 때, 제 1 데이터를 제 1 태깅되지 않은 메모리로부터 프로세서에 의해 사용되는 데이터 캐시로 로드하는 제 1 명령어 - 데이터 캐시에 저장된 제 1 데이터는 연관된 제 1 메타데이터 태그를 가짐 -; 프로세서에 의해 실행될 때, 제 2 데이터를 데이터 캐시로부터 제 1 태깅되지 않은 메모리로 저장하는 제 2 명령어 - 데이터 캐시에 저장된 제 2 데이터는 연관된 제 2 메타데이터 태그를 가짐 -; 태깅되지 않은 데이터를 프로세서에 의해 시스템에서 사용되는 태깅된 데이터로 변환하는 제 1 하드웨어 컴포넌트 - 제 1 명령어의 실행에 응답하여, 제 1 하드웨어 컴포넌트는 제 1 태깅되지 않은 메모리로부터, 임의의 연관된 메타데이터 태그 없는 제 1 데이터를 수신하고, 연관된 제 1 메타데이터 태그를 갖는 제 1 데이터를 출력함 -; 및 태깅된 데이터를 태깅되지 않은 데이터로 변환하는 제 2 하드웨어 컴포넌트를 포함하고, 제 2 명령어의 실행에 응답하여, 제 2 하드웨어 컴포넌트는 연관된 제 2 메타데이터 태그를 갖는 제 2 데이터를 수신하고 임의의 연관된 메타데이터 태그 없는 제 2 데이터를 출력한다. 임의의 연관된 메타데이터 태그 없는 제1 데이터는 암호화될 수 있으며, 제 1 하드웨어 컴포넌트는 제 1 데이터를 암호 해독된 형태로 변환할 수 있고, 디지털 서명을 사용하여 제 1 데이터의 입증 처리를 수행하며, 성공적인 입증 처리 시, 제 1 데이터가 신뢰성 있음을 나타내는 연관된 제 1 메타데이터 태그를 갖도록 제 1 데이터에 태깅할 수 있다. 제 2 연관된 메타데이터 태그를 갖는 제 2 데이터는 암호 해독된 형태일 수 있으며, 제 2 하드웨어 컴포넌트는 제 2 데이터를 암호화된 형태로 변환하며 제 2 데이터에 따라 디지털 서명을 발생할 수 있다. 제 1 하드웨어 컴포넌트는 제 1 데이터가 신뢰성 있음을 나타내며 또한 제 1 데이터가 공개적 소스로부터 온 것임을 식별하는 연관된 제 1 메타데이터 태그를 갖도록 제 1 데이터에 태깅할 수 있다. 하나 이상의 암호 키 세트는 하드웨어에서 인코딩되는 것 및 메모리에 저장되는 것 중 하나일 수 있다. 하나 이상의 암호 키 세트는 암호 해독 및 입증 처리를 수행하는 것과 관련하여 제 1 하드웨어 컴포넌트에 의해 사용될 수 있으며 암호화를 수행하고 디지털 서명을 발생하는 것과 관련하여 제 2 하드웨어 컴포넌트에 의해 사용될 수 있다. 제 1 데이터는 제 1 하드웨어 컴포넌트에 의해 사용된 암호 키 세트 중 특정 하나를 식별하여 제 1 데이터를 암호 해독할 수 있으며, 제 2 데이터의 연관된 메타데이터 태그는 제 2 하드웨어 컴포넌트에 의해 사용되는 암호 키 세트 중 특정 하나를 식별하여 제 2 데이터를 암호화하고 서명할 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 현재 명령어를 처리하는 방법은: 메타데이터 처리를 위해, 현재 명령어를 수신하는 단계; 및 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 현재 명령어에 대한 메타데이터 처리를 수행하는 단계를 포함하고, 상기 현재 명령어는 메타데이터 처리에서 사용되는 제 1 메타데이터 태그를 갖는 제 1 메모리 위치를 참조하고, 현재 명령어에 대한 상기 메타데이터 처리는: 메모리로부터 제 1 메타데이터 태그를 검색하는 처리를 수행하는 단계; 메모리로부터 제 1 메모리 위치에 대한 제 1 메타데이터 태그를 수신하기에 앞서, 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값을 결정하는 단계; 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값을 사용하여, 현재 명령어의 결과 오퍼랜드에 대한 제 1 결과 메타데이터 태그를 결정하는 단계; 및 메모리로부터, 제 1 메타데이터 태그를 수신하는 것; 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭하는지를 결정하는 ㄷ단계; 및 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭한다고 결정하는 것에 응답하여, 제 1 결과 메타데이터 태그를 결과 오퍼랜드에 대한 최종 결과 메타데이터 태그로서 사용하는 단계를 포함한다. 현재 명령어에 대한 메타데이터 처리는 현재 명령어 및 현재 명령어에 대한 입력 메타데이터 태그들의 세트에 따라, 현재 명령어에 대한 제 1 규칙을 결정하는 단계 - 제 1 규칙은 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값을 포함하며 제 1 결과 메타데이터 태그를 포함하고, 제 1 규칙은 메타데이터 처리 도메인에서 메타데이터 처리를 위해 사용되는 규칙 캐시에 포함됨 -; 및 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭하지 않는다고 결정하는 것에 응답하여, 현재 명령어에 대한 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 단계를 포함할 수 있다. 현재 명령어에 대한 메타데이터 처리 도메인에서 규칙 캐시 미스 처리는 코드 실행 도메인에서 현재 명령어의 실행이 허용되는지를 결정하는 단계; 코드 실행 도메인에서 현재 명령어의 실행이 허용된다고 결정하는 것에 응답하여, 현재 명령어에 대한 새로운 규칙을 발생하는 단계 - 새로운 규칙은 현재 명령어, 입력 메타데이터 태그의 세트 및 제 1 메타데이터 태그에 따라 발생됨 -; 및 메타데이터 처리 도메인에서 메타데이터 처리를 위해 사용되는 규칙 캐시에 새로운 규칙을 삽입하는 단계를 포함할 수 있다. 다른 입력 메타데이터 태그들의 세트는 현재 명령어에 대한 복수의 다른 메타데이터 태그를 포함할 수 있고, 상기 다른 메타데이터 입력 태그들의 세트는: 프로그램 카운터, 현재 명령어 및 현재 명령어의 입력 오퍼랜드 중 어느 것에 대한 메타데이터 태그를 포함할 수 있다. 결과 오퍼랜드는 현재 명령어를 실행한 결과를 저장하는 목적지 메모리 위치 또는 목적지 레지스터일 수 있다. 명령어는 제 1 스테이지 및 제 2 스테이지를 포함하는 복수의 스테이지에 따라 처리될 수 있고, 제 1 스테이지는 제 2 스테이지에 앞서 존재할 수 있다. 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값은 제 1 스테이지에서 결정될 수 있으며, 제 2 스테이지는 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭하는지의 상기 결정을 수행하는 것을 포함할 수 있으며, 제 2 스테이지는 또한 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭하지 않는다고 결정하는 것에 응답하여 현재 명령어에 대해 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 것을 포함할 수 있다. 규칙 캐시는 예측 선택기 모드(prediction selector mode)에 따라 예측 모드 또는 정상 처리 모드에서 동작하도록 구성 가능할 수 있다. 규칙 캐시는 현재 명령어에 대해 메타데이터 처리를 수행할 때 예측 모드에서 동작하도록 구성될 수 있다. 규칙 캐시가 상기 예측 모드에서 동작하도록 구성될 때, 규칙 캐시는 제 1 규칙에 따라 제 1 출력을 발생할 수 있다. 제 1 출력은 다음 명령어의 프로그램 카운터에 대한 메타데이터 태그, 현재 명령어의 결과 오퍼랜드에 대한 제 1 결과 메타데이터 태그 및 제 1 스테이지의 출력으로서 메타데이터 태그의 예측된 값을 포함할 수 있다. 규칙 캐시가 상기 정상 처리 모드에서 동작하도록 구성될 때, 규칙 캐시는 제 1 규칙과 상이한 제 2 규칙에 따라 제 2 출력을 발생할 수 있고, 제 2 출력은 제 1 메타데이터 태그의 예측된 값을 포함하지 않을 수 있으며, 제 2 출력은 현재 명령어의 결과 오퍼랜드에 대한 그리고 다음 명령어의 프로그램 카운터에 대한 메타데이터 태그를 포함할 수 있다. 규칙 캐시는 예측 모드에서 동작할 때 제 1 정책의 규칙의 제 1 버전을 사용할 수 있으며, 그렇지 않으면 정상 처리 모드에서 동작할 때 제 1 정책의 규칙의 제 2 버전을 사용하며, 제 1 규칙은 규칙의 제 1 버전에 포함될 수 있으며 제 2 규칙은 규칙의 제 2 버전에 포함될 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 시스템은: 복수의 파이프라인 스테이지를 포함하는 파이프라인 프로세서 - 상기 복수의 스테이지는 메모리 스테이지(memory stage) 및 라이트백 스테이지(writeback stage)를 포함함 -; 메모리 스테이지 메모리 스테이지의 완료에 앞서 동작하는 통합된 메타데이터 처리용 프로그래머블 유닛(programmable unit for metadata processing)(PUMP) - PUMP는 메타데이터 처리에서 사용된 제 1 메타데이터 태그를 갖는 제 1 메모리 위치를 참조하는 현재 명령어에 대한 메타데이터 처리를 수행하고, PUMP는 현재 명령어에 대한 제 1 메타데이터 태그를 포함하는 제 1 입력을 수신하며, PUMP는 라이트백 스테이지에 입력으로서 제공되는 제 1 출력을 발생하고, 제 1 출력은 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값 및 현재 명령어의 결과 오퍼랜드에 대한 제 1 결과 메타데이터 태그를 포함하고, 제 1 결과 메타데이터 태그는 제 1 메모리 위치에 대한 제 1 메타데이터 태그의 예측된 값에 따라 PUMP에 의해 결정됨 -; 및 제 1 메모리 위치에 대한 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭하는지를 결정하며, 제 1 메타데이터가 제 1 메타데이터 태그의 예측된 값과 매칭할 때 제 1 결과 메타데이터 태그를 결과 오퍼랜드에 대한 최종 결과 메타데이터 태그로서 사용하는 라이트백 스테이지의 하드웨어 컴포넌트를 포함한다. PUMP는 메모리 스테이지와 동시에 동작하고 예측 모드에서 더 동작하는 제 1 PUMP일 수 있으며 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값을 결정할 수 있으며, 시스템은 정상의 비-예측 모드에서 동작하는 제 2 PUMP를 포함할 수 있으며 제 1 메모리 위치의 제 1 메타데이터 태그에 대한 임의의 예측된 값을 결정하지 않을 수 있다. 제 2 PUMP는 메모리 스테이지와 라이트백 스테이지 사이의 다른 스테이지로서 통합될 수 있다. 제 1 PUMP는 예측 모드에서 동작할 때 사용하기 위한 제 1 정책의 규칙의 제 1 버전을 사용할 수 있으며, 제 2 PUMP는 정상의 비-예측 모드에서 동작할 때 사용하기 위한 제 1 정책의 규칙의 제 2 버전을 사용할 수 있다. 제 1 PUMP는 제 1 버전으로부터의 제 1 규칙에 따라 제 1 출력을 결정할 수 있으며, 제 2 PUMP는 제 2 버전으로부터의 제 2 규칙에 따라 제 2 출력을 결정할 수 있다. 제 2 출력은 제 1 메모리 위치에 대한 제 2 결과 메타데이터 태그를 포함할 수 있으며 상기 제 2 출력은 라이트백 스테이지로의 입력으로서 제공될 수 있다. 라이트백 스테이지의 하드웨어 컴포넌트는 제 1 메타데이터 태그가 예측된 값과 매칭하지 않을 때 제 2 결과 메타데이터 태그를 결과 오퍼랜드에 대한 최종 결과 메타데이터 태그로서 추가로 사용할 수 있다.
본 명세서에서의 기술의 다른 양태에 따르면, 비일시적 컴퓨터 판독가능한 매체는 실행될 때, 태깅된 데이터 소스와 태깅되지 않은 데이터 소스 사이에서 프로세서-중재 데이터 이전 방법을 수행하는 저장된 코드를 포함하고, 태깅된 데이터 소스와 태깅되지 않은 데이터 소스 사이에서 프로세서-중재 데이터 이전 방법은: 프로세서상에서, 태깅되지 않은 데이터 소스로부터 제 1 데이터를 로드하는 제 1 명령어를 실행하는 단계 - 태깅되지 않은 데이터 소스는 연관된 메타데이터 태그를 갖지 않는 메모리 위치를 포함함 -; 제 1 하드웨어에 의해, 제 1 데이터가 신뢰성이 없고 공개적 데이터 소스(public data source)로부터 온 것임을 나타내는 제 1 메타데이터 태그로 제 1 데이터를 태깅하는 단계 - 제 1 메타데이터 태그를 갖는 제 1 데이터는 제 1 버퍼에 저장됨 -; 및 프로세서상에서, 제 1 하나 이상의 규칙을 사용하는 메타데이터 처리를 트리거하는 제 1 코드를 실행하는 단계를 포함하고, 제 1 하나 이상의 규칙을 사용하는 메타데이터 처리는 제 1 데이터가 신뢰성 있음을 나타내는 제 2 메타데이터 태그를 갖도록 제 1 데이터를 재 태깅하는 재태깅을 수행한다.
본 명세서에서의 기술의 다른 양태에 따르면, 비일시적 컴퓨터 판독가능한 매체는 실행될 때, 현재 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하고, 현재 명령어를 처리하는 방법은: 메타데이터 처리를 위해, 현재 명령어를 수신하는 단계; 및 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 현재 명령어에 대한 메타데이터 처리를 수행하는 단계를 포함하고, 현재 명령어는 메타데이터 처리에서 사용되는 제 1 메타데이터 태그를 갖는 제 1 메모리 위치를 참조하고, 현재 명령어에 대한 메타데이터 처리는: 메모리로부터 제 1 메타데이터 태그를 검색하는 처리를 수행하는 단계; 메모리로부터 제 1 메모리 위치에 대한 제 1 메타데이터 태그를 수신하기에 앞서, 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값을 결정하는 단계; 제 1 메모리 위치의 제 1 메타데이터 태그의 예측된 값을 사용하여, 현재 명령어의 결과 오퍼랜드에 대한 제 1 결과 메타데이터 태그를 결정하는 단계; 및 메모리로부터, 제 1 메타데이터 태그를 수신하는 것; 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭하는지를 결정하는 단계; 및 제 1 메타데이터 태그가 제 1 메타데이터 태그의 예측된 값과 매칭한다고 결정하는 것에 응답하여, 제 1 결과 메타데이터 태그를 결과 오퍼랜드에 대한 최종 결과 메타데이터 태그로서 사용하는 단계를 포함한다.
본 명세서에서 본 기술의 특징 및 장점은 첨부된 도면과 함께 설명된 이하의 실시예에 관한 상세한 설명으로부터 더욱 명백해질 것이다.
도 1은 프로세서 파이프라인에서 파이프라인 스테이지로서 통합된 PUMP 캐시의 예를 도시하는 개략도이다.
도 2는 PUMP 평가 프레임워크(PUMP Evaluation Framework)를 도시하는 개략도이다.
도 3a는 도 2에 도시된 평가 프레임워크를 사용하여 간단히 실시한 단일 런타임 정책에 대한 성능 결과를 도시하는 그래프이다.
도 3b는 간단한 구현에 따른 단일 에너지 정책의 성능 결과를 도시하는 그래프이다.
도 4a는 64b 태그(Tag)를 갖는 간단한 구현의 복합 정책 런타임 오버헤드(composite policy runtime overhead)를 도시하는 일련의 막대 그래프이고, 여기서 복합 정책은 다음과 같은 정책 (i) 공간적 및 시간적 메모리 안전, (ii) 테인트 추적(taint tracking), (iii) 제어 흐름 무결성(control-flow integrity) 및 (iv) 코드 및 데이터 분리를 동시에 시행한다.
도 4b는 64b 태그를 갖는 간단한 구현의 복합 정책 에너지 오버헤드를 도시하는 일련의 막대 그래프이다.
도 4c는 베이스라인에 비해 간단한 구현에 따른 전력 천장(power ceiling)을 도시하는 일련의 막대 그래프이다.
도 5a는 opgroup 최적화를 하지 않는 그리고 opgroup 최적화를 하는 PUMP 규칙의 수를 비교한 막대 그래프이다.
도 5b는 PUMP 용량에 기초한 다양한 opgroup 최적화의 미스 레이트(miss rate)의 영향을 도시하는 일련의 그래프이다.
도 6a는 복합 정책에 따른 gcc 벤치마크에 대한 각 DRAM 이전에 대한 고유 태그의 분포를 도시하는 그래프로, 대부분의 워드가 동일한 태그를 갖는 것을 보여준다.
도 6b는 메인 메모리 태그 압축을 도시하는 다이어그램이다.
도 7a는 16b L2 태그 및 12b L1 태그 간의 변환을 도시하는 개략도이다.
도 7b는 12b L1 태그 및 16b L2 태그 간의 변환을 도시하는 개략도이다.
도 8a는 L1 PUMP 플러시(flush)에 미치는 L1 태그 길이의 영향을 도시하는 개략적인 그래프이다.
도 8b는 L1 PUMP 미스 레이트에 미치는 L1 태그 길이의 영향을 도시하는 개략적인 그래프이다.
도 9a는 상이한 정책에 대한 미스 레이트를 도시하는 일련의 막대 그래프이다.
도 9b는 네 개의 예시적인 마이크로아키텍처 최적화에 대한 캐시 히트 레이트(cache hit rate)를 도시하는 라인 그래프이다.
도 9c는 미스 서비스 성능(miss service performance)을 나타내는 라인 그래프이다.
도 9d는 용량에 기초한 미스 핸들러 히트 레이트(miss handler hit rate)를 도시하는 라인 그래프이다.
도 9e는 복합 정책에 대한 최적화의 영향을 도시하는 일련의 막대 그래프이다.
도 10a는 최적화된 구현의 런타임 오버헤드를 도시하는 일련의 그래프이다.
도 10b는 최적화된 구현의 에너지 오버헤드를 도시하는 일련의 막대 그래프이다.
도 10c는 베이스라인에 비교하여 최적화된 구현의 절대 전력을 도시하는 일련의 막대 그래프이다.
도 11a는 상이한 대표적인 벤치마크에 대한 태그 비트 길이 및 UCP-캐시($) 용량의 런타임 오버헤드 영향을 도시하는 일련의 음영 처리된 그래프이다.
도 11b는 상이한 대표적인 벤치마크에 대한 태그 비트 길이 및 UCP-$ 용량의 에너지 오버헤드 영향을 도시하는 일련의 음영 그래프이다.
도 12a는 대표적인 벤치마크에 미치는 최적화의 런타임 영향을 도시하는 일련의 그래프로서, A: 간단; B: A + Op그룹화; C: B + DRAM 압축; D: C + (10b L1, 14b, L2) 짧은 태그; E: D + (2048-UCP; 512-CTAG)이다.
도 12b는 대표적인 벤치마크에 미치는 최적화의 에너지 영향을 도시하는 일련의 그래프로서, A: 간단; B: A + Op그룹화; C: B + DRAM 압축; D: C + (10b L1, 14b, L2) 짧은 태그; E: D + (2048-UCP; 512-CTAG)이다.
도 13a는 대표적인 벤치마크에 대한 복합에서의 런타임 정책 영향을 도시하는 일련의 그래프이다.
도 13b는 복합에서의 에너지 정책 영향을 도시하는 일련의 그래프이다.
도 14는 조사된 정책의 요약을 제공하는 "테이블 1"로 표기된 제 1 테이블이다.
도 15는 태깅 체계의 분류의 요약을 제공하는 "테이블 2"로 표기된 제 2 테이블이다.
도 16은 베이스라인 및 간단한 PUMP-확장된 프로세서(PUMP-extended processor)에 대한 메모리 자원 추정의 요약을 제공하는 "테이블 3"으로 표기된 제 3 테이블이다.
도 17은 실험에서 사용된 PUMP 파라미터 범위의 요약을 제공하는 "테이블 4"로 표기된 제 4 테이블이다.
도 18은 PUMP-최적화된 프로세서(PUMP-optimized processor)에 대한 메모리 자원 추정의 요약을 제공하는 "테이블 5"로 표시된 제 5 테이블이다.
도 19는 테인트 추적 미스 핸들러의 요약을 제공하는 "알고리즘 1"로 표기된 제 1 알고리즘이다.
도 20은 N-정책 미스 핸들러의 요약을 제공하는 "알고리즘 2"로 표기된 제 2 알고리즘이다.
도 21은 HW 지원되는 N-정책 미스 핸들러의 요약을 제공하는 "알고리즘 3"으로 표기된 제 3 알고리즘이다.
도 22는 PUMP 규칙 캐시 데이터 흐름 및 마이크로아키텍처의 개략도이다.
도 23은 PUMP 마이크로아키텍처의 개략도이다.
도 24는 도 1과 유사하게, 프로세서 파이프라인 및 그 opgroup 변환, UCP 및 CTAG 캐시들에서 파이프라인 스테이지로서 통합된 예시적인 PUMP 캐시를 도시하는 개략도이다.
도 25는 본 명세서에서의 기술에 따른 실시예에서 제어 상태 레지스터(control status register)(CSR)의 예이다.
도 26은 본 명세서에서의 기술에 따른 실시예에서 태그모드(tagmode)의 예이다.
도 27은 본 명세서에서의 기술에 따른 실시예에서 별도의 프로세서를 갖는 별도의 메타데이터 처리 서브시스템/도메인을 도시하는 예이다.
도 28은 본 명세서에서의 기술에 따른 실시예에서 PUMP 입력 및 출력을 도시한다.
도 29는 본 명세서에서의 기술에 따른 실시예에서 opgroup 테이블과 관련하여 입력 및 출력을 도시한다.
도 30은 본 명세서에서의 기술에 따른 실시예에서 PUMP에 의해 수행된 처리를 도시한다.
도 31 및 도 32는 본 명세서에서의 기술에 따른 실시예에서 PUMP 입력 및 출력의 제어 및 선택에 관한 추가적인 세부 사항을 제공한다.
도 33은 본 명세서에서의 기술에 따른 실시예에서 6 스테이지 처리 파이프라인을 나타내는 예이다.
도 34 내지 도 38은 실시예에서 서브 명령어 및 연관된 기술을 도시하는 예이다.
도 36 내지 도 38은 실시예에서 서브 명령어 및 연관된 기술을 도시하는 예이다.
도 39 내지 도 42는 실시예에서 바이트 레벨 태깅 및 연관된 기술을 예시하는 예이다.
도 43은 본 명세서에서의 기술에 따른 실시예에서 가변 길이 opcode를 도시하는 예이다.
도 44는 본 명세서에서의 기술에 따른 실시예에서 opcode 매핑 테이블을 도시하는 예이다.
도 45는 본 명세서에서의 기술에 따른 실시예에서 공유된 페이지를 도시하는 예이다.
도 46은 본 명세서에서의 기술에 따른 실시예에서 제어 포인트의 이전을 도시하는 예이다.
도 47은 본 명세서에서의 기술에 따른 실시예에서 호출 스택을 도시하는 예이다.
도 48 내지 도 49는 본 명세서에서의 기술에 따른 실시예에서 메모리 위치 태깅 또는 컬러화(coloring)를 도시하는 예이다.
도 50은 본 명세서에서의 기술에 따른 실시예에서 setjmp 및 longjmp를 도시하는 예이다.
도 51, 도 52 및 도 53은 본 명세서에서의 기술에 따른 실시예에서 보호 행위를 구현하는데 사용되는 상이한 런타임 거동 및 연관된 보호 행위 및 메커니즘의 테이블이다.
도 54, 도 55 및 도 56은 본 명세서에서의 기술에 따른 실시예에서 정책 규칙을 학습하거나 결정하기 위해 수행될 수 있는 처리를 도시하는 예이다.
도 57, 도 58, 도 59 및 도 60은 데이터의 외부 버전과 내부 태깅된 버전 사이의 변환과 관련하여 실시예에서의 컴포넌트를 도시하는 예이다.
도 61, 도 62 및 도 63은 본 명세서에서의 기술에 따른 실시예에서 태그 예측을 수행하는 양태를 도시하는 예이다.
도 64 및 도 65는 실시예에서 메모리가 할당된 본 출원의 컬러화 메모리 위치 검출 기술의 사용을 도시한다.
도 66 및 도 67은 본 명세서에서의 기술에 따른 실시예에서 하드웨어 규칙 지원을 제공하는 상이한 컴포넌트를 도시한다.
도 68 내지 도 70은 PUMP가 값을 리턴하는 실시예에서 본 명세서에서의 기술의 사용을 도시하는 예이다.
도 71은 명령어 시퀀스를 갖는 실시예에서 본 명세서에서의 기술의 사용을 도시하는 예이다.
도 72는 본 명세서에서의 기술에 따른 실시예에서 시스템을 부팅하는 것과 관련하여 수행될 수 있는 처리 단계의 흐름도이다.
도 73은 본 명세서에서의 기술에 따른 실시예에서 태그 발생과 관련된 트리 태그 계층(tree tag hierarchy)의 예이다.
도 74, 도 75, 도 76 및 도 77은 본 명세서에서의 기술에 따른 실시예에서 I/O PUMP와 관련한 양태 및 특징을 도시하는 예이다.
도 78, 도 79, 도 80, 도 81 및 도 82는 본 명세서에서의 기술에 따른 실시예에서 태그 값을 저장하고 결정하는 것과 관련하여 사용되는 계층을 도시하는 예이다.
도 83 및 도 84는 본 명세서에서의 기술에 따른 실시예에서 제어 흐름 무결성 및 연관된 처리를 도시하는 예이다.
도 1은 프로세서 파이프라인에서 파이프라인 스테이지로서 통합된 PUMP 캐시의 예를 도시하는 개략도이다.
도 2는 PUMP 평가 프레임워크(PUMP Evaluation Framework)를 도시하는 개략도이다.
도 3a는 도 2에 도시된 평가 프레임워크를 사용하여 간단히 실시한 단일 런타임 정책에 대한 성능 결과를 도시하는 그래프이다.
도 3b는 간단한 구현에 따른 단일 에너지 정책의 성능 결과를 도시하는 그래프이다.
도 4a는 64b 태그(Tag)를 갖는 간단한 구현의 복합 정책 런타임 오버헤드(composite policy runtime overhead)를 도시하는 일련의 막대 그래프이고, 여기서 복합 정책은 다음과 같은 정책 (i) 공간적 및 시간적 메모리 안전, (ii) 테인트 추적(taint tracking), (iii) 제어 흐름 무결성(control-flow integrity) 및 (iv) 코드 및 데이터 분리를 동시에 시행한다.
도 4b는 64b 태그를 갖는 간단한 구현의 복합 정책 에너지 오버헤드를 도시하는 일련의 막대 그래프이다.
도 4c는 베이스라인에 비해 간단한 구현에 따른 전력 천장(power ceiling)을 도시하는 일련의 막대 그래프이다.
도 5a는 opgroup 최적화를 하지 않는 그리고 opgroup 최적화를 하는 PUMP 규칙의 수를 비교한 막대 그래프이다.
도 5b는 PUMP 용량에 기초한 다양한 opgroup 최적화의 미스 레이트(miss rate)의 영향을 도시하는 일련의 그래프이다.
도 6a는 복합 정책에 따른 gcc 벤치마크에 대한 각 DRAM 이전에 대한 고유 태그의 분포를 도시하는 그래프로, 대부분의 워드가 동일한 태그를 갖는 것을 보여준다.
도 6b는 메인 메모리 태그 압축을 도시하는 다이어그램이다.
도 7a는 16b L2 태그 및 12b L1 태그 간의 변환을 도시하는 개략도이다.
도 7b는 12b L1 태그 및 16b L2 태그 간의 변환을 도시하는 개략도이다.
도 8a는 L1 PUMP 플러시(flush)에 미치는 L1 태그 길이의 영향을 도시하는 개략적인 그래프이다.
도 8b는 L1 PUMP 미스 레이트에 미치는 L1 태그 길이의 영향을 도시하는 개략적인 그래프이다.
도 9a는 상이한 정책에 대한 미스 레이트를 도시하는 일련의 막대 그래프이다.
도 9b는 네 개의 예시적인 마이크로아키텍처 최적화에 대한 캐시 히트 레이트(cache hit rate)를 도시하는 라인 그래프이다.
도 9c는 미스 서비스 성능(miss service performance)을 나타내는 라인 그래프이다.
도 9d는 용량에 기초한 미스 핸들러 히트 레이트(miss handler hit rate)를 도시하는 라인 그래프이다.
도 9e는 복합 정책에 대한 최적화의 영향을 도시하는 일련의 막대 그래프이다.
도 10a는 최적화된 구현의 런타임 오버헤드를 도시하는 일련의 그래프이다.
도 10b는 최적화된 구현의 에너지 오버헤드를 도시하는 일련의 막대 그래프이다.
도 10c는 베이스라인에 비교하여 최적화된 구현의 절대 전력을 도시하는 일련의 막대 그래프이다.
도 11a는 상이한 대표적인 벤치마크에 대한 태그 비트 길이 및 UCP-캐시($) 용량의 런타임 오버헤드 영향을 도시하는 일련의 음영 처리된 그래프이다.
도 11b는 상이한 대표적인 벤치마크에 대한 태그 비트 길이 및 UCP-$ 용량의 에너지 오버헤드 영향을 도시하는 일련의 음영 그래프이다.
도 12a는 대표적인 벤치마크에 미치는 최적화의 런타임 영향을 도시하는 일련의 그래프로서, A: 간단; B: A + Op그룹화; C: B + DRAM 압축; D: C + (10b L1, 14b, L2) 짧은 태그; E: D + (2048-UCP; 512-CTAG)이다.
도 12b는 대표적인 벤치마크에 미치는 최적화의 에너지 영향을 도시하는 일련의 그래프로서, A: 간단; B: A + Op그룹화; C: B + DRAM 압축; D: C + (10b L1, 14b, L2) 짧은 태그; E: D + (2048-UCP; 512-CTAG)이다.
도 13a는 대표적인 벤치마크에 대한 복합에서의 런타임 정책 영향을 도시하는 일련의 그래프이다.
도 13b는 복합에서의 에너지 정책 영향을 도시하는 일련의 그래프이다.
도 14는 조사된 정책의 요약을 제공하는 "테이블 1"로 표기된 제 1 테이블이다.
도 15는 태깅 체계의 분류의 요약을 제공하는 "테이블 2"로 표기된 제 2 테이블이다.
도 16은 베이스라인 및 간단한 PUMP-확장된 프로세서(PUMP-extended processor)에 대한 메모리 자원 추정의 요약을 제공하는 "테이블 3"으로 표기된 제 3 테이블이다.
도 17은 실험에서 사용된 PUMP 파라미터 범위의 요약을 제공하는 "테이블 4"로 표기된 제 4 테이블이다.
도 18은 PUMP-최적화된 프로세서(PUMP-optimized processor)에 대한 메모리 자원 추정의 요약을 제공하는 "테이블 5"로 표시된 제 5 테이블이다.
도 19는 테인트 추적 미스 핸들러의 요약을 제공하는 "알고리즘 1"로 표기된 제 1 알고리즘이다.
도 20은 N-정책 미스 핸들러의 요약을 제공하는 "알고리즘 2"로 표기된 제 2 알고리즘이다.
도 21은 HW 지원되는 N-정책 미스 핸들러의 요약을 제공하는 "알고리즘 3"으로 표기된 제 3 알고리즘이다.
도 22는 PUMP 규칙 캐시 데이터 흐름 및 마이크로아키텍처의 개략도이다.
도 23은 PUMP 마이크로아키텍처의 개략도이다.
도 24는 도 1과 유사하게, 프로세서 파이프라인 및 그 opgroup 변환, UCP 및 CTAG 캐시들에서 파이프라인 스테이지로서 통합된 예시적인 PUMP 캐시를 도시하는 개략도이다.
도 25는 본 명세서에서의 기술에 따른 실시예에서 제어 상태 레지스터(control status register)(CSR)의 예이다.
도 26은 본 명세서에서의 기술에 따른 실시예에서 태그모드(tagmode)의 예이다.
도 27은 본 명세서에서의 기술에 따른 실시예에서 별도의 프로세서를 갖는 별도의 메타데이터 처리 서브시스템/도메인을 도시하는 예이다.
도 28은 본 명세서에서의 기술에 따른 실시예에서 PUMP 입력 및 출력을 도시한다.
도 29는 본 명세서에서의 기술에 따른 실시예에서 opgroup 테이블과 관련하여 입력 및 출력을 도시한다.
도 30은 본 명세서에서의 기술에 따른 실시예에서 PUMP에 의해 수행된 처리를 도시한다.
도 31 및 도 32는 본 명세서에서의 기술에 따른 실시예에서 PUMP 입력 및 출력의 제어 및 선택에 관한 추가적인 세부 사항을 제공한다.
도 33은 본 명세서에서의 기술에 따른 실시예에서 6 스테이지 처리 파이프라인을 나타내는 예이다.
도 34 내지 도 38은 실시예에서 서브 명령어 및 연관된 기술을 도시하는 예이다.
도 36 내지 도 38은 실시예에서 서브 명령어 및 연관된 기술을 도시하는 예이다.
도 39 내지 도 42는 실시예에서 바이트 레벨 태깅 및 연관된 기술을 예시하는 예이다.
도 43은 본 명세서에서의 기술에 따른 실시예에서 가변 길이 opcode를 도시하는 예이다.
도 44는 본 명세서에서의 기술에 따른 실시예에서 opcode 매핑 테이블을 도시하는 예이다.
도 45는 본 명세서에서의 기술에 따른 실시예에서 공유된 페이지를 도시하는 예이다.
도 46은 본 명세서에서의 기술에 따른 실시예에서 제어 포인트의 이전을 도시하는 예이다.
도 47은 본 명세서에서의 기술에 따른 실시예에서 호출 스택을 도시하는 예이다.
도 48 내지 도 49는 본 명세서에서의 기술에 따른 실시예에서 메모리 위치 태깅 또는 컬러화(coloring)를 도시하는 예이다.
도 50은 본 명세서에서의 기술에 따른 실시예에서 setjmp 및 longjmp를 도시하는 예이다.
도 51, 도 52 및 도 53은 본 명세서에서의 기술에 따른 실시예에서 보호 행위를 구현하는데 사용되는 상이한 런타임 거동 및 연관된 보호 행위 및 메커니즘의 테이블이다.
도 54, 도 55 및 도 56은 본 명세서에서의 기술에 따른 실시예에서 정책 규칙을 학습하거나 결정하기 위해 수행될 수 있는 처리를 도시하는 예이다.
도 57, 도 58, 도 59 및 도 60은 데이터의 외부 버전과 내부 태깅된 버전 사이의 변환과 관련하여 실시예에서의 컴포넌트를 도시하는 예이다.
도 61, 도 62 및 도 63은 본 명세서에서의 기술에 따른 실시예에서 태그 예측을 수행하는 양태를 도시하는 예이다.
도 64 및 도 65는 실시예에서 메모리가 할당된 본 출원의 컬러화 메모리 위치 검출 기술의 사용을 도시한다.
도 66 및 도 67은 본 명세서에서의 기술에 따른 실시예에서 하드웨어 규칙 지원을 제공하는 상이한 컴포넌트를 도시한다.
도 68 내지 도 70은 PUMP가 값을 리턴하는 실시예에서 본 명세서에서의 기술의 사용을 도시하는 예이다.
도 71은 명령어 시퀀스를 갖는 실시예에서 본 명세서에서의 기술의 사용을 도시하는 예이다.
도 72는 본 명세서에서의 기술에 따른 실시예에서 시스템을 부팅하는 것과 관련하여 수행될 수 있는 처리 단계의 흐름도이다.
도 73은 본 명세서에서의 기술에 따른 실시예에서 태그 발생과 관련된 트리 태그 계층(tree tag hierarchy)의 예이다.
도 74, 도 75, 도 76 및 도 77은 본 명세서에서의 기술에 따른 실시예에서 I/O PUMP와 관련한 양태 및 특징을 도시하는 예이다.
도 78, 도 79, 도 80, 도 81 및 도 82는 본 명세서에서의 기술에 따른 실시예에서 태그 값을 저장하고 결정하는 것과 관련하여 사용되는 계층을 도시하는 예이다.
도 83 및 도 84는 본 명세서에서의 기술에 따른 실시예에서 제어 흐름 무결성 및 연관된 처리를 도시하는 예이다.
다음 단락에서는 메타데이터 태그를 시스템의 메인 메모리, 캐시 및 레지스터 내의 모든 워드와 불가분으로 연관시키는 메타데이터 처리용 프로그래머블 유닛(Programmable Unit for Metadata Processing)(PUMP)의 다양한 실시예와 양태를 설명한다. 무제한의 메타데이터를 지원하기 위해, 태그는 메모리의 데이터 구조체를 간접 지정할 만큼 충분히 크다. 모든 명령어에서, 입력의 태그는 동작이 허용되는지를 결정하고, 허용된다면 결과의 태그를 계산하는데 사용된다. 일부 실시예에서, 태그 검사 및 전파 규칙은 소프트웨어로 정의된다; 그러나 성능 영향을 최소화하기 위해 이러한 규칙은 프로세서의 산술 논리 유닛(arithmetic logic unit)(ALU) 부분과 병렬로 동작하는 하드웨어 구조체인 PUMP 규칙 캐시에 캐싱된다. 일부 실시예에서, 예컨대 소프트웨어 및/또는 하드웨어를 사용하여 구현될 수 있는 미스 핸들러(miss handler)는 현재 시행되는 정책에 기초하여 캐시 미스를 서비스하는데 사용될 수 있다.
PUMP의 성능 영향은 상이한 방식으로 PUMP에 스트레스를 주고 보안 속성의 범위를 예시하는, 예를 들어, (1) 태그를 사용하여 코드를 메모리의 데이터와 구별하고 간단한 코드 삽입 공격(code injection attack)에 대해 보호를 제공하는 실행-불가 데이터 및 기입-불가 코드(Non-Executable Data and Non-Writable Code)(NXD+NWC) 정책; (2) 실질적으로 제한 없는 (260) 수의 컬러("테인트 마크(taint mark)")로 확장하는 힙-할당 메모리(heap-allocated memory)의 모든 공간적 및 시간적 위반을 검출하는 메모리 안전(Memory Safety) 정책; (3) 간접 제어 이전(indirect control transfer)을 프로그램의 제어 흐름 그래프에서 허용된 에지만으로 제한하여, 리턴-지향-프로그래밍-스타일(return-oriented-programming-style) 공격을 방지하는 제어-흐름 무결성(Control-Flow Integrity)(CFI) 정책 (미세 세밀화된 CFI가 시행되지만, 공격에 잠재적으로 취약 가능성 있는 저급으로 근사화한 것은 제외함); 및 (4) 각 워드가 동시에 다수의 소스(라이브러리 및 10 개 스트림)에 의해 잠재적으로 오염될 수 있는 미세 세밀화된 테인트 추적 정책(fine-grained Taint Tracking policy)(일반화)과 같은, 네 개의 상이한 정책의 복합을 사용하는 적어도 하나의 실시예에서, PUMP의 성능 영향이 측정될 수 있다(도 14 참조).
전술한 바는 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 잘 알려진 정책의 예이다. 문헌에서 보호 능력이 확립된 잘 알려진 그러한 정책에 대해, 본 명세서에서의 기술은 그러한 정책을 시행하면서도 또한 PUMP를 사용하여 정책을 시행하는 것의 성능 영향을 줄이는데 사용될 수 있다. NXD+NWC를 제외하고, 이들 정책 각각은 근본적으로 무한한 수의 고유 아이템들을 구별해야 하며; 대조적으로, 메타데이터 비트의 수가 제한된 해결책은 기껏해야 극도로 단순화된 근사화된 해결책만을 지원할 수 있다.
본 명세서의 다른 곳에서 도시되고 설명된 바와 같이, 본 명세서에서의 기술에 따른 일 실시예는 포인터-크기(64b 또는 바이트)의 태그 내지 64b 워드를 사용하여 시스템의 모든 메모리의 크기 및 에너지 사용이 적어도 두배가 되는 PUMP의 간단하고 직접적인 구현을 활용할 수 있다. 규칙 캐시는 이것 이외에 영역 및 에너지를 추가한다. 이러한 특정 실시예에서, 190 %의 영역 오버헤드(도 16 참조)가 측정되었고 약 220 %의 기하학적 의미의 에너지 오버헤드가 측정되었다; 더욱이 일부 애플리케이션에서는 런타임 오버헤드가 300 %를 넘을 수 있다. 이렇게 높은 오버헤드 때문에 이것이 수행될 수 있는 최상의 것이라면 채택할 의욕이 좌절되게 할 수 있다.
그러나 아래에서 자세히 보다 설명하는 것처럼 대부분의 정책은 태그와 그에 대해 정의된 규칙 둘 모두에 대해 공간적 및 시간적 지역성(locality)을 보인다. 따라서, 본 명세서에서의 기술에 따른 실시예는 유사한 (또는 심지어 동일한) 명령어들의 그룹에 대해 규칙을 정의하고, 강제 미스(compulsory miss)를 줄이고 규칙 캐시의 유효 용량을 증가시킴으로써 고유의 규칙의 수를 상당히 감소시킬 수 있다. 오프-칩 메모리 트래픽은 태그의 공간 지역성을 활용하여 줄일 수 있다. 온-칩 영역 및 에너지 오버헤드는 소수의 비트를 사용하여 한 번에 사용 중시의 포인터-크기(point-sized) 태그의 서브세트를 한 번에 표현함으로써 최소화될 수 있다. 복합 정책 미스 핸들러의 런타임 비용은 컴포넌트 정책을 캐싱하기 위한 하드웨어 지원을 제공함으로써 감소될 수 있다. 따라서, 본 명세서에서의 기술에 따른 실시예는 그러한 최적화를 포함할 수 있고, 그럼으로써 PUMP가 그의 풍부한 정책 모델을 훼손하지 않으면서 더 낮은 오버헤드를 달성할 수 있게 한다.
본 명세서에서의 기술에 따른 실시예는 별도로 또는 동시에 시행될 수 있는 임의의 수의 보안 정책을 인코딩하는데 사용될 수 있는 메타데이터로 메모리 워드 및 내부 프로세서 상태를 강화할 수 있다. 본 명세서에서의 기술에 따른 실시예는 "통상의" 프로세서(예를 들어, RISC-CPU, GPU, 벡터 프로세서 등)에다 데이터 흐름과 병렬로 작동하는 메타데이터 처리 유닛(PUMP)을 추가시킴으로써 전술한 바를 달성할 수 있고; 본 개시내용의 기술은 특별히 본 명세서에서의 기술이 광범위한 메타데이터 처리 정책에 적응되고 적용될 수 있도록 메타데이터를 제한 없고 소프트웨어적으로 프로그래밍 가능하게 만든다. 예를 들어, PUMP는 통상적인 (RISC) 프로세서의 새로운/별도의 파이프라인 스테이지로서 통합될 수 있거나, "호스트" 프로세서와 병렬로 작동하는 하드웨어의 스탠드얼론 단편으로 통합될 수 있다. 전자의 경우, 설계를 특성화하기 위하여 명령어 레벨 시뮬레이터, 정교한 정책, 구현 최적화와 자원 추정 및 광범위한 시뮬레이션이 있을 수 있다.
정책을 미세한 (즉, 명령어) 세분화 레벨(granularity level)에서 시행하려는 기존 해결책은 임의의 세트의 정책들을 시행할 수 없다. 보통, 소수의 고정 정책만이 명령어 레벨에서 시행될 수 있다. 더 높은 세분화 레벨(즉, 스레드)에서 정책을 시행하면 리턴 지향형 프로그래밍(Return Oriented Programming) 공격의 특정 부류를 예방할 수 없고, 이에 따라 그 유용성에 있어서 그런 유형의 시행은 제한적이 된다. 대조적으로, 본 명세서에서의 기술에 따른 실시예는 명령어 레벨에서 단독으로 또는 동시에 시행될 수 있는 무한한 수의 정책의 표현을 가능하게 한다(메타데이터는 임의의 모든 데이터 구조체를 가리킬 수 있는 어드레스 포인터의 관점에서 표현되기 때문에 유일한 제한은 크기 어드레스 공간(size address space)이다).
다음의 단락에서 설명되는 다양한 도면은 본 명세서에서 설명된 기술의 다양한 양태의 다양한 예, 방법 및 다른 예시적인 실시예를 도시한다는 것을 유의해야 한다. 그러한 도면에서, 도시된 요소 경계(예를 들어, 박스, 박스들의 그룹 또는 다른 형상)는 일반적으로 경계의 일례를 나타낸다는 것임을 인식할 것이다. 관련 기술분야에서 통상의 기술자라면 일부 예에서 하나의 요소가 다수의 요소로서 설계될 수 있거나 다수의 요소가 하나의 요소로서 설계될 수 있음을 인식할 것이다. 일부 예에서, 다른 요소의 내부 컴포넌트로 도시된 요소는 외부 컴포넌트로 구현될 수 있고 그 반대의 경우도 가능하다. 그뿐만 아니라, 요소는 일정한 비율로 그려지지 않을 수도 있다.
도 1을 참조하면, 메타데이터 처리용 프로그래머블 유닛(PUMP)(10)은 에너지 절약(energy-conscious) 애플리케이션에 적합한 순서적(in-order) 구현 및 5-스테이지 파이프라인을 갖는 통상의 축소 명령어 집합 컴퓨팅 또는 컴퓨터(Reduced Instruction Set Computing or Computer)(RISC)로 통합될 수 있고, PUMP(10)가 추가된 6-스테이지 파이프라인으로 효과적으로 변환된다. 제 1 스테이지는 페치 스테이지(fetch stage)(14)이고, 제 2 스테이지는 디코드 스테이지(decode stage)(16)이고, 제 3 스테이지는 실행 스테이지(execute stage)(18)이고, 제 4 스테이지는 메모리 스테이지(memory stage)(20)이고, 제 5 스테이지는 라이트백 스테이지(writeback stage)(22)이다. PUMP(10)는 메모리 스테이지(20)와 라이트백 스테이지(22) 사이에 개재된다.
다양한 실시예는 정책 시행 및 메타데이터 전파를 제공하는 메커니즘인 전자 로직을 사용하여 PUMP(10)를 구현할 수 있다. PUMP(10)의 실시예는 (i) 네 개의 다양한 정책 및 정책의 조합 하에서 벤치마크들의 표준 세트에 미치는PUMP(10)의 간단한 구현의 런타임, 에너지, 전력 상한 및 영역 영향에 대한 경험적 평가; (ii) 한 세트의 마이크로-아키텍처 최적화; (iii) 온-칩 메모리 구조체에 110 % 추가 영역을 사용함으로써 10 % 미만의 전형적인 런타임 오버헤드, 10 %의 전력 상한, 및 60 % 미만의 전형적인 에너지 오버헤드를 특징으로 할 수 있다.
컴퓨팅 시, 벤치마킹은 개체의 상대적 성능을 평가하기 위하여, 다수의 표준 테스트 및 테스트에 대한 시도를 정상적으로 실행함으로써, 컴퓨터 프로그램, 한 세트의 프로그램 또는 다른 동작을 실행하는 행위라고 특징지을 수 있다. 본 명세서에서 사용되는 '벤치마크'라는 용어는 벤치마킹 프로그램 자체를 지칭한다. 이러한 애플리케이션 및 도면 전체에서 사용되는 벤치마크 프로그램 유형은 GemsFDTD, astar, bwaves, bzip2, cactusADM, calculix, deall, gamess, gcc, gobmk, gromacs, h264ref, hmmer, Ibm, leslie3d, libquantum, mcf, mile, namd, omnetpp, perlbench, sjeng, specrand, sphinx3, wrf, zeusmp 및 mean이다. 예를 들면, 도 10a, 도 10b 및 도 10c를 참조한다.
본 명세서에서 사용되는 것으로서 "로직"은 기능(들) 또는 행위(들)을 수행하고 및/또는 다른 로직, 방법 및/또는 시스템으로부터 기능 또는 행위를 유발하는 하드웨어, 펌웨어, 소프트웨어 및/또는 각각의 조합을 포함하지만, 이것으로 제한되는 것은 아니다. 예를 들어, 원하는 어플리케이션 또는 필요에 따라, 로직은 소프트웨어 제어형 마이크로프로세서, 프로세서(예를 들어, 마이크로프로세서)와 같은 이산적 로직, 주문형 집적 회로(application specific integrated circuit)(ASIC), 프로그램된 로직 디바이스, 명령어들을 담은 메모리 디바이스, 메모리를 갖는 전기 디바이스 등을 포함할 수 있다. 로직은 하나 이상의 게이트, 게이트들의 조합 또는 다른 회로 컴포넌트를 포함할 수 있다. 로직은 또한 전체적으로 소프트웨어로 구현될 수도 있다. 다수의 로직이 설명되는 경우, 다수의 로직을 하나의 물리적 로직에 통합하는 것이 가능할 수 있다. 유사하게, 단일의 로직이 설명되는 경우, 다수의 물리적 로직 사이에 그 단일의 로직을 분포시키는 것이 가능할 수 있다.
본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, PUMP(10)는 통상의 RISC 프로세서(12)에 대한 확장으로 특징지을 수 있다. 다음의 단락은 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 PUMP(10)의 하드웨어 인터페이스 계층, 기본 마이크로아키텍처적 변경 및 동반하는 낮은 레벨의 소프트웨어를 구성하는 ISA(instruction set architecture)-레벨 확장의 추가적인 세부 사항을 제공한다.
본 명세서에서의 기술에 따른 실시예에서, PUMP-강화된 시스템(PUMP-enriched system)의 각 워드는 포인터-크기 태그와 연관될 수 있다. 이러한 태그는 하드웨어 레벨에서 해석되지 않다. 소프트웨어 레벨에서, 태그는 정책에 의해 정의된 것으로서, 무한한 크기 및 복잡성을 갖는 메타데이터를 나타낼 수 있다. 단지 몇 비트의 메타데이터만을 필요로 하는 더 간단한 정책은 메타데이터를 태그에 직접 저장할 수 있고; 더 많은 비트가 필요하면, 메타데이터를 데이터 구조체로서 메모리에 저장하는 간접 지정(indirection)이 사용되며, 이러한 구조체의 주소는 태그로서 사용된다. 특히, 이러한 포인터-크기 태그는 본 개시내용의 하나의 예시적인 양태이며, 제한적인 것으로 간주되지 않는다. 기본 어드레스 가능 메모리 워드는 불가분적으로 태그로 확장되어, 메모리, 캐시 및 레지스터를 비롯한 모든 값 슬롯을 적절하게 넓게 만든다. 프로그램 카운터(program counter)(PC)에도 또한 태깅된다. 소프트웨어-정의된 메타데이터 및 포인터-크기 태그로서 그 표현의 이러한 개념은 몇 비트만이 태그에 사용되고 및/또는 몇 비트가 고정된 해석으로 하드와이어드 이전의 태깅 접근법을 확장한다. 태깅 체계의 일부 예시적인 분류는 도 15에 재현되는 테이블 2에 제시된다.
메타데이터 태그는 사용자 프로그램에 의해 어드레스 지정될 수 없다. 오히려, 메타데이터 태그는 아래에서 세부 설명된 규칙 캐시 미스 때 호출되는 정책 핸들러에 의해 어드레스 지정된다. 태그에 대한 모든 업데이트는 PUMP(10) 규칙을 통해 실현된다.
무한한 메타데이터 외에, 본 명세서에서의 기술에 따른 PUMP(10)의 실시예의 다른 특징은 메타데이터에 대해 단일 사이클 공통-사례 계산을 위한 하드웨어 지원이다. 이러한 계산은 opcode: (PC, CI, OP1, OP2, MR) => (PCnew, R)이라는 형태의 규칙의 관점에서 정의되고, 이는 "현재 opcode가 opcode이면, 프로그램 카운터 상의 현재 태그는 PC이고, 현재 명령어 상의 태그가 CI이고, (만일 있다면) 그의 입력 오퍼랜드 상의 태그가 OP1및 OP2이며, (로드(load)/스토어(store)의 경우) 메모리 위치 상의 태그가 MR 이면, 다음 머신 상태의 프로그램 카운터 상의 태그는 PCnew이어야 하며 명령어 결과상의 태그(만일 있다면, 목적지 레지스터 또는 메모리 위치)는 R이어야 한다"라고 판독되어야 한다. 두 개의 출력 태그를 최대 다섯 개의 입력 태그에서 계산될 수 있게 하는 이러한 규칙 포맷은 최대 두 개의 입력으로부터 하나의 출력을 전형적으로 계산하는 이전 동작에서 고려된 것보다 현저하게 융통적이다(도 15의 테이블 2 참조). 데이터 태그(OP1, OP2, MR, R)를 단지 추적하기만 하는 이전의 해결책 외에도, 본 개시내용은 코드 블록의 출처, 무결성 및 사용을 추적하고 시행하는데 사용될 수 있는 현재 명령어 태그(current instruction tag)(CI)를 제공하고; 그뿐만 아니라 실행 이력, 주변 인가(ambient authority) 및 암시적 정보 흐름을 포함하는 "제어 상태"를 기록하는데 사용할 수 있는 PC 태그를 제공한다. CFI 정책은 PC 태그를 이용하여 간접 점프(indirect jump)의 소스를 기록하기 위한 PC 태그 및 점프 타깃을 식별하기 위한 CI 태그를 이용하며, NXD + NWC는 CI를 적극 활용하여 데이터가 실행 가능하지 않도록 시행하고, 테인트 추적(Taint Tracking)은 이를 생성하였던 코드에 기초하여 데이터를 오염시키는 CI를 사용한다.
일반적인 사례에서 단일 사이클에서 규칙을 해결하기 위해, 본 명세서에서의 기술에 따른 실시예는 가장 최근에 사용된 규칙의 하드웨어 캐시를 사용할 수 있다. 명령어 및 정책에 따라, 주어진 규칙에서 입력 슬롯들 중 하나 이상이 사용되지 않을 수 있다. 사용되지 않는 슬롯의 모든 가능한 값에 대한 규칙으로 캐시를 오염시키는 것을 방지 하기 위해, 규칙-캐시 룩업 로직(lookup logic)은 각 입력 슬롯-opcode 쌍에 대해, 대응하는 태그가 규칙 캐시 룩업 시에 실제로 사용되는지를 결정하는, "돈-케어(don't-care)" (도 1 참조) 비트가 들어있는 비트 벡터를 참조한다. 이러한 "돈-케어" 입력을 효율적으로 처리하기 위해, 이들 입력은 입력을 PUMP(10)에 제시하기 전에 마스킹된다. 돈-케어 비트 벡터는 미스 핸들러 설치의 일부로서 권한 있는(privileged) 명령어에 의해 설정된다.
도 1은 일반적으로 PUMP(10) 하드웨어를 통합한 수정된 5-스테이지 프로세서(12) 파이프라인을 갖는 본 명세서에서의 기술에 따른 일 실시예를 도시한다. PUMP(10) 스테이지가 프로세서 파이프라인에 추가 기능정지(stall)를 생성하지 않도록 규칙 캐시 룩업이 추가 스테이지 및 바이패스 태그 및 데이터로서 독립적으로 추가된다.
(메모리 스테이지(20)와 라이트백 스테이지(22) 사이에) 별도의 스테이지로서 PUMP(10)를 배치하는 것은 메모리(로드)로부터 판독된 워드 상에 태그를 제공(로드)할 필요에 의해 또는 PUMP(10)로의 입력으로서 메모리(스토어)에 오버라이트(overwirite)되게 할 필요에 의해 동기 부여된 것이다. 기입되는 메모리 위치의 기존 태그에 의존하는 규칙이 허용되기 때문에, 기입 동작은 판독-수정-기입 동작이 된다. 판독 규칙과 같은 메모리 스테이지(20) 동안 기존 태그가 판독되고, 판독 규칙은 PUMP(10) 단계에서 체크되고, 기입은 라이트백 스테이지(22)라고도 지칭될 수 있는 커밋 스테이지(Commit stage) 동안 수행된다. 임의의 캐싱 체계와 함께, 다중 레벨의 캐시가 PUMP(10)에 사용될 수 있다. 아래에서 보다 상세히 설명하는 바와 같이, 본 명세서에서의 기술에 따른 실시예는 두 레벨의 캐시를 이용할 수 있다. 다중 레벨의 캐시로의 확장은 관련 기술분야에서 통상의 기술자에게 용이하게 자명하다.
비 제한적인 하나의 예에서, 라이트백 스테이지(22)의 규칙 캐시에서 최종 레벨 미스가 발생할 때, 다음과 같이 처리된다: (i) 현재의 opcode 및 태그는 이 목적을 위해서만 사용되는 프로세서 레지스터의 (새로운) 세트에 저장되고, (ii) 제어는 정책 미스 핸들러(아래에서 보다 자세히 설명됨)로 이전되며, (iii) 동작이 허용되는지 그리고 허용된다면 적절한 규칙이 생성되는지를 결정한다. 미스 핸들러가 리턴할 때, 하드웨어는 (iv) 이 규칙을 PUMP(10) 규칙 캐시에 설치하고, (v) 결함유도(faulting) 명령어를 재-발행한다. 권한을 받은 미스 핸들러와 나머지 시스템 소프트웨어 및 사용자 코드 사이의 분리를 제공하기 위해, 규칙 캐시 미스상에 설정되고 핸들러가 리턴할 때 리셋되는 프로세서 상태의 비트에 의해 제어되는 미스 핸들러 동작 모드가 프로세서에 추가된다. 모든 규칙 캐시 미스에 관해 레지스터를 저장하고 복원할 필요를 방지하기 위해, 정수 레지스터 파일이 미스 핸들러에서만 이용 가능한 16 개의 추가 레지스터로 확장할 수 있다.
또한, 규칙 입력 및 출력은 미스 핸들러(다른 것은 제외함)가 태그를 일반 값으로 조작할 수 있게 하는 미스 핸들러 모드(예를 들어, 레지스터 윈도우)에서, 레지스터로서 출현한다. 되풀이 하면, 이것들은 모두 라이트백 스테이지(22)의 비 제한적인 예이다.
새로운 미스 핸들러 리턴 명령어가 추가되어 규칙을 PUMP(10) 규칙 캐시에 설치하고 사용자 코드로 리턴한다. 이와 같은 특정의 비 제한적인 실시예에서, 이러한 명령어는 미스 핸들러 모드에 있을 때만 발행될 수 있다. 미스 핸들러 모드에 있는 동안, 규칙 캐시는 무시되고 그 대신 PUMP(10)는 단일의 하드와이어드 규칙을 대신 적용한다: 미스 핸들러가 접촉한 모든 명령어 및 데이터는 미리 정의된 MISSHANDLER 태그로 태깅되어야하며, 모든 명령어 결과에는 동일한 태그가 주어진다. 이러한 방식으로, PUMP(10) 아키텍처는 사용자 코드가 정책에 의해 제공되는 보호를 약화시키는 것을 방지한다. 대안적으로, PUMP는 미스 핸들러 액세스에 관한 융통성 있는 규칙을 시행하는데 사용될 수 있다. 태그는 사용자 코드에 의해 나눌 수 있거나, 어드레스 지정 가능하거나, 또는 교체 가능하지 않고; 메타데이터 데이터 구조체 및 미스 핸들러 코드는 사용자 코드에 의해 건드릴 수 없으며; 사용자 코드는 규칙을 규칙 캐시에 직접 삽입할 수 없다.
도 19를 참조하면, 알고리즘 1은 테인트 추적 정책을 위한 미스 핸들러의 동작을 도시한다. 개별 태그(및 규칙)의 수를 최소화하기 위해, 미스 핸들러는 구축하는 임의의 새로운 데이터 구조체를 "정규화(canonicalization)"하여 논리적으로 동등한 메타데이터에 단일 태그를 사용한다.
사용자가 단일 정책을 선택하도록 강요하는 대신, 다수의 정책을 동시에 시행하고 나중에 새로운 정책을 추가한다. 이러한 "무한" 태그의 예시적인 장점은 이들이 동시에 임의의 수의 정책을 시행할 수 있다는 것이다. 이것은 태그를 여러 컴포넌트 정책으로부터의 태그들의 튜플(tuple)을 가리키는 포인터가 되게 함으로써 달성될 수 있다. 예를 들어 NXD+NWC 정책을 테인트 추적 정책과 조합하기 위해, 각 태그는 튜플(s, t)을 가리키는 포인터가 될 수 있으며, 여기서 s는 NXD+NWC 태그(DATA 또는 CODE)이고, t는 테인트 태그(테인트들의 세트를 가리키는 포인터)이다. 규칙 캐시 룩업은 비슷하며; 그러나 미스가 발생할 때 두 컴포넌트 정책이 별도로 평가된다: 두 정책이 이를 허용하는 경우에만 동작이 허용되며, 결과적인 태그는 두 컴포넌트 정책의 결과의 쌍이다. 그러나, 다른 실시예들에서, 정책이 어떻게 (단순히 모든 구성 컴포넌트 사이에 AND로서가 아니라) 조합되어야 하는지를 표현하는 것이 가능할 수 있다.
도 20을 참조하면, 알고리즘 2는 모든 N 정책에 대한 복합 미스 핸들러의 일반적인 거동을 도시한다. 튜플 내의 태그가 어떻게 상관되는지에 따라, 태그 수 및 규칙 수가 크게 증가하는 결과를 가져올 수 있다. 다수의 정책을 동시에 지원하고 작업 세트 크기(working set size)에 미치는 영향을 측정하기 위해, 실험을 통해 복합 정책("복합")이 구현되었으며, 여기서 복합 정책은 위에 설명된 모두 네 개의 정책을 포함한다. 복합 정책은 지원되는 정책 작업부하의 종류를 나타내며 아래에서 자세히 설명한다. 도 4a 및 도 20에서 도시된 바와 같이, 복합 정책은 다음의 정책, (i) 공간적 및 시간적 메모리 안전, (ii) 테인트 추적, (iii) 제어 흐름 무결성 및 (iv) 코드 및 데이터 분리를 동시에 시행한다.
대부분의 정책은 적절한 로직을 선택하기 위해 opcode 상에 디스패치한다. NXD+NWC와 같은 일부 정책은 동작이 허용되는지를 바로 체크할 것이다. 다른 정책은 데이터 구조체를 참고할 수 있다(예를 들어, CFI 정책은 허용된 간접 호출 및 리턴 id의 그래프를 참고한다). 메모리 안전은 어드레스 컬러(즉, 포인터 컬러)와 메모리 영역 컬러 간의 동일성을 체크한다. 테인트 추적은 입력 태그(알고리즘 1)를 조합함으로써 새로운 결과 태그를 계산한다. 대규모 데이터 구조체에 액세스해야 하는 정책(CFI) 또는 대규모 집계 전체를 표준화해야 하는 정책(테인트 추적, 복합)은 온-칩 캐시에서 미스를 발생하여 DRAM으로 이동하는 많은 메모리 액세스를 만들 수 있다. 모든 벤치마크 전체를 평균하여, NXD+NWC에 대한 미스를 서비스하는데 30 사이클, 메모리 안전에 60 사이클, CFI에 85 사이클, 테인 추적에 500 사이클 및 복합에 800 사이클이 필요했다.
정책 미스 핸들러가 동작이 허용되지 않는다고 결정하면, 적합한 보안 결함 핸들러(security fault handler)를 호출한다. 이 결함 핸들러가 행하는 일은 런타임 시스템 및 정책에 달려 있고; 전형적으로, 이것은 문제가 되는 프로세스를 종료할 것이지만, 대신에 경우에 따라 적절한 "안전한 값"을 리턴할 수 있다. UNIX-스타일 오퍼레이팅 시스템을 사용한 점진적 전개의 경우, 추정된 정책이 프로세스마다 적용되어, 각 프로세스는 서로 다른 정책 세트를 가질 수 있다. 프로세스 당 적용되는 리사이테이션(recitation)은 비 제한적이지만 오히려 예시적이고 관련 기술분야에서 통상의 기술자는 이를 인식한다. 또한 이것은 우리가 태그, 규칙 및 미스 핸들링 지원을 프로세스의 어드레스 공간에 배치할 수 있게 해주어, OS 레벨의 컨텍스트 전환이 필요하지 않게 한다. 장기적으로, 아마도 PUMP 정책은 OS도 보호하는데 사용될 수 있다.
런타임, 에너지, 면적 및 전력 오버헤드를 측정하기 위한 다음의 세부 평가 방법론은 128b 워드(64b 페이로드 및 64b 태그) 및 도 1에 도시된 수정된 파이프라인 프로세서(12)를 사용하여 이것을 PUMP 하드웨어 및 소프트웨어의 간단한 구현에 적용한다. 최적화된 구현은 (베이스라인 프로세서와 관련하여) 오버헤드를 궁극적으로 바라던 버전일지라도, 간단한 PUMP 구현을 먼저 설명하고 측정하는 것이 유용하다. 보다 정교한 버전에 다다르기 전에 이것이 핵심 메커니즘의 기본 버전을 상세히 열거하기 때문에 둘 모두 설명된다.
PUMP의 물리적 자원 영향을 평가하기 위해, 메모리 비용에 무엇보다 먼저 초점이 맞추어졌는데, 왜냐하면 메모리는 간단한 RISC 프로세서 및 PUMP 하드웨어 확장 시 주요한 영역이고 에너지 소비자이기 때문이다. 32 nm의 낮은 동작 전력(Low Operating Power)(LOP) 프로세스는 L1 메모리(도 1 참조) 용도로 고려되며, 낮은 대기 전력(Low Standby Power)(LSTP)은 L2 메모리 용도로 고려되고, 면적, 액세스 시간, 액세스 당 에너지 및 메인 메모리와 프로세서 온-칩 메모리의 정적(누설) 전력을 모델링하기 위해서는 CACTI 6. 5를 사용한다.
베이스라인 프로세서(PUMP 없음)는 데이터 및 명령어용의 별도의 64KB L1 캐시 및 일원화된 512KB L2 캐시를 갖는다. 지연에 최적화된 L1 캐시 및 에너지에 최적화된 L2 캐시가 사용되었다. 모든 캐시는 라이트백 규율(writeback discipline)을 사용한다. 베이스라인 L1 캐시는 약 880ps의 대기 시간을 가지며; 한 사이클 내에서 결과를 리턴할 수 있고 그 클럭을 1 ns로 설정하여 근래의 내장형 셀 폰 프로세서에 필적하는 1 GHz 사이클 목표를 제공할 수 있다고 추정된다. 이 프로세서의 파라미터는 도 16의 테이블 3에 제시된다.
PUMP 규칙 캐시(10) 하드웨어 구현의 일 실시예는 두 부분: 스테이지(14, 16, 20) 내의 모든 아키텍처적 상태를 태그로 확장하는 것 및 프로세서(12)에 PUMP 규칙 캐시를 추가하는 것을 포함할 수 있다. 온-칩 메모리 내의 각각의 64b 워드를 64b 태그로 확장하는 것은 액세스 당 영역 및 에너지를 증가시키고 액세스 대기 시간을 악화시킨다. 이것은 이미 다중 사이클 액세스 대기 시간을 가지며 매 사이클마다 사용되지 않는 L2 캐시가 잠재적으로 견딜 가능성이 있다. 그러나 L1 캐시(도 1 참조)에 액세스하기 위한 가외의 대기 시간 사이클을 추가하면 파이프라인에서 기능정지를 초래할 수 있다. 이것을 피하기 위해, 이러한 간단한 구현에서 L1 캐시의 유효 용량이 기본 설계의 절반으로 줄어든 다음 태그를 추가하는데; 이것은 L1 캐시에 대해 동일한 단일 사이클 액세스를 제공하지만 미스가 증가함으로 인해 성능을 저하시킬 수 있다.
본 명세서에서의 기술에 따른 실시예에서, PUMP 규칙 캐시(10)는 전통적인 캐시 어드레스 키(cache address key)(어드레스 폭 미만)와 비교되는 롱 매치 키(long match key)(5 포인터-크기 태그 및 명령어 opcode 또는 328b)를 이용하고, 128b 결과를 리턴한다. 일 실시예에서, 완전 연관 L1 규칙 캐시가 사용될 수 있지만 높은 에너지 및 지연을 초래할 수 있다(도 16의 테이블 3 참조). 대안으로서, 본 명세서에서의 기술에 따른 실시예는 도 22에 도시된 바와 같이, 네 개의 해시 함수로 영감을 얻은 다중 해시 캐시 방식을 이용할 수 있다. L1 규칙 캐시는 단일 사이클에서 결과를 생성하고, 제 2 사이클에서 거짓 히트(false hit)에 대해 체크하는 반면, L2 규칙 캐시는 낮은 에너지 용도로 설계되어 다중 사이클 액세스 대기 시간을 제공한다. 되풀이 하면, 도 16의 테이블 3은 간단한 구현에 사용된 1024-엔트리 L1 및 4096-엔트리 L2 규칙 캐시의 파라미터를 도시한다. 이러한 캐시가 용량에 도달할 때, 간단한 선입 선출(first-in-first out)(FIFO) 대체 정책이 사용되는데, 이 정책은 현재 동작 부하에서 실제로 잘 작동하는 것으로 보인다(FIFO는 본 출원에서 LRU의 6 % 이내임).
도 2를 참조하면, PUMP의 성능 영향 평가는 ISA, PUMP 및 어드레스-트레이스 시뮬레이터의 조합을 식별한다. gem5 시뮬레이터(24)는 64-비트 Alpha 베이스라인 ISA상에서 SPEC CPU2006 프로그램(gem5가 실패한 xalancbmk 및 tonto을 생략함)에 대한 명령어 트레이스를 발생한다. 각 프로그램은 1B 명령어의 워밍업 기간 동안 위에 열거된 네 개의 정책 각각 및 복합 정책에 대해 시뮬레이션한 다음 500M 명령어를 평가한다. gem5 시뮬레이터(24)에서, 각각의 벤치마크는 태그 또는 정책없이 베이스라인 프로세서상에서 실행된다. 그런 다음 결과로 생긴 명령 트레이스(26)는 각 명령어에 대해 메타데이터 계산을 수행하는 PUMP 시뮬레이터(28)를 통해 실행된다. 이러한 "단계적(phased)" 시뮬레이션 전략은 PUMP의 결과가 프로그램의 제어 흐름을 그의 베이스라인 실행으로부터 벗어나게 할 수 없는 고장-정지 정책에 대해 정확하다. 어드레스-트레이스 시뮬레이션은 고도로 파이프라인화되고 비순차적인 프로세서에 대해 정확하지 않을 수 있지만, 간단하고 순차적인 5-스테이지 및 6-스테이지 파이프라인에 대해서는 매우 정확하다. 베이스라인 구성에서, gem5 명령어 시뮬레이션 및 어드레스 트레이스 발생(30)에 뒤이은 어드레스 시뮬레이터(32)에서의 커스톰 어드레스 트레이스 시뮬레이션 및 카운팅은 gem5의 사이클-정확도 시뮬레이션의 1.2 % 이내였다.
PUMP 시뮬레이터(28)는 각 정책을 구현하는 미스-핸들러 코드(C로 작성됨)를 포함하고, 메타데이터 태그는 정책에 따라 초기 메모리 상에 할당된다. PUMP 시뮬레이터(28)는 PUMP(10) 규칙 캐시 내의 액세스 패턴을 포착하고 L2 규칙 캐시에 액세스하는데 요구되는 더 긴 대기 사이클을 감안하여 연관된 런타임 및 에너지 비용을 추정한다. 미스 핸들러 코드를 갖는 PUMP 시뮬레이터(28)가 또한 프로세서상에서 실행되기 때문에, gem5상의 미스 핸들러에 대해 별도의 시뮬레이션을 수행하여 동적 거동을 포착한다. 미스-핸들러 코드는 잠재적으로 데이터 및 명령어 캐시에 영향을 미치기 때문에, 사용자 및 미스-핸들러 코드 둘 모두로부터 적절히 인터리빙된 메모리 액세스를 포함하는 병합된 어드레스-트레이스가 생성되는데, 이는 메모리 시스템의 성능 영향을 평가하는 최종 어드레스-트레이스 시뮬레이션에 사용된다.
다음 단락에서, PUMP 없는 베이스라인과 비교하여 간단한 PUMP 구현의 평가가 제공된다.
하나의 평가 포인트로서, 베이스라인 프로세서 외에 PUMP(10)의 전체 영역 오버헤드는 190 %(도 16의 테이블 3 참조)라는 것을 유의하여야 한다. 이러한 영역 오버헤드 중 주요한 부분(110 %)은 PUMP(10) 규칙 캐시에서 비롯된다. 단일화된 L2 캐시는 나머지 영역 오버헤드의 대부분의 원인이 된다. L1 D/I 캐시는 그의 유효 용량이 반으로 줄어들기 때문에 대략 동일하게 유지된다. 이렇게 높은 메모리 영역 오버헤드는 정적 전력을 대략 세 배로 늘리기에, 에너지 오버헤드의 24 %의 원인이 된다.
또 다른 평가 포인트는 런타임 오버헤드와 관련이 있다. 대부분의 벤치마크에서 모든 단일 정책의 경우, 이러한 간단한 구현의 평균 런타임 오버헤드는 단지 10 %이다(도 3a 및 도 3b 참조; 박스플롯을 읽으려면: 막대는 중간 값이고, 박스는 위와 아래의 1/4 분위를 차지하고(건수의 중간 50 %), 점은 각 개개의 데이터 포인트를 나타내며, 위스커(whisker)는 아웃 라이어를 제외한 전체 범위(각각의 사분위수 1.5x초과)를 나타내며, 주요한 오버헤드는 프로세서에 및 프로세서로부터 태그 비트를 전송하는데 필요한 추가 DRAM 트래픽으로부터 나온다). 메모리 안전 정책(도 3a 및 도 3b)에 대해, 새로 할당된 메모리 블록에서 강제 미스로 인해 총 오버헤드를 40 내지 50 %까지 밀어 올리는 높은 미스 핸들러 오버헤드를 보이는 몇 가지 벤치마크가 있다. 복합 정책 런타임(도에서 "CPI" 또는 "CPI 오버헤드"라고 표기됨)의 경우, 벤치마크 중 다섯 개가 미스 핸들러에서 매우 높은 오버헤드를 겪고 있고(도 4a 참조), 최악의 경우 GemsFTDT에서는 780 %에 가깝고 geomean에서는 50 %에 이른다. 도 4b에 도시된 복합 정책 에너지(도면에서 "EPF" 또는 "EPI 오버헤드"로 표기됨)의 경우, 벤치마크 중 세 개(예를 들어, GemsFTDT, astar, omnetpp)는 미스 핸들러에서 매우 높은 오버헤드를 겪으며, 최악의 경우 GemsFTDT에서는 1600 %, astar에서는 600 %, 그리고 omnetpp에서는 520 %에 가깝다).
이러한 오버헤드의 원인이 되는 두 가지 인자는: (1) 최종 레벨 규칙 캐시 미스를 해결하는데 요구되는 많은 수의 사이클(모든 컴포넌트 미스 핸들러가 참고되기 때문임) 및 (2) 작업 세트 크기를 확장하고 규칙 캐시 미스 레이트를 증가시키는 규칙 수의 폭증이다. 최악의 경우, 고유한 복합 태그의 수는 각 컴포넌트 정책에 있는 고유 태그의 결과물일 수 있다. 그러나 전체 규칙은 최대 단일 정책인 메모리 안전에 비해 3x 내지 5x 배만큼 증가한다.
평가의 또 다른 포인트는 에너지 오버헤드이다. 더 넓은 워드로 인해 더 많은 비트를 이동시키는 것 및 미스 핸들러 코드로 인해 더 많은 명령어를 실행하는 것 둘 모두는 에너지 오버헤드의 원인이 되어, 단일 정책 및 복합 정책에 모두 영향을 미친다(도 3b 및 도 4b). CFI 및 메모리 안전 정책 - 및 이에 따른 복합 정책 - 은 에너지 비용이 드는 DRAM 액세스를 종종 요구하는 대용량 데이터 구조체에 액세스한다. 최악의 경우의 에너지 오버헤드는 단일 정책의 경우 400 %에 가까우며, 복합 인스턴스 정책의 경우 약 1600 %이고, geomean 오버헤드는 약 220 %이다.
많은 플랫폼 설계에서, 최악의 경우의 전력 또는 등가적으로 사이클 당 에너지는 제한 기준(limiter)이다. 플랫폼이 배터리로부터 인출할 수 있는 최대 전류 또는 주변의 냉각을 이용하는 모바일 또는 유선 디바이스에서 최대 지속 동작 온도로 인해 이러한 전력 상한이 돌진될 수 있다. 도 4c는 간단한 구현이 lbm을 사용하여 최대 전력 상한을 76 %만큼 올려 베이스라인 구현 및 간단한 PUMP 구현 둘 모두에서 최대 전력에 돌진하는 것을 도시한다. 이러한 전력 상한의 증가는 최악의 경우의 에너지 오버헤드 보다 부분적으로 더 낮은데, 왜냐하면 일부 벤치마크는 이들이 소비하는 여분의 에너지보다 느려지기 때문이고 그리고 높은 에너지 오버헤드를 가진 벤치마크는 베이스라인 설계에서 사이클 당 최소 절대 에너지를 소비하는 것들이기 때문이라는 것을 유의하여야 한다. 전형적으로 이러한 에너지-효율적 프로그램의 데이터 작업 세트는 온-칩 캐시에 적합하며, 그래서 DRAM 액세스의 비용보다 더 많이 드는 경우는 거의 없다.
위에서 설명된 전술한 구현을 포함하는 실시예는 대부분의 벤치마크에서 합당한 성능을 달성하고, 벤치마크 중 일부에서 복합 정책에 대한 런타임 오버헤드 및 모든 정책과 벤치마크에서 에너지 및 전력 오버헤드는 허용할 수 없을 정도로 높은 것 같다. 이러한 오버헤드를 해결하기 위해, 일련의 목표로 삼은 마이크로아키텍처 최적화가 도입될 수 있고 본 명세서에서의 기술에 따른 실시예에 통합될 수 있다. 도 17의 테이블 4에서, 이러한 최적화는 전체 비용에 미치는 PUMP 컴포넌트와 연관된 아키텍처 파라미터의 영향에 대해 검사된다. 규칙이 동일한 opcode들을 그룹화하면 PUMP 규칙 캐시의 유효 용량, DRAM 이전의 지연 및 에너지를 줄이는 태그 압축, 온-칩 메모리의 면적 및 에너지를 줄이는 짧은 태그, 및 미스 핸들러의 오버헤드를 감소시키는 일원화된 컴포넌트 정책(Unified Component Policy)(UCP) 및 복합 태그(Composition Tag)(CTAG) 캐시를 증가시키는데 사용된다.
이제 설명되는 것은 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 "opgroup"이다. 실용적인 정책에서는 여러 opcode에 대해 유사한 규칙을 정의하는 것이 일반적이다. 예를 들어, 테인트 추적 정책에서, Add 및 Sub 명령어에 대한 규칙은 동일하다(도 19의 알고리즘 1 참조). 그러나 간단한 구현에서, 이러한 규칙은 규칙 캐시에서 별도의 엔트리를 차지한다. 이러한 관찰에 기초하여, 명령어 연산 코드("opcode")는 동일한 규칙이 "opgroups"으로 그룹화되어 필요한 규칙 수를 줄이다. 함께 그룹화될 수 있는 opcode는 정책에 따라 다르고; 그러므로 "돈-케어" SRAM이 실행 스테이지(18)(도 1)에서 확장되어 규칙 캐시 룩업에 앞서 opcode를 opgroup으로 또한 변환한다. 복합 정책의 경우, 300 개가 넘는 알파(Alpha) opcode가 14 개 opgroup으로 줄어들고, 전체 규칙 수는 평균 1.5x로 1.1x 내지 6x 배만큼 줄어든다(도 5a는 이러한 영향을 모든 SPEC 벤치마크에 걸쳐 측정한다). 이것은 실리콘 영역에서 주어진 투자에 대한 규칙 캐시 용량을 효과적으로 증가시킨다. 그룹 내 단일 명령어에 대한 미스는 그룹 내 모든 명령어 opcode에 적용하는 규칙을 설치하기 때문에 opgroup은 강제 미스의 수를 또한 줄인다. 도 5b는 opgroup화할 때와 하지 않을 때 복합 정책에 대해 서로 다른 L1 규칙 캐시 크기에 대한 모든 SPEC 벤치마크 전반의 미스 레이트를 요약한 것이다. 도 5b는 opgrouping에 의해 미스 레이트의 범위 및 평균 둘 모두가 감소함을 보여준다. 특히, opgroup 최적화 이후 1024 엔트리 규칙 캐시는 최적화 없는 4096 엔트리 규칙 캐시보다 낮은 미스 레이트를 갖는다. 더 낮은 미스 레이트는 미스 핸들러에서 소비되는 시간과 에너지를 자연스럽게 줄여 주며(도 12a 및 도 12b 참조) 더 작은 규칙 캐시는 면적과 에너지를 직접 줄여준다.
본 명세서에서의 기술에 따른 실시예는 이제 설명될 메인 메모리 태그 압축을 이용할 수 있다. 64b 워드에 64b 태그를 사용하면 오프-칩 메모리 트래픽이 두 배로 늘어나 연관된 에너지가 거의 두 배로 된다. 전형적으로, 태그는 공간적 지역성을 나타내지만 - 많은 인접한 워드는 동일한 태그를 갖는다. 예를 들어, 도 6a는 복합 정책에 따른 gcc 벤치마크의 각 DRAM 이전에 대한 고유 태그 분포를 도표로 구성한 것으로, 대부분의 워드가 동일한 태그를 갖는다는 것을 보여주며; 평균적으로 8-워드 캐리 라인의 DRAM 이전 당 고유 태그는 단지 약 1.14 개이다. 이러한 공간 태그 지역성은 오프-칩 메모리로 및 오프-칩 메모리로부터 이전되어야 하는 태그 비트를 압축하는데 이용된다. 데이터는 캐시 라인에서 이전되기 때문에, 캐시 라인은 이러한 압축의 기초로서 사용된다. 어드레스 특정을 간단하게 하기 위해, 캐시 라인 당 128B가 메인 메모리에 할당된다.
그러나, 128b 태깅된 워드를 직접 저장하는 대신 도 6b에 도시된 바와 같이, 여덟 개의 64b 워드(페이로드)가 저장되고, 이어서 여덟 개의 4b 인덱스, 그런 다음 최대 여덟 개의 60b 태그가 저장된다. 인덱스는 60b 태그 중 어느 것이 연관된 워드와 어울리는지를 식별한다. 태그는 인덱스를 수용하기 위해 60b로 잘리지만, 이것은 태그를 포인터로서 사용하는 것을 훼손하지 않는다: 바이트 어드레스 지정 및 16B(두 개의 64b 워드) 정렬된 메타데이터 구조체를 가정하면, 64b 포인터의 하위 4b는 0으로 채워질 수 있다. 결과적으로, 인덱스의 4B를 전송한 후, 남은 모든 것은 캐시 라인에서 고유한 7.5B 태그를 이전해야 한다. 예를 들어, 캐시 라인의 모든 워드가 동일한 태그를 사용하면, 첫 번째 판독에서는 64B+4B = 68B가 이전되고, 두 번째 판독에서는 8B가 이전되어 128B 대신 총 76B가 이전된다. 4b 인덱스는 직접 인덱스이거나 특수 값일 수 있다. 디폴트 태그를 나타내는 특수 인덱스 값이 정의되어, 그래서 이 경우에는 임의의 태그를 전송할 필요가 없게 한다. 이러한 방식으로 태그를 압축함으로써, DRAM 전송 당 평균 에너지 오버헤드가 110 %에서 15 %로 줄어든다.
위에서 제시된 압축 방식은, 예를 들어, 오프-칩 메모리 에너지를 줄일 때 단순성 및 유효성의 조합으로 인해, 본 명세서에서의 기술에 따른 실시예에서 이용될 수 있다. 관련 기술분야에서 통상의 기술자라면 다중 레벨 태그 페이지 테이블, 가변적 세밀화된 TLB-유사 구조체(TLB-like structure) 및 범위 캐시를 비롯한 미세 세밀화된 메모리 태깅을 위한 추가적이고 대안적인 정교한 방식이 존재한다는 것 및 이것들은 본 명세서에서의 기술에 따른 실시예에서 DRAM 풋 프린트를 줄이는데 사용될 수도 있다는 것을 명확히 인식한다.
이제 태그 변환이 본 명세서에서의 기술에 따른 실시예에서 수행될 수 있는 방법이 설명될 것이다. 도 1을 다시 참조하면, 각각의 캐싱된 규칙은 456b 폭이기 때문에 간단한 PUMP 규칙 캐시에게는 크다(110 % 영역 추가). PUMP(10)을 지원하려면 베이스라인 온-칩 메모리(RF 및 L1/L2 캐시)를 64b태그로 확장하는 것이 필요했다. 여기서 각 64b 워드에 대해 전체 64b(또는 60b) 태그를 사용하면 밀집 영역과 에너지 오버헤드를 유발한다. 그러나, 64KB L1-D$는 단지 8192 워드만을 수용하며 이에 따라 많아 봐야 8192 개 고유 태그를 보유한다. 64KB L1-I$와 함께, L1 메모리 서브시스템에서는 많아야 16384 개 고유 태그가 있을 수 있고; 이것들은 단지 14b 태그로 표현되어, 시스템에서 지연, 면적, 에너지 및 전력을 줄일 수 있다. 캐시(L1, L2)는 시간적 지역성을 이용하기 위해 존재하며, 이러한 관찰은 지역성이 면적 및 에너지를 줄이는데 적극 활용될 수 있음을 시사한다. 태그 비트가 14b로 줄어들면, PUMP 규칙 캐시 매치 키는 328b에서 78b로 줄어든다.
전체 포인터-크기 태그의 유연성을 잃지 않으면서 전술한 절감의 장점을 획득하기 위해, 상이한-폭 태그(different-width tag)가 상이한 온-칩 메모리 서브시스템에 사용되어 필요할 때 이들 사이에서 변환될 수 있다. 예를 들어, L1 메모리에서 12b 태그를 사용하고 L2 메모리에서 16b 태그를 사용할 수 있다. 도 7a는 L1 및 L2 메모리 서브시스템들 사이에서 수행될 수 있는 태그 변환을 상세히 도시한다. L2 캐시(34)로부터 L1 캐시(36)로 워드를 이동하려면 그의 16b 태그를 대응하는 12b 태그로 변환하여, 필요하다면 새로운 연관성을 생성할 것을 요구한다. L2-태그-대-L1-태그 변환을 위한 간단한 SRAM(38)은 L2 태그에 대한 L1 매핑이 존재하는지를 나타내는 여분의 비트를 갖는다. 도 7b는 L1 태그를 어드레스로 사용하여 SRAM(39) 룩업이 수행된 (라이트백 또는 L2 룩업시) L1 태그(40)로부터 L2 태그(42)로의 변환을 상세하게 도시한다. 유사한 변환은 60b 메인 메모리 태그와 16b L2 태그 사이에서 발생한다.
장단(long-to-short) 변환 테이블에 긴 태그가 없을 때, 새로운 짧은 태그가 할당되어, 더 이상 사용되지 않는 이전에 할당된 짧은 태그를 잠재적으로 되돌릴 수 있다. 가비지 콜렉션(garbage collection) 및 태그-사용 계산(tag-usage counting)을 비롯하여 짧은 태그를 되돌릴 수 있는 때를 결정할 수 있는 풍부한 설계 공간이 있다. 간략화를 위해, 짧은 태그가 순차적으로 할당되고 짧은 태그 공간이 모두 소모될 때 특정 레벨(명령어, 데이터 및 PUMP) 이상의 모든 캐시를 플러시(flush)하여, 특정한 짧은 태그가 되돌려질 수 있는 때를 추적할 필요성을 회피한다. 캐시는 캐시 플러시를 저렴하게 만드는 적합한 기술로 설계될 수 있다. 예를 들어, 본 명세서에서의 기술에 따른 실시예에서, 모든 캐시는 예컨대 관련 기술분야에서 공지되어 있고, 예를 들어 문헌(K. Mai, R. Ho, E. Alon, D. Liu, Y. Kim, D. Patil, M. Horowitz, Architecture and Circuit Techniques for a 1.1GHz 16-kb Reconfigurable Memory in 0.18um-CMOS, IEEE J. Solid-State Circuits, 40(l):261-275, January 2005)에서 설명된 광파장 갱 클리어(lightweight gang clear)로 설계될 수 있으며, 이 문헌은 본 출원에서 참조로 포함된다.
각 L1 규칙 캐시 액세스 비용이 51pJ가 드는 경우, (도 16에서 재현된) 테이블 3과 비교하여, 본 명세서에서의 기술은 8b L1 태그를 갖는 10pJ 또는 16b L1 태그를 갖는 18pJ로 떨어지는 감소를 제공하고, 에너지는 이들 포인트 사이의 태그 길이에 따라 선형적으로 크기 조정된다. L1 명령어 및 데이터 캐시에 미치는 에너지 영향은 작다.
마찬가지로, 16b L2 태그를 사용하면, L2 PUMP 액세스 비용은 120pJ이고 64b 태그를 사용하는 173pJ보다 낮다. L1 태그를 슬림화하면 L1 캐시의 용량을 복원할 수 있다. 12b 태그를 사용하면, 전체 용량(76KB, 유효 64KB) 캐시는 단일 사이클 타이밍 요건을 충족할 것이므로, L1 캐시 용량이 줄어듦으로써 간단한 구현에 초래되는 성능 불이익이 줄어들 것이다. 결과적으로 L1 태그 길이 조사는 12 비트 이하로 제한된다. 심지어 태그가 더 짧아지면 에너지가 줄어들지만, 더 짧은 태그는 플러시의 빈도를 증가시킨다.
도 8a 및 도 8b는 L1 태그 길이가 늘어남에 따라 어떻게 플러시가 감소하는지에 관한 것뿐만 아니라, L1 규칙 캐시 미스 레이트에 미치는 영향을 도시한다.
이제는 미스 핸들러 가속화와 관련하여 사용될 수 있는 다양한 기술이 설명될 것이다. 본 명세서에서의 기술에 따른 실시예는 네 개의 정책을 단일의 복합 정책으로 조합할 수 있다. 도 20을 참조하면, 알고리즘 2에서, N-정책 미스 핸들러의 각각의 호출은 태그들의 튜플을 분해해야 하고, 복합 정책에 필요한 규칙은 도 9a에서 식별되는 규칙 캐시 미스 레이트를 증가시킨다. 테인트 추적 및 CFI 정책은 개별적으로 낮은 미스 레이트를 가질지라도, 메모리 안전 정책으로 생긴 더 높은 미스 레이트는 복합 정책의 미스 레이트를 마찬가지로 높게 몰고 간다. 개개의 정책의 미스 레이트가 더 낮다는 것은 복합 규칙이 없을 때에도 미스 레이트의 결과가 캐싱 가능하다는 것을 시사한다.
도 23에 도시된 바와 같은 PUMP 마이크로아키텍처의 다양한 양상과 관련하여, 복합 정책 미스 처리(composite policy miss handling)를 최적화하기 위해 하드웨어 구조체가 이용될 수 있다. 본 명세서에서의 기술에 따른 실시예는 가장 최근의 컴포넌트 정책 결과가 캐싱되는 단일화된 컴포넌트 정책(Unified Component Policy)(UCP; 도 21의 알고리즘 3 참조) 캐시(UCP $)를 이용할 수 있다. 이러한 실시예에서, 복합 정책에 필요한 일반적인 미스-핸들러는 컴포넌트 정책(예를 들어, 도 21의 알고리즘, 라인 3에서의 정책 참조)을 해결하면서 이 캐시에서 룩업을 수행하도록 수정된다. 이 캐시가 컴포넌트 정책에 대해 미스를 발생할 때, 이 캐시의 정책 계산은 소프트웨어에서 수행된다(그리고 결과는 이 캐시에 삽입된다).
도 24에서도 또한 도시된 바와 같이, UCP 캐시는 정책 식별자 필드가 추가되는, 정규 PUMP 규칙 캐시와 동일한 하드웨어 구성으로 구현될 수 있다. FIFO 대체 정책은 이 캐시에 사용될 수 있지만, 컴포넌트 정책에 대한 재 계산 비용과 같은 메트릭을 사용하여 공간의 우선 순위를 정함으로써 더 나은 결과를 달성하는 것이 가능하다. 이 캐시는 보통의 용량으로 대부분의 정책 재-계산을 걸러낸다(도 9Bb; 새로운 메모리 할당과 연관된 강제 미스(compulsory miss)로 인해 메모리 안전에 대한 히트 레이트(hit rate)는 낮아진다). 결과적으로, 평균 미스 핸들러 사이클 수는 가장 까다로운 벤치마크에 대해 5배만큼 줄어든다(도 9e). 필요한 복합 규칙은 적은 수의 컴포넌트 정책 규칙의 결과물일 수 있기 때문에 L2 PUMP에서 미스가 있을 때 모든 정책이 UCP 캐시에서 히트할 가능성이 있다. GemsFDTD의 경우, 세 개 이상의 컴포넌트 정책이 시간 중 약 96 %를 히트했다.
도 23과 도 24에 또한 도시된 바와 같이, 캐시는 결과 태그들의 튜플을 그의 표준 복합 결과 태그로 변환하기 위해 추가될 수 있다. 전술한 캐시는 몇몇 컴포넌트 정책 룰이 결과 태그들의 동일한 튜플을 리턴하는 것이 일반적이기 때문에 사실상의 복합 태그(CTAG) 캐시(CTAG $)(도 9D)라고 지칭될 수 있다. 예를 들어, 결과 태그가 상이할지라도, 대부분의 경우 PCtag는 동일할 것이다. 또한, 많은 상이한 규칙 입력은 동일한 출력으로 이어질 수 있다. 예를 들어, 테인트 추적 세트에서, 합집합이 수행되고, 많은 상이한 합집합이 동일한 결과를 가질 것이다; 예를 들어, (Blue, {A, B, C})는 {A} U {B, C} 및 {A, B} U {B, C}(테인트 추적) 둘 모두의 결과를 Blue 슬롯(메모리 안전)에 기입하기 위한 복합 답변이다. FIFO 대체 정책은 이 캐시에 사용된다. CTAG 캐시는 평균 미스 핸들러 사이클을 또 다른 2배만큼 줄어든다(도 9e 참조).
2048 엔트리의 UCP 캐시와 512 엔트리의 CTAG 캐시가 함께 사용되면 각 L2 규칙 캐시 미스에 소모되는 평균 시간을 800 사이클에서 80 사이클로 줄인다.
본 명세서에서의 기술에 따른 실시예는 또한 규칙을 포함하는 하나 이상의 캐시에 저장되는 하나 이상의 규칙을 프리페치(prefetch)함으로써 성능을 개선할 수 있다. 따라서 가까운 장래에 필요할 수 있는 선계산 규칙(precompute rule)을 사용하여 강제 미스 레이트를 줄일 수도 있다. 예시적인 인스턴스는 메모리 안전 규칙에 대해 높은 값을 갖는다. 예를 들어, 새로운 메모리 태그가 할당될 때, 새로운 규칙은 그 태그에 대해 (초기화 (1), 포인터에 오프셋 추가 및 무브(move) (3), 스칼라 로드(scalar load) (1), 스칼라 저장(scalar store) (2))을 해야 할 것이다. 그 결과, 이러한 규칙은 모두 UCP 캐시에 즉시 추가될 수 있다. 단일 정책 메모리 안전 사례의 경우, 규칙은 규칙 캐시에 직접 추가될 수 있다. 이렇게 하면 메모리 안전 미스 핸들러 호출 수가 2x 배 줄어든다.
전체 평가와 관련하여 도 11a를 참조하면, 아키텍처 파라미터는 특정 비용에 단조적으로 영향을 주어 에너지, 지연 및 면적 사이의 상쇄관계를 제공하지만, 단일 비용 기준 내에서 최소한도를 정의하지는 않는다. 일단 태그 비트가 충분히 작아지면, L1 D/I 캐시는 베이스라인 용량으로 복원될 수 있어서, 베이스라인이 L1 태그 길이를 탐구하는 상한선으로 채택되는 문턱 효과가 있지만, 그 포인트를 넘어 태그 길이가 줄어들면 성능에 미치는 영향이 작으면서 에너지가 줄어든다.
도 11b는 태그 길이를 감소시키는 것이 대부분의 벤치마크 프로그램에 대해 우세한 에너지 효과가 있고(예를 들어, Ieslie3d, mcf), 몇몇 프로그램이 UCP 캐시 용량의 증가에 따라 동일하거나 더 큰 이득을 보이는 것(예를 들어, GemsFDTD, gcc)을 도시한다. 다른 비용 문제를 무시하고, 에너지를 줄이기 위해, 큰 미스 핸들러 캐시 및 몇 개의 태그 비트가 선택된다. 런타임 오버헤드(도 11a 참조)는 또한 더 큰 미스 핸들러 캐시를 사용하여 최소화되지만, 태그 비트 수가 적은 것보다는 오히려 많은 것이 이득이 있다(예를 들어, GemsFDTD, gcc).
이득의 규모는 벤치마크와 정책에 따라 달라진다. 모든 벤치마크를 통해, SPEC CPU2006 벤치마크의 경우 10b L1 태그를 능가하는 장점은 작기 때문에, 10b는 에너지와 지연 사이의 절충안으로 사용되며 2048-엔트리 UCP 캐시 및 512-엔트리 CTAG 캐시를 사용하여 탐구된 아키텍처 파라미터의 공간 내의 최소 에너지 레벨에 근접하면서 오버헤드를 줄인다.
도 12a 및 도 12b는 최적화를 적용하는 런타임 및 에너지 오버헤드에 미치는 전반적인 영향을 도시한다. 모든 최적화는 일부 벤치마크에서 우세하고(예를 들어, astar에 대해서는 opgroup, lbm에 대해서는 DRAM 태그 압축, h264ref에 대해서는 짧은 태그, GemsFDTD에 대해서는 미스 핸들러 가속), 각각의 최적화는 연속하여 하나의 병목을 제거하고 다음 병목을 드러낸다. 벤치마크와 상이한 거동은 아래에 상세히 설명된 대로 베이스라인 특성을 따른다.
지역성이 낮은 애플리케이션은 높은 메인 메모리 트래픽으로 인해 DRAM에 의해 주도되는 기본 에너지 및 성능을 갖는다. 이러한 벤치마크에서의 오버헤드(예를 들어, lbm)는 DRAM 오버헤드 경향이므로, DRAM 오버헤드의 감소는 런타임 및 에너지 오버헤드에 직접적인 영향을 준다. 지역성이 더 많은 애플리케이션은 베이스라인 구성에서 더 빠르고, 에너지를 덜 소비하고, DRAM 오버헤드를 덜 겪으며; 결과적으로, 이러한 벤치마크는 L1 D/I 및 규칙 캐시에서 감소된 L1 용량 및 태그 에너지 감소로 인해 더 심하게 영향을 받는다. DRAM 최적화는 이러한 애플리케이션에 미치는 영향이 적지만, 짧은 태그를 사용하면 에너지에 큰 영향을 미치고 L1 D/I 캐시 용량 불이익을 제거한다(예를 들어, h264ref).
동적 메모리 할당이 많은 벤치마크에서는 새로 생성된 태그가 캐시에 설치되어야 하므로 강제 미스로 인해 L2 규칙 캐시 미스 레이트가 더 높아진다. 이것은 간단한 구현에서 여러 벤치마크에 대해 높은 오버헤드를 주도했다(GemsFDTD, omnetpp). 본 출원에서 설명되는 미스 핸들러 최적화는 이러한 미스의 일반적 사례의 비용을 줄여주고, opgroup 최적화는 용량 미스 레이트(capacity miss rate)를 줄여준다. 간단한 구현에 대해, GemsFDTD는 매 200개 명령어마다 L2 규칙 캐시 미스를 일으켰고 780 % 런타임 오버헤드의 대부분을 주도하는 각 미스를 처리하기 위해 800 사이클을 사용했다(도 4a 참조). 최적화에 따르면, GemsFDTD 벤치마크는 매 400개 명령어마다 L2 규칙 캐시 미스를 서비스하고 미스 당 평균 140 사이클만 사용하여, 런타임 오버헤드를 약 85 %까지 줄여준다(도 10a 참조).
전반적으로, 이러한 최적화는 메모리 할당이 높은 GemsFDTD 및 omnetpp를 제외한 모든 벤치마크에 대해 런타임 오버헤드를 10 % 아래로 내린다(eh 10a 참조). 평균 에너지 오버헤드는 60 %에 가깝고, 단지 네 개의 벤치마크만이 80 %를 초과한다(도 10b 참조).
설명하자면, PUMP의 성능 영향은 여러 방식으로 PUMP를 강조하고 다양한 보안 특성 범위를 예시하는 네 개의 상이한 정책: (1) 태그를 사용하여 코드를 메모리의 데이터와 구별하고 단순 코드 주입(simple code injection) 공격으로부터 보호를 제공하는 실행 불가 데이터 및 기입 불가 코드(Non-Executable Data and Non-Writable Code)(NXD+NWC) 정책; (2) 유효하게 무한 (260) 수의 컬러("테인트 마크")으로 확장되는, 힙-할당된 메모리(heap-allocated memory)의 모든 공간적 및 시간적 위반을 검출하는 메모리 안전 정책; (3) 간접 제어 이전(indirect control transfer)을 프로그램의 제어 흐름 그래프에서 허용된 에지만으로 제한하여, 리턴 지향 프로그래밍 스타일의 공격을 방지하는 제어 흐름 무결성(CFI) 정책(미세 세밀화된 CFI를 시행하지만, 잠재적으로 공격에 취약 가능성 있는 저급으로 근사화한 것은 제외함); (4) 각 워드가 동시에 다수의 소스(라이브러리 및 10 스트림)에 의해 잠재적으로 오염될 수 있는 미세 세밀화된 테인트 추적 정책(일반화) 복합을 사용하여 측정할 수 있다(도 14의 테이블 1 참조). 본 출원의 다른 곳에서 언급한 바와 같이, 이러한 것들은 보호 능력이 본 출원의 문헌에서 확립되어있는 공지된 정책이고 본 명세서에서의 설명은 PUMP를 사용하여 이를 시행하는데 미치는 성능 영향을 측정하고 줄이는데 중점을 둔다. NXD+NWC를 제외하고, 이들 정책 각각은 근본적으로 제한되지 않는 수의 고유 아이템을 구별하며; 이에 반해, 메타데이터 비트 수가 제한된 해결책은 기껏해야 극도로 단순하게 근사화된 것만을 지원할 수 있다. 위에서 또한 언급했듯이, PUMP의 간단하고 직접적인 구현은 비용이 많이들 수 있다. 예를 들어, 포인터-크기(64b) 태그를 64b 워드에 추가하면 시스템의 모든 메모리 크기와 에너지 사용량을 최소한 두 배로 만들며; 규칙 캐시에는 이것 외에 영역과 에너지가 추가된다. 이러한 간단한 구현의 경우, 측정된 면적 오버헤드는 약 190 %이고 기하학적 의미의 에너지 오버헤드는 약 220 %이고; 더욱이, 일부 애플리케이션에서 런타임 오버헤드는 실망스럽다(300 % 이상). 이러한 높은 간접비가 행할 수 있는 최선의 것이라면 채택을 좌절시킬 것이다.
본 명세서에서 설명된 것과 같은 마이크로-아키텍처 최적화는 본 명세서에서의 기술에 따른 실시예에 포함되어 전력 한도를 10 % 줄일 수 있어(도 10c 참조), 최적화된 PUMP는 플랫폼의 동작 엔벨로프에 거의 영향을 미치지 않음을 시사한다. DRAM 압축은 lbm의 경우 에너지 오버헤드를 20 % 줄이며; 이것은 또한 9 %만큼 느려지므로, 전력 요구량은 단지 10 %만큼 증가한다.
최적화된 설계의 면적 오버헤드는 단순한 설계의 190 %(예를 들어, 도 16의 테이블 3 참조)와 비교하여 약 110 %(예를 들어, 도 18의 테이블 5 참조)이다. 짧은 태그는 L1 및 L2 캐시의 면적(지금은 베이스라인보다 5 % 만 추가됨) 및 규칙 캐시의 면적(26 % 만 추가됨)을 상당히 줄이다. 반대로, 최적화된 설계는 런타임 및 에너지 오버헤드를 줄이는데 약간의 면적을 소비한다. UCP 및 CTAG 캐시는 33 %의 영역 오버헤드를 추가하는 반면, 짧은 태그(L1 및 L2 모두)를 위한 변환 메모리는 또 다른 46 %를 추가한다. 이러한 추가적인 하드웨어 구조체는 면적을 추가하지만, 드물게 액세스되고 UCP 및 CTAG 캐시로 인해 미스 핸들러 사이클이 의미 있게 줄어들기 때문에, 순수 에너지 감소를 제공한다.
본 명세서에 설명된 모델 및 최적화의 한 가지 목표는 동시에 시행되는 추가 정책을 추가하는 실시예를 상대적으로 간단하게 만드는 것이다. 간단한 PUMP 설계의 복합 정책은 미스 핸들러 런타임이 크게 증가하여 여러 벤치마크에 대해 증분 비용의 이상의 비용을 초래하였지만, 이것들은 미스 핸들러 최적화로 인해 줄어든다.
도 13a(CPI 오버헤드)과 도 13b(EPI 오버헤드)는 각각의 단일 정책의 오버헤드를 먼저 보여준 다음, 정책을 가장 복잡한 단일 정책인 메모리 안전에 추가하는 복합을 보여줌으로써 정책의 증분적인 추가가 런타임 오버헤드에 어떻게 영향을 미치는지를 도시한다. 이 진행은 더 높은 오버헤드 정책을 추가하는 것과 대조적으로 임의의 정책의 단순한 추가로 인해 무슨 오버헤드가 비롯되는지를 명확하게 해준다. 여기서 네 가지 정책을 넘어서는 확장성을 얻기 위해, CFI 정책(리턴(return) 및 계산된-점프/호출(computed-jump/call)) 및 테인트 추적 정책(코드 테인팅(code tainting 및 I/O 테인팅(I/O tainting))은 각각 두 부분으로 나누어진다. 추가 정책의 런타임 오버헤드가 최초의 복잡한 정책(메모리 안전)보다 점차 늘어남을 추적하는 것이 도시되는데, 이때 비-이상치(non-outlier)에 미치는 주목할만한 런타임은 없고(최악의 비-이상치는 9 %에서 10 % 오버헤드로 상승함), 주로 미스 핸들러 해결 복잡성 증가로 인해 각각의 새로운 종류의 정책이 추가되기 때문에 두 개의 이상 치에서 더 크게 증가한다(20 내지 40 %). 에너지는 GemsFDTD를 제외한 모든 것을 감안하는 비-이상치 정책에 미치는 영향이 보통 정도인 유사한 추세를 따른다(geomean은 60 %에서 70 %로 증가한다).
관련 동작에 관한 간략한 요약은 도 15에서 재현된 테이블 2에서 확인된다.
본 명세서에서의 기술에 따른 정책 프로그래밍 모델에 따르면, PUMP 정책은 태그 값들의 세트와 함께, 이들 태그들을 조작하여 원하는 태그 전파(tag propagation) 및 시행 메커니즘을 구현하는 규칙들의 모음을 포함한다. 규칙은 두 개의 형태: 시스템의 소프트웨어 계층(상징적 규칙) 또는 하드웨어 계층(구체적인 규칙)로 비롯된다.
예를 들어, PUMP의 동작을 설명하기 위해, 프로그램 실행 중에 리턴 포인트를 제한하는 간단한 예제 정책을 고려한다. 이 정책의 동기는 리턴 지향 프로그래밍(return-oriented programming)(ROP)으로 알려진 공격 부류에서 비롯되는데, POP에서, 공격자는 공격 받는 프로그램의 이진 실행 파일에서 "가젯(gadget)"들의 세트를 식별하고 이를 사용하여 적절한 스택 프레임들의 시퀀스 - 각 스택 프레임에는 일부 가젯을 가리키는 리턴 어드레스가 담겨 있음 - 를 구축함으로써 복잡한 악의적인 거동을 모으며; 그러면 버퍼 오버플로우 또는 다른 취약점이 악용되어 스택의 상단을 원하는 시퀀스로 오버라이팅함으로써, 스니핏(snippet)을 순서대로 실행되게 한다. ROP 공격을 제한하는 하나의 간단한 방법은 리턴 명령어의 타깃을 잘 정의된 리턴 포인트로 제한하는 것이다. 이것은 PUMP를 사용하여 메타데이터 태그 타깃이 있는 유효한 리턴 포인트인 명령어에 태깅함으로써 수행된다. 리턴 명령어가 실행될 때마다, PC상의 메타데이터 태그는 리턴이 방금 발생했는지를 표시할 것을 체크하도록 설정된다. 다음 명령어에서, PC 태그가 체크되고 현재 명령어 상의 태그가 타깃인지를 검증하고, 그렇지 않으면 보안 위반을 신호한다. 메타데이터를 더 풍부하게 만듦으로써, 어떤 리턴 명령어가 어떤 리턴 포인트로 리턴할 수 있는지를 정확하게 제어하는 것이 가능하다. 메타데이터를 더욱 풍부하게 만듦으로써, 전체 CFI를 체킹하는 것이 구현할 수 있다.
PUMP(10)의 정책 설계자 및 소프트웨어 부분의 관점에서, 작은 도메인-특정 언어로 작성된 상징적 규칙(symbolic rule)을 사용하여 정책을 간결하게 서술할 수 있다. 예시적인 상징적 규칙 및 그의 프로그램 언어는 예를 들어, "PUMP 프로그램하기, 하드웨어 지원형 보안 마이크로-정책(PROGRAMMING THE PUMP, Hardware-Assisted Micro-Policies for Security)"이라는 제목의 단원에서 설명된다.
상징적 규칙은 다양한 메타데이터 추적 메커니즘을 간결하게 인코딩할 수 있다. 그러나 하드웨어 레벨에서, 기본 계산의 속도 저하를 피하기 위해 효율적인 해석을 위해 조정된 표현을 위한 규칙이 필요하다. 이를 위해, 구체적 규칙(concrete rule)이라고 불리는 더 낮은 레벨의 규칙 형식이 도입될 수 있다. 직관적으로, 주어진 정책에 대한 각각의 상징적 규칙은 동등한 세트의 구체적인 규칙으로 확장될 수 있다. 그러나 단일의 상징적 규칙은 일반적으로 무한한 수의 구체적인 규칙을 발생할 수 있기 때문에, 이렇게 완성시킨 일은 느리게 수행되어 시스템이 실행되는 동안 필요에 따라 구체적인 규칙을 발생한다.
(예를 들어, ROP보다 풍부한) 메타데이터 태그가 있는 정책의 경우, 상징적 규칙으로부터 구체적 규칙으로의 변환은 동일한 일반 라인을 따르지만, 세부 사항은 조금 복잡해진다. 예를 들어, 테인트-추적 정책은 태그가 메모리 데이터 구조체를 가리키는 포인터가 되게 하며, 각각의 메모리 데이터 구조체는 (주어진 단편의 데이터의 근원이 될 수 있는 데이터 소스 또는 시스템 컴포넌트를 나타내는) 테인트들의 임의의 크기의 세트를 서술한다. 로드 opgroup에 대한 상징적 규칙은 로드된 값에 미친 테인트가 명령어 자체에 미친 테인트, 로드를 위한 타깃 어드레스 및 그 어드레스에 있는 메모리의 합집합이어야 한다고 말한다. 상징적 규칙 및 그의 프로그램 언어는 이전에 확인된 "PUMP 프로그램하기, 보안을 위한 하드웨어 지원형 마이크로-정책"이라는 제목의 논문으로부터 참조로 포함되고 공공 열람이 가능하다.
구별되는 태그의 수를 줄이기 위해(및 이에 따라 규칙 캐시에 가해지는 압박을 줄이기 위해), 메타데이터 구조체는 내부적으로 표준형으로 저장될 수 있고, 태그는 변경할 수 없기 때문에 공유하게 되면 완전히 악용된다(예를 들어, set 요소에는 표준 순서가 부여되므로 set는 공통 프리픽스 서브세트(common prefix subset)를 공유하여 간결하게 표현될 수 있다). 더 이상 필요하지 않을 때, 이러한 구조체는(예를 들어, 가비지 콜렉션에 의해) 되돌려질 수 있다.
실시예는 복합 정책을 이용할 수 있다. 태그를 여러 컴포넌트 정책의 태그 튜플을 가리키는 포인터가 되도록 함으로써 다중 직교 정책은 동시에 시행될 수 있다. (일반적으로 다중 정책은 직교하지 않을 수 있다) 예를 들어, 테인트-추적 정책을 사용하여 제 1 리턴 opgroup(ROP) 정책을 작성하기 위해, 각 태그를 하나의 튜플의 표현(r; t)을 가리키는 포인터로 놓는데, 여기서 r은 ROP 태그(코드 위치 식별자)이고 t는 테인트 태그(한 세트의 테인트를 가리키는 포인터)이다. 캐시 룩업 프로세스는 정확히 동일하지만, 미스가 발생할 때 튜플의 컴포넌트를 추출하고 상징적 규칙의 세트를 둘 다 평가하는 루틴으로 디스패치한다. 두 정책이 적용하는 규칙을 가진 경우에만 동작이 허용되며; 이 경우 결과 태그는 두 개의 서브 정책의 결과를 포함하는 쌍을 가리키는 포인터이다.
연결 정책 시스템 및 보호에서, 정책 시스템은 각 사용자 프로세스 내에서 별도의 메모리 영역으로서 존재한다. 정책 시스템은 예를 들어, 미스 핸들러에 대한 코드, 정책 규칙 및 정책의 메타데이터 태그를 나타내는 데이터 구조체를 포함할 수 있다. 프로세스에 정책 시스템을 배치하면 기존의 유닉스(Unix) 프로세스 모델에서 침입이 최소화되고 정책 시스템과 사용자 코드 간의 가벼운 전환을 용이하게 한다. 정책 시스템은 다음에 설명되는 메커니즘을 사용하여 사용자 코드와 분리된다.
분명히, 공격자가 메타데이터 태그를 재 기입하거나 그 해석을 변경할 수 있다면, PUMP에 의해 제공되는 보호는 쓸모가 없다. 본 명세서에서 설명된 기술은 이러한 공격을 방지하도록 설계된다. 커널(kernel), 로더(loader) 및 (일부 정책의 경우) 컴파일러(complier)는 신뢰성이 있다. 특히, 컴파일러는 초기 태그를 워드에 할당하고, 필요한 경우 규칙을 정책 시스템에 전달하는 것을 필요로 한다. 로더는 컴파일러에 의해 제공된 태그를 보존할 것이고, 컴파일러로부터 로더까지의 경로는 예를 들어, 암호화 서명을 사용하여 함부로 변경되는 것이 방지된다.
본 명세서에서의 기술에 따른 실시예는 각 프로세스에 대해 초기 메모리 이미지를 설정하는 표준 유닉스 스타일 커널을 사용할 수 있다. (이러한 가정 중 일부를 없애기 위해 마이크로-정책을 사용하여 TCB의 크기를 추가로 줄이는 것이 가능할 수 있다). 이러한 실시예에서, 규칙-캐시-미스-핸들링 소프트웨어가 정확하게 구현된다고 추가로 가정한다. 이것은 작으며, 그렇기 때문에, 공식 검증을 위한 좋은 타깃이다. 하나의 관심사는 프로세스에서 실행 중인 사용자 코드가 프로세스의 정책에 의해 제공되는 보호를 약화시키지 못하게 하는 것이다. 사용자 코드는 (i) 태그를 직접 조작할 수 없어야 하고 - 모든 태그 변경은 현재 시행되는 정책/정책 규칙에 따라 수행되어야 하고 -; (ii) 미스 핸들러에 의해 사용된 데이터 구조체 및 코드를 조작할 수 없어야 하며; (iii) 하드웨어 규칙 캐시에 규칙을 직접 삽입할 수 없어야 한다.
어드레스 지정과 관련하여, 사용자 코드에 의한 태그의 직접적인 조작을 방지하기 위해, 모든 64b 워드에 첨부된 태그는 자체가 별도로 어드레스 지정될 수 없다. 특히, 태그를 판독하거나 기입하기 위해 태그 또는 태그의 일부분에만 대응하는 어드레스를 특정하는 것은 가능하지 않다. 모든 사용자 액세스 가능한 명령어는 원자 단위로서 (데이터, 태그) 쌍에 대해 동작한다 - 표준 ALU는 값 부분에 대해 동작하며 PUMP는 태그 부분에 대해 동작한다.
본 명세서에서의 기술에 따른 실시예의 미스 핸들러 아키텍처와 관련하여, 정책 시스템은 PUMP 캐시에 대한 미스에 대해서만 작동될 수 있다. 정책 시스템과 사용자 코드 간에 분리를 제공하기 위해, 미스 핸들러 동작 모드가 프로세서에 추가된다. 정수 레지스터 파일은 레지스터의 저장 및 복원을 방지하기 위해 미스 핸들러에만 사용 가능한 16 추가 레지스터로 확장된다. 16 개 추가 레지스터를 사용하는 것은 예시적이며 실제로는 정수 레지스터 파일을 더 적은/더 많은 레지스터로 확장해야 할 수도 있음을 유의하여야 한다. 결함 유도 명령어의 PC, 규칙 입력(opgroup 및 태그) 및 규칙 출력은 미스 핸들러 모드에 있는 동안 레지스터로서 출현한다. 구체적 규칙을 캐시에 설치하는 것을 마무리하고 사용자 코드로 리턴하는 미스-핸들러-리턴(miss-handler-return) 명령어가 추가된다.
본 명세서에서의 기술에 따른 실시예에서, 프로세서(12)가 미스 핸들러 모드에 있는 동안 PUMP(10)의 정상적인 거동은 연계 해지된다(disengaged). 그 대신, 단일의 하드와이어드 규칙(hardwired rule)이 적용되고; 미스 핸들러가 손대는 모든 명령어 및 데이터는 임의의 정책에 의해 사용되는 태그와 완전히 다른 미리 정의된 미스 핸들러 태그로 태깅되어야 한다. 이렇게 하면 동일한 어드레스 공간에서 미스 핸들러 코드 및 데이터와 사용자 코드 간의 분리가 보장된다. 사용자 코드는 정책 시스템 데이터 또는 코드를 손대거나 실행할 수 없으며, 미스 핸들러는 뜻하지 않게 사용자 데이터와 코드에 손댈 수 없다. 미스-핸들러-리턴 명령어는 미스 핸들러 모드에서만 발행될 수 있기에, 사용자 코드가 임의의 규칙을 PUMP에 삽입하는 것이 방지된다.
이전 동작에서는 안전 및 보안 정책을 간결하게 표현하거나 대략적으로 표현하는데 정교한 방식이 사용되었지만, 이것은 종종 의도된 정책에 대한 절충안이며, 이것은 복잡함을 간결함으로 맞바꾸어준다. 본 출원에서 설명되는 바와 같이, 추가 런타임 오버헤드가 거의 없거나 전혀 없이 보다 완벽하고 보다 자연스럽게 보안 정책의 필요성을 포착하는 풍부한 메타데이터를 포함하는 것이 가능하다. 메타데이터 표현 및 정책 복잡성에 대한 고정된 경계를 부과하는 대신, PUMP(10)는 성능 측면에서 적절한 저하를 제공한다. 이것은 일반적인 경우의 성능 및 크기에 영향을 주지 않으면서 정책으로 하여금 필요한 곳에 더 많은 데이터를 사용할 수 있게 한다. 복잡한 정책 조차도 쉽게 표현되고 실행될 수 있기 때문에, 정책의 증분적 세분화 및 성능 조정을 또한 가능하게 한다.
메타데이터-기반 정책 시행의 가치에 대한 증거가 늘어나면서, 본 개시내용은 소프트웨어 정의 메타데이터 처리를 위한 아키텍처를 정의하고 대부분의 런타임 오버헤드를 제거하는 가속기를 식별한다. 전용 하드웨어 메타데이터 전파 해결책에 필적할만한 성능을 제공하는 네 개의 마이크로아키텍처 최적화(opgroup, 태그 압축, 태그 변환 및 미스 핸들러 가속화)와 함께 동시에 지원되는 메타데이터 비트의 수 또는 정책의 수에 제한 없이 (즉, 어떤 경계도 없이) 아키텍처가 본 명세서에서 소개되고 설명된다. 소프트웨어 정의된 메타데이터 정책 모델 및 그의 가속화는 사운드 정보 흐름 제어, 미세 세밀화된 액세스 제어, 무결성, 동기화, 경합 탐지(race detection), 디버깅, 애플리케이션-특정 정책 및 동적 코드의 통제된 발생 및 실행을 비롯하여 본 명세서에서 설명된 것들 이외의 광범위한 정책에 적용 가능할 것이다.
본 명세서에 설명된 다양한 양태 및 실시예의 일부 비제한적인 장점은 (i) 이 아키텍처에 의해 지원되는 정책을 간결하고 정확하게 설명하기 위한 프로그래밍 모델 및 지원 인터페이스 모델; (ii) 잘 연구된 정책의 네 개의 다양한 클래스를 사용하여 정책 인코딩 및 구성에 관한 자세한 예; (iii) 이러한 정책의 요구 사항, 복잡성 및 성능의 정량화를 제공한다.
본 명세서에 설명된 실시예의 프로그래밍 모델은 다수의 다른 정책을 인코딩할 수 있다. 여기서 정보-흐름 제어는 단순한 테인트 추적 모델보다 더 풍부하지만, 암묵적 흐름을 추적하는 것은 RIFLE-스타일의 바이너리 변환으로 또는 컴파일러로부터의 약간의 지원과 함께PC 태그를 사용하여 지원받을 수 있다. 마이크로-정책은 경량 액세스 제어 및 구획화(compartmentalization)를 지원할 수 있다. 태그는 위조할 수 없는 자원을 구별하는데 사용될 수 있다. 고유의 발생된 토큰은 데이터의 봉인 및 보증을 위한 키로서 작용할 수 있으며, 이는 결국 강력한 추상화에 사용할 수 있으므로, 인가된 코드 구성요소에 의해서만 데이터가 생성되고 파괴됨을 보장한다. 마이크로-정책 규칙은 불역성 및 선형성과 같은 데이터 불변성을 실시할 수 있다. 마이크로-정책은 데이터 또는 선물에 대해 채워진/비어있는 비트와 같은 동기화 프리미티브(synchronization primitive)에 대한 대역 외 메타데이터로서 또는 잠금에 관한 경합 조건을 감지하는 상태로서 병렬 처리를 지원할 수 있다. 시스템 설계자는 모든 라인을 감사 또는 재작성하지 않고도 특정 마이크로-정책을 기존의 코드에 적용할 수 있다.
본 출원에서 설명된 PUMP(10) 설계는 융통성과 성능의 매력적인 조합을 제공하여, 대부분의 경우 전용 메커니즘에 필적하는 단일 정책 성능으로 낮은 레벨의 미세 세밀화된 보안 정책의 다양한 모음을 지원하면서, 규칙 복잡성이 증가함에 따라 대부분 적절히 성능을 저하시킨 보다 풍부하고 복합적인 정책을 지원한다. 또한, PUMP에 의해 제공되는 메커니즘은 그 자체의 소프트웨어 구조체를 보호하는데 사용될 수 있다. 본 명세서에서의 기술에 따른 실시예는 PUMP(10)를 사용하여 "구획화" 마이크로-정책을 구현하고 이를 사용하여 미스 핸들러 코드를 보호함으로써 특별한 미스 핸들러 동작 모드를 대체할 수 있다. 마지막으로, 본 명세서에 설명된 바와 같이, 각각의 정책에 의해 제공되는 보호가 다른 정책과 완전히 독립적인 경우, 직교 세트의 정책들이 조합될 수 있다. 그러나 정책은 종종 상호 작용한다: 예를 들면, 정보-흐름 정책은 메모리 안전 정책에 의해 할당되는 새로운 영역에 태그를 배치해야 할 수 있다. 정책 구성에는 표현 및 효율적인 하드웨어 지원 둘 모두와 관련하여 분석이 필요하다.
이제는 힙 할당 메모리에서 모든 시간적 및 공간적 위반을 식별하는 본 명세서에서의 기술에 따른 실시예에서 메모리 안전 정책의 구현을 도시하는 다른 예가 설명될 것이다. 적어도 하나의 실시예에서, 각각의 새로운 할당에 대해, 새로운 컬러 id, c를 구성하고 (예를 들어, 예컨대 memset을 통해) 새로 생성된 메모리 블록 내의 각각의 메모리 위치상의 태그로서 c를 기입하는 처리가 수행될 수 있다. 새 블록을 가리키는 포인터 또한 c로 태깅된다. 나중에 포인터를 역 참조하는 처리가 수행될 때, 그 처리는 포인터가 참조하거나 가리키는 메모리 셀 상의 태그와 동일한지를 포인터의 태그가 체크하는 것을 포함할 수 있다. 블록이 프리(free) 상태로 될 때, 블록의 모든 셀상의 태그가 비어 있는 메모리를 나타내는 상수 F로 수정될 수 있다. 힙에는 초기에 F로 태깅될 수 있다. 포인터가 아닌 경우 특수 태그인 
이 사용할 수 있다. 따라서, 일반적으로, 실시예는 메모리 위치에 대해 컬러 c 또는 
중 어느 하나인 태그 t를 기입할 수 있다.
메모리 셀은 포인터를 포함할 수 있기 때문에, 일반적으로 메모리 내의 각 워드는 두 개의 태그와 연관될 수 있다. 이러한 실시예에서, 각 메모리 셀상의 태그는 쌍(c, t)을 가리키는 포인터가 되며, 여기서 c는 이 셀이 할당되었던 메모리 블록의 id이고, t는 셀에 저장된 워드의 태그이다. 실시예는 상징적 규칙의 관점에서 정책을 특정하기 위해 본 명세서의 다른 곳에서 설명된 규칙 기능에 기초한 도메인 특정 언어를 사용할 수 있다. 로드 및 스토어에 대한 규칙은 이들 쌍을 패킹 및 언패킹하는 것과 함께, 각 메모리 액세스가 유효한지를 (즉, 액세스된 셀이 이 포인터가 가리키는 블록 내에 있는지를) 체크하는 것에 주의한다:
전술한 규칙 및 다른 규칙에서 체크의 수행은 상징적 규칙이 유효한 조건(예를 들어, 스토어 규칙에서 위의 c2=c3)으로서 나타난다. "-" 기호는 규칙에서 돈-케어 필드를 나타낸다.
어드레스 산술 연산은 포인터 태그를 보존한다:
포인터에 관한 태그가 할당으로부터만 발생한다는 불변성을 유지하기 위해, 데이터를 스크래치(scratch)(예를 들어, 상수의 로딩)부터 생성하는 동작은 그의 태그를 
로 설정한다.
메모리 안전성 정책을 구현하는 실시예에서, malloc 및 free와 같은 동작은, 예를 들어, 태깅된 명령어 및 (예를 들어, 한번 사용되면 캐시로부터 삭제될 수 있는) 일시적 규칙을 사용하여 메모리 영역에 태깅하도록 수정될 수 있다. malloc와 관련하여, 처리는 포인터가 일시적인 규칙을 통해 새로운 영역을 가리키는 새로운 태그를 발생할 수 있다. 예를 들어, 무브(move)에 대한 규칙은 다음과 같은 일시적인 규칙일 수 있다:
위 첨자가 1 인 화살표(예를 들어, 
)는 일시적 규칙을 나타낼 수 있다. 그런 다음 태깅된 포인터를 리턴하기에 앞서, 새로 태깅된 포인터는 특수 스토어 규칙을 사용하여 할당된 영역의 모든 동작에 0을 기입하는데 사용될 수 있다:
나중 시점에, 영역을 free 리스트에 리턴하기 전에, free는 수정된 스토어 명령어를 영역을 할당되지 않은 것으로 다시 태깅하는데 사용할 수 있다:
메모리 안전 정책을 사용하는 이러한 실시예에서, opgroup은 다음과 같이 규칙 세트를 서술하는데 사용될 수 있다:
정책 명세에 대해 위에서 사용된 상징적 규칙은 변수를 사용하여 기입될 수 있으므로, 소수의 상징적 규칙이 구별되는 값의 무한한 세계를 통해 정책을 설명할 수 있게 한다. 그러나 규칙 캐시에 저장된 구체적인 규칙은 특정의 구체적 태그 값을 말한다. 예를 들어, 23 및 24가 유효한 메모리 블록 컬러이면, 실시예는 c = 23 및 c = 24에 대한 PUMP 규칙 캐시에서 위의 상징적 규칙(3)의 구체적인 인스턴스를 갖는 구체적인 규칙을 사용할 수 있다. 예를 들어, 
을 0으로 인코딩하고 돈-케어 필드를 0으로 표시한다고 가정하면, 위의 상징적 규칙(3)에 대해 구체적 규칙은 다음과 같다:
본 명세서의 다른 곳에서의 논의와 일관하여, 적어도 하나의 실시예에서, 미스 핸들러는 규칙을 PUMP 규칙 캐시에 삽입하기 위해 구체적 입력 태그를 획득하고 상징적 규칙으로부터 컴파일된 코드를 실행하여 연관된 구체적 출력 태그를 생성할 수 있다. 상징적 규칙이 위반을 식별할 때, 제어는 에러 핸들러에 전달하고 새로운 구체적 규칙은 PUMP 규칙 캐시에 삽입되지 않는다.
이제 본 명세서에서의 논의와 일치하는 소프트웨어 정의된 메타데이터 처리(software defined metadata processing, SDMP)를 지원하기 위해 RISC-V 아키텍처가 메타데이터 태그 및 PUMP로 추가로 확장된 것에 기초한 본 명세서에서의 기술에 따른 실시예가 설명될 것이다. RISC-V는 축소 명령어 집합 컴퓨팅(reduced instruction set computing)(RISC) 명령어 집합 아키텍처(instruction set architecture)(ISA)의 오픈 소스 구현으로서 특징지을 수 있다. 이러한 실시예에서, 메타데이터 태그는 각 워드에 대한 명령어 및 데이터 둘 모두에 배치된다. RISC-V 아키텍처에서 워드는 64 비트이다. RISC-V 아키텍처는 상이한 워드 크기 변형성을 제공한다 - RV64는 64 비트 워드 크기이고 RV32는 32 비트 워드 크기이다. 레지스터 및 사용자 어드레스 공간의 너비 또는 크기는 워드 크기에 따라 다를 수 있다. 태그 크기 또는 너비는 워드 크기 또는 너비와 독립적일 수 있지만, 일 실시예에서는 더 전형적으로 동일할 수 있다. 관련 기술분야에서 공지된 바와 같이, RISC-V 아키텍처는 32 비트 명령어를 가지며, 이에 따라 64 비트 워드 크기를 사용하여 지원하고 동작하는 실시예는 단일의 태깅된 워드에 2 명령어를 저장할 수 있다. RISC-V 아키텍처의 전술한 양상 및 다른 양상은 메타데이터 태그인 PUMP 및 SDMP와 함께 사용하기 위해 RISC-V 아키텍처를 확장하는 것과 관련된 상이한 기술 및 특징의 사용과 관련하여 본 명세서의 다른 곳에서 논의된다.
RISC-V 아키텍처는 예를 들어, ["The RISC-V Instruction Set Manual Vol. I, User-Level ISA, Version 2.0", May 6, 2014, Waterman, Andrew, et. al., ("also referred to as the "RISC-V user level ISA")]에 설명된 바와 같은 사용자 레벨 명령어를 포함하며, 이 문헌은 본 명세서에서 참조로 포함되고, 예를 들어 RISCV.ORG 웹 사이트 및 버클리 소재의 유니버시티 오브 캘리포니아(University of California)를 통해 Technical Report UCB/EECS-2014-54로서 대중에게 입수 가능하다. RISC-V 아키텍처는 또한 예를 들어 ["The RISC-V Instruction Set Manual Volume II: Privileged Architecture, Version 1.7", May 9, 2015, also referred to as the "RISC-V privileged ISA")]에 설명된 바와 같이, 오퍼레이팅 시스템, 부착형 외부 디바이스 등을 실행하는데 필요한 권한 있는 명령어 및 추가 기능성을 포함하는 권한 있는 아키텍처를 통합하며, 이 문헌은 본 명세서에서 참조로 포함되고, 예를 들어, RISCV.ORG 웹 사이트 및 버클리 소재의 University of California를 통해 Technical Report UCB/EECS-2015-49로서 대중에게 입수 가능하다.
RISC-V 아키텍처의 실시예는 다음과 같은 네 개의 RISC-V 권한 레벨: 사용자/애플리케이션(U) 권한 레벨에 대한 레벨 0, 슈퍼바이저(S) 권한 레벨에 대한 레벨 1, 하이퍼바이저(H) 권한 레벨에 대한 레벨 및 머신(M) 권한 레벨에 대한 레벨 3RISC-V 권한 레벨을 가질 수 있다. 전술한 것에서, RISC-V 권한 레벨은 최고 내지 최저의 0부터 3까지의 순위가 매겨질 수 있고, 레벨 0이 최고 또는 가장 큰 권한 레벨을 나타내고, 레벨 3이 가장 낮은 또는 최소 권한 레벨을 나타낸다. 이러한 권한 레벨은 상이한 컴포넌트들 간에 보호를 제공하는데 사용될 수 있으며, 현재 권한 레벨 또는 모드에서 허용되지 않는 연산을 수행하는 코드를 실행하려 시도하면 기본 실행 환경으로 향하게 하는 트랩과 같은 예외가 일어나게 한다. 머신 레벨은 가장 높은 권한을 가지며 RISC-V 하드웨어 플랫폼에만 유일한 강제적 권한 레벨(mandatory privilege level)이다. 머신 모드(M-모드)에서 실행되는 코드는 머신 구현으로의 액세스 레벨이 낮기 때문에 본질적으로 신뢰성이 있다. 사용자 모드(U-모드) 및 슈퍼바이저 모드(S-모드)는 각각 통상의 애플리케이션 및 오퍼레이팅 시스템용으로 의도되지만, 하이퍼바이저 모드(H-모드)는 가상 머신 모니터를 지원하도록 의도된다. 각 권한 레벨은 임의적 확장과 변형성을 가진 핵심 권한 ISA 확장 세트를 가지고 있다. RISC-V 아키텍처의 구현은 적어도 M-모드를 지원하여야 하고 대부분의 구현은 적어도 U-모드 및 M-모드를 지원한다는 것을 유의하여야 한다. S-모드는 슈퍼바이저 레벨 오퍼레이팅 시스템의 코드와 M-모드에서 실행되는 다른 보다 권한 있는 코드 간의 추가 분리를 제공하기 위해 추가될 수 있다. 사용자 또는 애플리케이션 코드는 전형적으로 트랩(예를 들어, 슈퍼바이저 호출, 페이지 폴트(page fault)) 또는 인터럽트가 발생하여 지원되는 상위 권한 모드 또는 레벨(예를 들어, H, S 또는 M 모드) 중 하나에서 실행되는 트랩 핸들러로 제어를 강제로 이전할 때까지 U-모드에서 실행될 수 있다. 이후 트랩 핸들러의 코드가 실행된 다음 트랩을 유발한 원래 사용자 코드 또는 애플리케이션으로 제어가 반환될 수 있다. 이러한 사용자 코드 또는 애플리케이션의 실행은 트랩 핸들러 호출을 트리거했던 U-모드의 원래의 트랩된 명령어에서 또는 그 이후에서 재개될 수 있다. RISC-V 구현에서 지원되는 모드들의 다양한 조합은: 단일 M 모드, 두 개의 모드 - M 및 U, 세 개의 모드 - M, S 및 U, 또는 네 개의 모드 M, H, S, U 만을 포함할 수 있다. 본 명세서에 설명된 적어도 하나의 실시예에서, 전술한 권한 레벨들 네 개 모두가 지원될 수 있다. 최소한 본 명세서에서의 기술에 따른 실시예는 M AND U 모드를 지원할 수 있다.
RISC-V 아키텍처는 하나 이상의 연관된 권한 레벨에 의해 원자적으로 판독되고 수정될 수 있는 제어 상태 레지스터(Control Status Register)(CSR)를 갖는다. 일반적으로 CSR은 네 개의 권한 레벨 중 첫 번째 권한 레벨과 첫 번째 권한 레벨보다 높은 네 개 권한 레벨 중 임의의 다른 권한 레벨에서 액세스할 수 있다. 예를 들어, 프로그램이 U-모드(레벨 3)에서 실행 중이고 규칙 캐시 미스와 같은 트랩이 발생한다고 가정하면, 제어는 규칙 캐시 미스 핸들러 코드와 같은 상위 권한 또는 모드(예를 들어, 레벨 0 내지 2 중 임의의 레벨)에서 실행 중인 트랩 핸들러로 이전된다. 트랩이 발생하면, 정보는 M-모드에서 실행되는 트랩 핸들러에 액세스 가능한, 예를 들면 그렇지 않았더라면 (예를 들어, H, S 또는 U 모드에서는 코드에 액세스 가능하지 않은) 더 낮은 권한 레벨에서 실행되는 임의의 다른 코드에 액세스 가능하지 않은, CSR에 배치될 수 있다. 적어도 하나의 실시예에서, 규칙 캐시 미스 핸들러는 PUMP 보호 레벨 이상의 권한 레벨에서 실행될 수 있다(예를 들면, H-모드, S-모드 또는 M-모드에서 실행될 수 있다). 이러한 실시예에서, 본 명세서의 다른 곳에서 설명된 바와 같이, 규칙 캐시 미스 핸들러 레벨에서 태그 정의 및 정책은 (예를 들어, 가상 머신별로) 오퍼레이팅 시스템 전역에 걸쳐 있을 수 있으며, 이에 따라 동일한 태그 정의 및 정책은 모든 실행 코드 전체에 적용될 수 있다. 적어도 하나의 실시예에서, 애플리케이션별 또는 프로세스별 정책은 그러한 정책이 전역적으로 설치된 곳에서 지원될 수 있고, PC(현재 명령어를 식별하는 프로그램 카운터) 및/또는 코드는 프로세스 또는 애플리케이션-특정 규칙을 구별하기 위해 태깅될 수 있다. 가상 머신(virtual machine)(VM)이 메모리를 공유하지 않는 실시예에서, 정책은 VM 단위로 정의될 수 있다.
본 명세서의 다른 부분에서의 논의와 일관하여, PUMP는 SDMP에 대한 규칙 캐시로서 특징지을 수 있다. 명령어상의 한 세트의 태그와 동작 결과에 대한 명령어 입력 및 태그와의 사이에는 매핑이 있을 수 있다. 태그 처리는 명령어의 정상 동작과는 독립적이며 평행하다. 적어도 하나의 실시예에서, PUMP는 정상 RISC-V 동작과 병렬로 실행하여, 동작의 결과에 대한 태그를 공급한다. PUMP는 캐시이기 때문에, 규칙 캐시 미스는 PUMP가 특정 명령어 및 그래서 PUMP 입력(예를 들어, 강제)의 특정 대응 세트를 처음 수신할 때 또는 PUMP가 규칙을 캐시에 보유할 수 없을 때(예를 들어, 캐시의 용량이 초과되고 그래서 규칙이 규칙 캐시에서 퇴거되었거나 어쩌면 충돌할 때) 발생한다. 규칙 캐시 미스는 미스 트랩 시스템(예를 들어, 규칙 캐시 미스 핸들러)의 코드에 의해 처리되는 미스 트랩을 유발한다. 입력은 PUMP CSR을 통해 미스 핸들러로 전달될 수 있고, 규칙 삽입은 CSR을 통해 또한 PUMP로 다시 제공될 수 있다. 이것은 아래에서 보다 상세하게 논의된다. 제 1 실시예는 5 PUMP 입력 태그가 존재하는 본 명세서의 다른 곳에서 논의된다. 변형예로서, 실시예는 상이한 수의 태그 및 다른 PUMP 입력을 포함할 수 있다. 특정 수의 PUMP 태그 입력은 명령어 세트 및 오퍼랜드에 따라 다를 수 있다. 예를 들어, 다음은 RISC-V 아키텍처에 기초한 일 실시예에서 PUMP 입력으로서 포함될 수 있다:
1. Opgrp - 특정 opgroup가 현재 명령어를 포함함을 나타낸다. 일반적으로, opgroup은 명령어 그룹을 추상화한 것으로 본 명세서의 다른 곳에서 논의된다.
2. PCtag - PC상의 태그
3. CItag - 명령어상의 태그
4. OP1tag - 명령어로의 RS1 입력상의 태그
5. OP2tag - 명령어로의 RS2 입력상의 태그(또는 CSR 명령어일 때 CSR상의 태그)
6. OP3tag - 명령어에 대한 RS3 입력상의 태그
7. Mtag - 명령어로의 메모리 입력 또는 명령어의 메모리 타깃상의 태그
8. funct12(funct7) - 본 명세서의 다른 곳에서 설명된 바와 같이 일부 명령어에서 발생하는 확장된 opcode 비트이다.
9. subinstr - 워드에 여러 명령어가 채워져 있을 때, 이 입력은 워드의 어떤 명령어가 PUMP에 의해 연산되는 현재 명령어인지를 식별한다.
다음은 RISC-V 아키텍처에 기초한 일 실시예에서 펌프 출력으로서 포함될 수 있다:
1. Rtag - 결과: 목적지 레지스터, 메모리 또는 CSR 상의 태그
2. newPCtag - 이 동작 이후 PC상의 태그(예를 들어, 때로는 PCnew 태그라고도 지칭함).
정보는 예를 들어 트랩 발생시 U-모드에서 실행되는 사용자 코드로부터 M-모드에서 실행되는 규칙 캐시 미스 핸들러와 같은 트랩 핸들러로 CSR을 통해 전달될 수 있다. 유사한 방식으로, 정보는 CSR 내의 정보가 U-모드에서 액세스 가능한 대응하는 레지스터에 배치될 수 있는 경우 U-모드에서 프로그램 실행을 재개할 때 M-모드의 트랩 핸들러 사이에서 CSR을 통해 전달될 수 있다. 이러한 방식으로, 하나의 권한 레벨의 CSR과 다른 권한 레벨의 레지스터 사이에는 매핑이 있을 수 있다. 예를 들어, 본 명세서에서의 기술에 따른 실시예에서, 특정 명령어 오퍼랜드 태그가 트랩의 발생시 CSR에 기입되어 태그를 입력으로서 PUMP 및 규칙 캐시 미스 핸들러에 전달하는 경우 M-모드 핸들러 및 PUMP에 액세스 가능한 CSR이 정의될 수 있다. 유사한 방식으로, CSR은 예컨대, 규칙 캐시 미스 이후 (예를 들어, 매칭 규칙이 현재 명령어에 대한 PUMP 규칙 캐시에서 발견되지 않을 때 규칙 캐시 미스가 발생하는 경우) 프로그램 실행을 재개할 때, 정보를 트랩 핸들러 및/또는 (U-모드보다 높은 권한 레벨에서 동작하는) PUMP로부터 U-모드에서 실행되는 다른 코드로 전달하는데 사용될 수 있다. 예를 들어, CSR은 PCnew 및 RD에 대한 PUMP 출력 태그를 출력하거나 전파하는데 사용될 수 있다. 또한, CSR은 특정 CSR에 기입하는 것에 응답하여 상이한 행위가 발생할 수 있는 경우에 정의될 수 있다. 예를 들어, 규칙 캐시 미스 핸들러 코드는 특정 CSR에 기입함으로써 새로운 규칙을 PUMP의 규칙 캐시에 기입/삽입할 수 있다. 정의된 특정 CSR은 실시예에 따라 다를 수 있다.
도 25를 참조하면, 본 명세서에서의 기술에 따른 일 실시예에서 정의되고 사용될 수 있는 CSR의 예가 도시된다. 테이블(900)은 CSR 어드레스가 16 진수인 제 1 열(902), 권한의 제 2 열(904), CSR 이름을 나타내는 제 3 열(906) 및 CSR의 설명이 있는 제 4 열(908)을 포함한다. 테이블(900)의 각 라인은 상이한 정의된 CSR에 대한 정보를 식별할 수 있다. 테이블(900)에서의 상이한 CSR은 또한 실시예에 포함될 수 있는 부가적인 특징과 관련하여 본 명세서의 다른 곳에서 보다 상세하게 설명된다.
행(901a 내지 901c)은 PUMP에 의한 코드 및/또는 명령어에 태깅하기 위해 사용되는 특별한 태그 값을 갖는 CSR을 식별한다. 적어도 하나의 실시예에서, 엔트리(901a)에 의해 정의된 sboottag CSR은 시스템에서 사용되는 제 1 초기 또는 시작 태그 값을 포함할 수 있다. 전술한 시작 태그 값은 부트스트랩 태그 값(bootstrap tag value)으로 지칭될 수 있다. 일 양태에서, 부트스트랩 태그 값은 모든 다른 태그가 도출되거나 기초될 수 있는 "시드(seed)"로 특징지을 수 있다. 따라서, 부트스트랩 태그는 일 실시예에서 모든 다른 태그를 생성하기 위한 시작점으로 사용될 수 있다. 오퍼레이팅 시스템에서 부트스트랩 코드의 시작 위치의 초기 로딩과 유사한 방식으로, 하드웨어는 부트스트랩 태그로서 사용된 특정의 미리 정의된 태그 값으로 CSR(901a)을 초기화하는데 사용될 수 있다. 본 명세서에서의 기술에 따라 부트스트랩 태그가 시스템의 부팅의 일부로서 판독되면, sboottag CSR이 클리어될 수 있다. 예를 들어, 오퍼레이팅 시스템 코드의 권한 있는 부분은 부트스트랩 태그 값을 사용하여 초기 태그 전파를 수행하는 규칙을 호출하는 명령어를 포함할 수 있다. 부트스트랩 태그의 사용과 태그 발생 및 전달에 대해서는 본 명세서의 다른 곳에서 추가로 설명된다. 행(901b)은 본 명세서의 다른 곳에서 설명되는 바와 같이 공개적 신뢰성 없는 소스(public untrusted source)로부터의 데이터에 태깅하기 위해 사용된 태그 값을 포함하는 CSR을 식별한다. 행(901c)의 경우, 데이터 및/또는 명령어에 태깅할 때 디폴트 태그 값으로서 사용될 수 있는 디폴트 태그 값을 포함하는 CSR을 식별한다.
행(901d 및 901e)은 각각 opgroup/don't care 테이블에 기입하기 위한 어드레스 및 데이터를 나타낸다(예를 들어, 본 명세서의 다른 곳에서 opcode에 대한 opgroup 및 care/don't care 비트를 포함하는 매핑 또는 변환 테이블이라고도 지칭된다). 행(901e)에 의해 표시된 CSR에 기입하면 opgroup/care 표에 기입하는 것을 트리거한다. 행(901f)은 PUMP 규칙 캐시를 플러시하기 위해 기입될 수 있는 CSR을 식별한다. 행(901g 내지 901m)은 현재 명령어에 대한 태그 입력을 PUMP 및 규칙 캐시 미스 핸들러에 제공하는 CSR을 식별한다. 행(901j 내지 901m) 각각은 처리되는 현재 명령어의 오퍼랜드에 대한 상이한 오퍼랜드 태그를 나타내며, 규칙 캐시 미스를 유발함으로써 명령어는 최대 4개의 그러한 오퍼랜드(4 오퍼랜드 중 3개는 레지스터(CSR(901j 내지 901l)이고 4번째 오퍼랜드는 행(901m)에 의해 표시된 CSR에 저장된 태그를 갖는 메모리 위치임)를 포함할 수 있다. 행(901n)은 본 명세서의 다른 곳에서 설명된 바와 같이 현재 명령어의 opcode가 확장된 func12 필드를 사용할 때 확장된 opcode 비트를 보유하는 CSR을 식별한다. 행(901o)은 워드의 어떤 서브 명령어가 현재 참조되는 명령어인지를 나타내는 CSR을 나타낸다. 본 명세서의 다른 곳에서 논의된 바와 같이, 단일 태깅된 워드는 64 비트일 수 있고, 각 명령어는 32 비트일 수 있으며, 그에 따라 두 개의 명령어가 단일 태깅된 워드에 포함될 수 있다. 행(901o)로 표시된 CSR은 두 명령어 중 어느 명령어가 PUMP에 의해 처리되는지를 식별한다. 행(901p-901q)은 새로운 PC의 PUMP 출력 태그(예를 들어, 다음 명령어에 대한 새로운 PC 태그) 및 RD(목적지 레지스터, 현재 명령어의 결과에 대한 어드레스)를 각기 포함하는 CSR을 식별한다. 행(901q)으로 표시된 CSR에 기입은 (예를 들어, PUMP 규칙 캐시 미스를 트리거했던 현재 명령어에 매칭하는) 규칙을 PUMP 규칙 캐시에 기입하게 한다. 행(901r)은 PUMP 동작을 위한 tagmod를 식별한다. tagmod는 본 명세서의 다른 곳에서 더 상세히 설명된다.
적어도 하나의 실시예에서, opgroup 및 care/don't care 비트를 저장하는데 사용되는 하나 이상의 표(예를 들어, opgroup/care 표)는 (901e)로 표시된 CSR sopgrpvalue에 기입함으로써 채워질 수 있으며, 이곳에서 전술한 CSR (901e)의 내용이 (901d)로 표시된 sopgrpaddr CSR에 저장된 어드레스에 기입된다. 규칙은 엔트리(901q)에 의해 정의된 srtag CSR 정의에 기입하는 것에 응답하여 PUMP 규칙 캐시에 기입되거나 설치될 수 있다. 기입된 규칙은 opcode (또는 보다 구체적으로는 opcode에 대한 opgroup) 및 현재 명령어에 대한 태그 값을 PUMP CSR(예를 들어, PUMP CSR 입력(901g 내지 901o)에 기초함)을 통한 PUMP로의 입력으로서 명시하는 규칙이다.
CSR 동작에 대해 태깅 및 태그 보호를 허용하기 위해, 데이터 흐름(dataflow)은 CSR 태그가 PUMP에 입력되게 하고, PUMP로부터 출력되게 한다. RISC-V 아키텍처에 따르면, 각각 CSR로부터 판독하고 CSR에 기입하는 판독 및 기입 명령어가 있다. PUMP를 갖는 CSR 명령어와 관련하여, PUMP로의 R2tag 입력은 현재 CSR 태그이다. CSR 판독/기입 명령어(예를 들어, csrrc, csrrci, csrrs, csrrsi, csrrw, csrrwi)는 두 개의 입력: (1) RD 및 (2) 명령어에 의해 참조되는 CSR을 기입한다. 이 경우, PUMP 출력 R 태그(또는 목적지의 RD 태그)는 PUMP에 의해 출력된 CSR 태그를 특정하고 CSRtag를 레지스터 목적지 태그에 직접 복사한다:
열(904)에 의해 표시된 권한과 관련하여, 행(901r)에 의해 정의된 CSR mtagmode는 머신 또는 M-모드 레벨에서 실행되는 코드에 의한 판독/기입을 위해 액세스 가능하다. 행(901a 내지 901q)에 의해 정의된 나머지 CSR은 적어도 슈퍼바이저 또는 S-모드 레벨에서 실행되는 코드에 의한 판독/기입을 위해 액세스 가능하다. 따라서, 다양한 CSR에 대해 열(904)에 표시된 권한은 코드가 특정 CSR에 액세스하기 위한 실행 코드의 최소한의 RISC-V 권한 레벨을 표시한다. 실시예는 예(900)에 도시된 바와 달리 실시예에서 사용한 CSR를 갖는 상이한 RISC-V 권한 레벨을 할당할 수 있다.
본 명세서의 기술에 따른 실시예는 PUMP에 의해 수행된 태그 전파에 영향을 미치는 다수의 태그 모드를 정의할 수 있다. 현재 태그 모드는 행(901r)에 의해 정의된 바와 같이 CSR mtagmode에 저장된 현재 시점의 값으로 식별된다. 적어도 하나의 실시예에서, 태그 모드는 RISC-V 정의된 권한(예를 들어, 위의 M, H, S 및 U 모드)과 조합하여 PUMP와 관련하여 사용되는 CSR 보호 모델을 정의하는데 사용될 수 있다.
규칙 캐시 미스 핸들러를 구성 가능하게 배치할 수 있도록 하기 위해, RISC-V 권한을 더 확장하는 보호 모델이 사용될 수 있다. 권한 레벨에 따라 PUMP CSR 액세스를 전체적으로 정의하는 대신, CSR 액세스는 RISC-V 권한 레벨과 조합하여 현재 태그 모드에 대해 추가로 정의될 수 있다. 따라서, 본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 실행 코드가 CSR에 액세스하도록 허용되는지는 CSR의 최소한의 RISC-V 권한 레벨, 현재 태그 모드 및 실행 코드의 현재 RISC-V 권한 레벨에 종속할 수 있다. 태그모드는 아래에서 더 상세히 논의된다.
도 26을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 태그 모드의 예가 도시된다. 테이블(910)은 다음과 같은 열 - mtagmode 비트 인코딩(912), 동작(914) 및 태그 결과(916)를 포함한다. 테이블(910)의 각 행은 서로 다른 가능한 태그 모드에 대한 정보를 나타낸다. 태그 모드가 (911a)로 표시된 000 일 때, PUMP는 오프이고 사용 중이 아니며 어떠한 태그 결과도 생성하지 않는다. 태그 모드가 010 일 때, PUMP는 모든 결과에 디폴트 태그(예를 들어, 목적지 또는 결과 레지스터 또는 메모리 위치에 대한 Rtag)를 기입한다.
행(911c 내지 911f)과 관련하여, 코드가 상이한 RISC-V 권한 레벨에서 실행되는 경우 PUMP를 연계하거나(engaging) 또는 연계 해지하기(disengaged) 위해 특정될 수 있는 상이한 태그 모드가 표시된다. PUMP가 연계될 때, PUMP는 코드가 실행됨으로써 그 정책의 규칙이 코드 실행 동안 실시될 때 활성, 작동 가능 및 보호를 제공하는 것으로 특징지을 수 있으며, 된다. 이에 반해, PUMP가 연계 해지될 때, PUMP는 코드가 실행되어 그 정책의 규칙이 코드 실행 중에 실시되지 않을 때 비활성, 작동 불가 및 보호를 제공하지 않는 것으로 특징지을 수 있다. PUMP가 연계 해지될 때, 태그는 현재 명령어의 태그 값과 매칭하는 태그 값을 갖는 규칙의 평가에 기초하여 전파된 태그를 갖는 대신 하나 이상의 디폴트 태그 전파 규칙을 사용하여 전파될 수 있다. PUMP가 연계되는지 또는 연계 해지되는지는 상이한 RISC-V 권한 레벨에서 실행되는 코드에 기인한 특정의 추정된 신뢰 레벨 및 원하는 보호 레벨에 따라 달라질 수 있다.
태그 모드(911c 내지 911f)와 관련하여, (901r)로 표시된 mtagmode CSR을 제외하고, 예(900)의 모든 PUMP CSR은 PUMP가 연계 해지될 때만 액세스 가능할 수 있다. 즉, (901r)로 표시된 mtagmode CSR을 제외한 예(900)의 PUMP CSR은 태그 모드에 의해 표시된 가장 높은 순위의 PUMP 권한보다 더 권한 있는 현재 RISC-V의 동작 권한 또는 모드에서 실행 가능한 코드에만 액세스 가능하다(예를 들어, (911c)에 의해 표시된 가장 높은 순위의 권한은 U 모드이고, (911d)에 의해 표시된 가장 높은 순위의 권한은 S 모드이고, (911e)에 의해 표시된 가장 높은 순위의의 권한은 H 모드이며, (911f)에 의해 표시된 가장 높은 순위의 권한은 M 모드이다).
(911c)에 의해 표시된 바와 같이 태그 모드가 100 일 때, PUMP는 RISC-V 권한 레벨이 U-모드보다 높거나 더 승격된 권한 레벨을 표시할 때 연계되지 않고 동작하지 않는다. 따라서, 태그 모드(911c)는 코드가 U-모드에서 실행될 때 PUMP 및 보호를 제공하는 그의 규칙이 유일하게 연계되어 시행되며, 그럼으로써 U-모드보다 높은 권한 레벨(예를 들어, S, M 또는 H 모드)에서 실행되는 코드가 신뢰성 있음을 나타낸다. (911c)에 의해 표시된 바와 같이 태그 모드가 100이고 실행 코드의 RISC-V 보호 레벨이 S, M 또는 H 모드일 때, PUMP는 연계되지 않으며 그의 CSR은 S, M 또는 H 모드에서만 실행되는 코드에 액세스할 수 있다(예를 들면, CSR은 U-모드에서 실행되는 코드에 액세스할 수 없다).
(911d)에 의해 표시된 바와 같이 태그 모드가 101 일 때, PUMP는 RISC-V 권한 레벨이 S-모드보다 높거나 더 승격된 권한 레벨을 표시할 때 연계 해지되고 동작하지 않는다. 따라서, 태그 모드(911d)는 코드가 S-모드 및 U-모드에서 실행될 때 PUMP 및 보호를 제공하는 그의 규칙이 유일하게 연계되어 시행되며, 그럼으로써 S-모드보다 높은 권한 레벨(예를 들어, M 또는 H 모드)에서 실행되는 코드가 신뢰성 있음을 나타낸다. (911d)에 의해 표시된 바와 같이 태그 모드가 101이고 실행 코드의 RISC-V 보호 레벨이 M 또는 H 모드일 때, PUMP는 연계 해지되고 그의 CSR은 M 또는 H 모드에서만 실행되는 코드에 액세스할 수 있다(예를 들면, CSR은 S 또는 U 모드에서 실행되는 코드에는 액세스할 수 없다).
(911e)에 의해 표시되는 바와 같이 태그 모드가 110 일 때, PUMP는 RISC-V 권한 레벨이 H-모드보다 높거나 더 승격된 권한 레벨을 표시할 때 연계 해지되고 동작하지 않는다. 따라서, 태그 모드(911e)는 코드가 H-모드, S-모드 및 U-모드에서 실행될 때 유일하게 연계되고 시행되며, 그럼으로써 H-모드보다 높은 권한 레벨에서(예를 들어, M 모드에서)에서 실행되는 코드가 신뢰성 있음을 나타낸다. (911e)에 의해 표시된 바와 같이 태그 모드가 110이고 코드를 실행하는 RISC-V 보호 레벨이 M 모드일 때, PUMP는 연결 해지되고 그의 CSR은 M 모드에서만 실행되는 코드에 액세스할 수 있다(예를 들면, CSR은 U, H 또는 S 모드에서 실행되는 코드에 액세스할 수 없다).
(911f)에 의해 표시된 바와 같이 태그 모드가 111 일 때, PUMP는 항상 연계되며 M, H, S 및 U의 모든 RISC-V 권한 레벨에 대해 동작한다. 따라서, 태그 모드(911f)는 코드가 M-모드, H-모드, S-모드 및 U-모드 중 어느 모드에서건 실행될 때 PUMP 및 보호를 제공하는 그의 규칙이 연계되어 시행됨을 나타내며, 그럼으로써 코드가 본질적으로 신뢰성 없음을 나타낸다. (911f)에 의해 표시된 바와 같이 태그 모드=111의 경우, PUMP는 절대로 연계 해지되지 않으며 그의 CSR은 모든 실행 코드에 액세스할 수 없다.
행(911c 내지 911f)에 의해 표시된 태그 모드와 관련하여, 코드를 실행하는 현재 RISC-V 권한 레벨이 태그 모드에 의해 표시된 가장 높은 연계된 PUMP 레벨보다 높을 때, PUMP는 연계 해지될 수 있고 태그는 하나 이상의 디폴트 태그 전파 규칙을 사용하여 전파될 수 있다.
(PUMP가 오프임을 나타내는) 행(911a)에 의해 표시되는 바와 같이 태그 모드가 000의 인코딩을 가질 때, 또는 (기입 디폴트 모드를 나타내는) 행(911b) 에 의해 표시되는 바와 같이 태그 모드가 010의 인코딩을 가질 때, 테이블(900)의 모든 CSR은 M 모드에서 실행되는 코드에 의해서만 액세스 가능하다.
따라서, 본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 실행 코드가 CSR에 액세스할 수 있게 되는지는 (테이블(900)의 열(904)에서 특정된 것과 같은) CSR의 최소 RISC-V 권한 레벨, 현재 태그 모드 및 실행 코드의 현재 RISC-V 권한 레벨에 종속할 수 있다. 예를 들어, 태그 모드를 고려하지 않은 RISC-V 아키텍처에서, U 모드에서 실행되는 코드는 그러한 모든 CSR에 대해 (904)에 의해 표시된 최소 권한 레벨로 인해 (900)에서 정의된 CSR 중 임의의 CSR에 액세스할 수 없다. 그러나, 태그 모드를 고려하지 않고, 적어도 H-모드의 권한으로 실행되는 코드는 (901r)을 제외한 (900)의 모든 CSR에 액세스할 수 있고 M 모드에서 실행되는 코드는 (900)의 모든 CSR에 액세스할 수 있다. 이제 (904)의 최소 RISC-V 권한 및 태그 모드에 따라 (900)의 CSR에 대한 CSR 액세스를 결정하는 것을 고려해본다. 예를 들어, H-레벨에서 실행되는 코드 부분 A를 고려해 본다. 코드 부분 A은 (911c)에 의해 표시된 바와 같이 태그 모드가 100 일 때 또는 (911d)에 의해 표시된 바와 같이 태그 모드가 101 일 때 (테이블(900)의) CSR(901a 내지 901q)에 액세스할 수 있다. 그러나, S 모드에서 실행되는 코드 부분 B는 그러한 CSR에 대해 정의된 CSR 권한 레벨에 의해 명시된 최소 권한 레벨을 갖고 있지 않기 때문에 CSR(901a 내지 901q)에 액세스할 수 없을 수 있다. 따라서, 예를 들어, 코드 부분 A는 테이블(900)에서 정의된 CSR을 사용하여 H-레벨에서 실행되는 일 실시예에서의 캐시 미스 핸들러일 수 있다. 제 2 예로서, CSR(901a 내지 901q)에 대해 정의된 최소 RISC-V 권한이 SRW(이러한 CSR에 액세스하는 최소 권한 레벨로 S 모드를 표시함)이라고 가정한다. H 모드에서 실행되는 코드 부분 A는 태그 모드가 (911c)에서와 같이 100일 때 및 (911d)에서와 같이 태그 모드가 101일 때, CSR (901a 내지 901q)에 액세스할 수 있고, S 모드에서 실행되는 코드 부분 B는 태그 모드가 (911c)에서와 같이 100일 때 CSR(901a 내지 901q)에 액세스할 수 있다. 따라서, 코드 부분 A 또는 B는 캐시 미스 핸들러의 코드일 수 있다.
적어도 하나의 실시예에서, (911a)의 오프 태그 모드는 예컨대 부트 업 프로세스의 적절한 부분 동안 PUMP가 오프일 때 현재 태그 모드일 수 있다. (예를 들어, CSR(901c)로 표시된) 동일한 디폴트 태그를 갖기 위해 메모리 위치를 초기화할 때, (911b)의 디폴트 태그 모드는 현재 태그 모드일 수 있다. 일반적으로, 4 권한 모드가 RISC-V 아키텍처에서 명시되었지만, 실시예는 제 1 권한 레벨이 사용자 모드 또는 권한 없는 모드를 나타내고 제 2 권한 레벨이 (예를 들어, UNIX 기반 오퍼레이팅 시스템의 커널 모드와 유사한) 승격된 또는 권한 있는 실행 모드를 나타내는 상이한 수의 권한 모드를 대안적으로 사용할 수 있다. 이러한 실시예에서, PUMP는 사용자 또는 권한 없는 모드에서 코드를 실행할 때 연계되어 정책을 실행할 수 있고, PUMP는 제 2 승격된 권한 모드에서 코드를 실행할 때 연계 해지(예를 들어, PUMP 보호 오프 또는 규칙 시행하지 않음)될 수 있다. 이러한 방식으로, 실시예는 새로운 규칙을 PUMP 규칙 캐시에 저장하기 위해 미스 핸들러와 같은 신뢰성 있는 또는 승격된 권한 코드를 실행할 때 PUMP를 연계 해지할 수 있다.
위에서 언급한 바와 같이, 실시예는 디폴트 전파 규칙을 사용하여, 예를 들어, PUMP가 연계 해지될 때 및/또는 규칙이 PUMP 출력인 newPCtag 및 Rtag에 대해 don't care를 명시할 때(예를 들어, 그러한 don't care 값은 현재 명령어의 특정 opcode에 대해 care 벡터에 의해 표시될 수 있다), PUMP 출력인 newPCtag 및 Rtag를 출력하는 것을 결정할 수 있다. 일 실시예에서, 다음은 사용되는 디폴트 전파 규칙에서 구현되는 로직을 나타낼 수 있다.
* newPCtag는 디폴트 전파를 위한 PCtag이다.
* Rtag는 CSR 판독 및 기입 동작을 위한 RS1tag이고; RDtag에는 RS2tag(CSRtag)가 할당된다.
- 태그가 데이터 값과 함께 스왑할 수 있게 한다
- RDtag <-- RS2tag <-- 원래 CSRtag
- CSRtag <-- Rtag <-- 원래 RS1tag
* Rtag는 CSRR?I, CSRRS, CSRRC에 대한 RS2tag(CSRtag)이다.
- CSRtag는 변경되지 않는다
- RDtag <-- RS2tag <-- 원래 CSRtag
- CSRtag <-- Rtag <-- 원래 RS2tag <-- 원래 CSRtag
* Rtag는 JAL 및 JALR 명령어를 위한 PCtag이다(이것은 리턴 어드레스를 위한 것이다). Rtag는 AUIPC 명령어를 위한 PCtag이다. RISC-V에서, AUIPC(add upper immediate to PC) 명령어는 PC-상대 어드레스를 구축하는데 사용되며 U-타입 포맷을 사용한다. AUIPC는 20-비트 U-이미디어트(immediate)로부터 32 비트 오프셋을 형성하고, 최하위 12 비트를 0으로 채우고, 이 오프셋을 PC에 가산한 다음, 결과를 레지스터 rd에 놓는다.
* Rtag는 LUI 명령어를 위한 CItag이다. RISC-V에서, LUI(load upper immediate) 명령어는 32 비트 상수를 구축하는데 사용되며 U-타입 포맷을 사용한다. LUI는 U-이미디어트 값을 목적지 레지스터 RD의 상위 20 비트에 놓고 최하위 12 비트를 0으로 채운다.
* Rtag는 비-메모리, 비 CSR, 비-JAL(R)/AUIPC/LUI 동작을 위한 RS1tag이다.
* Rtag는 메모리 기입 연산을 위한 RS2tag이다.
* Rtag는 메모리 로드 연산을 위한 Mtag이다.
RISC-V 아키텍처에 기초한 본 명세서에서의 기술의 적어도 하나의 실시예에서, 새로운 PUMP 미스 트랩(new PUMP miss trap)이 규칙 캐시 미스 발생에 대해 정의될 수 있다. PUMP 미스 트랩은 가상 메모리 결함(memory fault) 또는 위법 명령어보다 낮은 우선 순위를 가질 수 있다
RISC-V 아키텍처를 사용하는 본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 데이터와 메타데이터 간의 엄격한 분리 및 격리는 태그 메타데이터 처리와 정상 명령어 처리 사이에 분리 및 격리가 존재하는 경우에 유지될 수 있다. 따라서, 메타데이터 규칙 처리와 정상적인 또는 전형적인 프로그램 명령어 실행 사이의 별도의 실행 도메인이 유지될 수 있다. 명령어와 연관된 태그 및 코드를 실행하는 데이터에 대해 PUMP를 사용하여 수행되는 메타데이터 처리가 수행될 수 있다. PUMP 규칙 캐시 미스가 발생하면 현재 명령어와 매칭하는 규칙을 생성 또는 검색하여 그 규칙을 PUMP 규칙 캐시에 저장하는 규칙 캐시 미스 핸들러로 제어를 이전하게 하는 트랩이 유발된다. 정보는 CSR을 사용하여 위에서 언급한 실행 도메인들 사이에 전달될 수 있다. 실행중인 프로그램의 명령 실행 도메인으로부터 메타데이터 규칙 처리 도메인으로 전환할 때(예컨대 규칙 캐시 미스 핸들러가 규칙 캐시 미스 트랩을 통해 트리거될 때), 태그 및 (트랩을 유발하는) 명령어에 관련 있는 다른 정보는 PUMP로의 입력으로서 제공되며 또한 CSR을 사용하여 미스 핸들러로의 입력으로도 제공된다. 유사한 방식으로, 메타데이터 규칙 처리 도메인으로부터 실행중인 프로그램의 명령어 실행 도메인으로 제어를 이전할 때(예컨대, 규칙 캐시 미스 트랩을 처리한 후 규칙 캐시 미스 핸들러로부터 리턴할 때), PUMP 출력은 CSR을 사용하여 전달될 수 있고, 그 후 CSR의 내용은 명령어 실행 도메인의 대응하는 매핑된 레지스터에 저장된다. 본 명세서의 논의와 일관하여, 규칙에 매핑되지 않는 (예를 들어, 명령어에 매칭하는 규칙이 캐시에 놓여 있지 않고, 캐시 미스 핸들러가 현재 명령어에 대해 그러한 매칭 규칙이 존재하지 않는다고 결정하는) 명령어는 규칙이 실행되도록 허용되지 않고, 이에 따라 트랩이나 다른 이벤트가 트리거된다는 것을 나타낸다. 예를 들어, 프로세서는 현재 프로그램 코드의 실행을 중지할 수 있다.
이러한 방식으로, 비록 동일한 RISC-V 프로세서 및 메모리가 두 영역들 모두에서 사용될 수 있을지라도, 전술한 도메인 및 연관된 데이터 경로 사이에는 엄격한 분리가 존재할 수 있다. 본 명세서에서의 기술을 사용하면, 코드를 실행하는 어떠한 명령어도 메타데이터 태그 또는 규칙을 판독하거나 기입할 수 없다. 명령어 및 데이터에 태깅하는 것을 비롯한 모든 메타데이터 변환은 PUMP를 통해 수행될 수 있다. 유사하게, PUMP 캐시로의 규칙 삽입은 메타데이터 서브시스템의 규칙 캐시 미스 핸들러에 의해서만 수행될 수 있다. 메타데이터 서브시스템 또는 처리 시스템에 의해 수행되는 처리와 관련하여, 실행 코드의 메타데이터 태그는 PUMP CSR에 놓이고 메타데이터 시스템에 의해 "데이터" 입력이 되고 그에 대해 동작된다(예를 들어, 포인터는 메타데이터 메모리 공간을 가리킨다). 메타데이터 서브시스템은 PUMP 입력 CSR을 통해 규칙에 따라 처리를 위한 PUMP 입력을 판독한다. 명령어가 규칙을 통해 진행될 수 있으면, PUMP는 (예를 들어, PC new 및 R tag에 대한) 태그 결과를 정의된 PUMP 출력 CSR에 기입한다. 규칙 캐시로의 규칙 삽입은 (예를 들어, (901q)의 srtag CSR과 같은) 특정 CSR에 기입하는 것에 응답하여 트리거될 수 있다. 이러한 방식으로, 모든 태그 업데이트는 PUMP의 규칙을 통해 수행되고 메타데이터 서브시스템에 의해 제어된다. 오직 메타데이터 서브시스템만이 규칙 캐시 미스의 발생시 호출되는 캐시 미스 핸들러를 통해 PUMP 캐시에 규칙을 삽입할 수 있다. 또한, RISC-V 아키텍처를 사용하는 본 명세서에 설명된 적어도 하나의 실시예에서, 메타데이터 처리와 정상적인 명령어 처리 간의 전술한 분리는 "RISC-V 사용자 레벨 ISA" 및 "RISC-V 권한 있는 ISA"의 명령어 이외의 임의의 새로운 명령어를 추가하지 않고 유지될 수 있다. 본 명세서의 다른 곳에서의 논의와 일관하여, 본 명세서에서의 기술에 따른 실시예는 데이터와 메타데이터 사이의 엄격한 분리 및 격리를 유지하며, 이것에 의해 태그에 기초한 메타데이터 처리와 정상적인 명령어 처리 사이의 분리가 존재할 수 있다. 적어도 하나의 실시예에서, 이러한 분리는 별도의 프로세서 및 별도의 메모리를 갖는 별도의 물리적 메타데이터 처리 서브시스템을 가짐으로써 유지될 수 있다. 따라서, 제 1 프로세서 및 제 1 메모리는 실행 프로그램의 명령어를 처리할 때 사용될 수 있고, 제 2 프로세서 및 제 2 메모리는 예컨대 규칙 캐시 미스 핸들러의 코드를 실행할 때 메타데이터 처리의 수행과 함께 사용하기 위해 메타데이터 처리 서브시스템에 포함될 수 있다.
도 27을 참조하면, 본 명세서에서의 기술에 따른 실시예에 포함될 수 있는 컴포넌트의 예(1000)가 도시된다. 예(1000)는 실행 프로그램 및 메타데이터 처리 서브시스템 또는 프로세서(1004)에 대한 정상적인 처리와 관련하여 사용되는 제 1 서브시스템 또는 프로세서(1002)를 포함한다. 제 1 서브시스템(1002)은 정상적인 프로그램 실행과 관련하여 사용되는 프로그램 실행 서브시스템으로 특징지을 수 있다. 서브시스템(1002)은 프로그램 코드를 실행하는 것 및 데이터를 사용하는 것과 관련하여 사용되는 컴포넌트를 포함하는 프로세서이며, 그러한 코드 및 데이터는 메타데이터 처리 서브시스템(1004)과 함께 사용하기 위해 본 명세서의 다른 곳에서 기술된 바와 같이 태그를 포함한다. 서브시스템(1002)은 메모리(1008a), 명령어 또는 I-스토어(1008b), ALU(산술 및 로직 유닛)(1008d) 및 프로그램 카운터(PC)(1008e)를 포함한다. PUMP(1003)는 서브시스템(1002)에서 코드의 실행과 관련하여 사용될 수 있지만 메타데이터 처리 서브시스템(1004)의 부분으로서 고려될 수 있음을 유의하여야 한다. 서브시스템(1002)에서의 모든 코드 및 데이터는 데이터(1002b)와 연관된 태그(1002a)에 의해 일반적으로 표시되는 바와 같이 태깅될 수 있으며, (1002a 및 1002b)는 메모리(1008a)에 저장될 수 있다. 마찬가지로, 요소(1001a)는 PC(1008e)의 명령어의 태그를 나타내고, (1001b)는 명령어(1008b)의 태그를 나타내고, (1001c)는 메모리 위치(1008a)의 태그를 나타내고, (1001d)는 레지스터(1008c)의 태그를 나타낸다.
메타데이터 처리 서브시스템(1004)은 현재 명령어의 태그 및 PUMP(1003)로의 입력으로서 제공된 연관된 데이터를 사용하여 메타데이터 규칙 처리와 관련하여 사용되는 컴포넌트를 포함하는 프로세서(메타데이터 프로세서라고도 지칭함)이다. PUMP(1003)는 본 명세서의 다른 곳에서 설명된 바와 같을 수 있고 규칙 캐시를 포함한다. 예를 들어, 적어도 하나의 실시예에서, PUMP(1003)는 도 22에 도시된 컴포넌트를 포함할 수 있다. PUMP(1003)의 컴포넌트, PUMP 입력 및 출력에 사용된 연관된 PUMP CSR 및 본 명세서에서의 기술에 따른 적어도 하나의 실시예에 포함될 수 있는 연관된 로직의 보다 상세한 설명 및 예는 아래에서 그리고 본 명세서의 다른 곳에서 더 상세하게 설명된다. 서브시스템(1004)은 메타데이터 처리를 위해 사용되는 별도의 프로세서이고 서브시스템(1002)의 컴포넌트와 유사한 컴포넌트를 포함한다. 서브시스템(1004)는 메모리(1006a), I-스토어(1006b), 레지스터 파일(1006b) 및 ALU(1006d)를 포함한다. 메모리(1006a)는 메타데이터 규칙 처리와 관련하여 사용되는 메타데이터 구조체를 포함할 수 있다. 예를 들어, 메모리(1006a)는 포인터인 태그가 가리키는 구조체 또는 데이터를 포함할 수 있다. 포인터 태그 및 포인터 태그가 가리키는 구조체/데이터의 예는 예컨대 CFI 정책과 관련하여 본 명세서에 설명된다. I-스토어(1006b) 및 메모리(1006a)는 메타데이터 처리를 수행하는 미스 핸들러와 같은 명령어 또는 코드를 포함할 수 있다. 메타데이터 프로세서(1004)는 (예를 들어, 태그 및 규칙에 기초하여) 메타데이터 처리만을 수행하기 때문에, 메타데이터 프로세서(1004)는 프로그램 실행과 관련하여 사용되는 데이터 메모리(1008a)와 같은, (1002)의 다른 컴포넌트에 액세스할 필요가 없다. 서브시스템(1004)은 별도의 메모리(1006a)와 같은 자체의 컴포넌트를 포함하고, 메타데이터 처리 코드 및 데이터를 서브시스템(1002)에 저장할 필요가 없다. 오히려, PUMP(1003)에 의해 사용될 수 있는 현재 명령어의 태그와 같은 모든 정보는 메타데이터 처리 서브시스템(1004)의 입력(예를 들어, PUMP 입력(1007))으로서 제공된다.
예(1000)는 본 명세서의 다른 곳에서 설명된 정상적인 프로그램 실행을 위해 사용되는 것과 동일한 서브시스템 상에서 메타데이터 처리를 수행하기보다는 별도의 메타데이터 처리 서브시스템(1004)을 갖는 대안적인 실시예를 도시한다. 예를 들어, 별도의 메타데이터 프로세서 또는 서브시스템(1004)을 갖는 대신, 실시예는 PUMP(1003) 및 서브시스템(1002)만을 포함할 수 있다. 단일 프로세서를 갖는 그러한 실시예에서, CSR은 본 명세서에서 설명된 바와 같이 메타데이터 처리 및 사용자 프로그램을 실행하는 정상 처리 모드 사이에서 정보를 전달하는데 사용될 수 있음으로써, 격리 및 분리를 제공할 수 있다. 별도의 메타데이터 프로세서 대신 단일 프로세서를 갖는 그러한 실시예에서, 미스 핸들러의 코드는 코드가 보호되도록 하는 방식으로 단일 메모리에 저장될 수 있다. 예를 들어, 별도의 메타데이터 프로세서 또는 서브시스템 없이, 미스 핸들러의 코드는 액세스를 제한하기 위해 본 명세서의 다른 부분에서 설명된 바와 같이 태그를 사용하여 보호될 수 있거나, 사용자 코드에 의해 어드레스 가능하지 않는 메모리의 일부분에 매핑될 수 있다.
이제 PUMP I/O(input/output)(입력/출력)에 관한 더 세부 사항이 설명된다. 아래에서 설명되는 PUMP I/O는 예를 들어 정상적인 코드 실행을 위해 동일한 프로세서 또는 서브시스템을 사용할 수 있는 PUMP의 실시예뿐만 아니라 (1000)에서와 같은 별도의 프로세서 또는 서브시스템을 사용할 수 있는 실시예에 적용된다는 것을 유의하여야 한다. 또한, 아래에서 설명되는 PUMP I/O는 RISC-V 아키텍처에 기초한 실시예와 함께 사용될 수 있고 다른 프로세서 아키텍처와 함께 사용하기 위해 일반화될 수 있다.
도 28을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 PUMP I/O를 요약하는 예(1010)가 도시된다. 예컨대 도 1 및 도 24와 관련하여 본 명세서의 다른 곳에서 설명한 바와 같이, PUMP는 스테이지(5 및 6)에서 동작한다. PUMP 입력은 정상적인 PUMP 검증(예를 들어, 현재 명령어가 정책 규칙을 사용할 수 있는지를 검증)과 관련하여, 일치하는 규칙(있는 경우)을 현재 명령어에 대한 PUMP의 규칙 캐시에서 찾는데 사용된다. 정상적인 PUMP 검증은 6 스테이지 파이프라인을 갖는 본 명세서의 다른 부분에서 설명한 바와 같이 스테이지 5에서의 일부와 같은 모든 명령어에 대해 발생할 수 있다. 또한, PUMP 입력은 예컨대 6 스테이지 파이프라인의 스테이지 6에서 발생할 수 있는, 규칙 캐시로의 규칙 삽입 제어와 관련하여 사용될 수 있다. 정상적인 PUMP 검증과 연관된 PUMP I/O는 상단(입력(1012))으로부터 하단(출력(1014))으로의 수직 방향의 입력 및 출력에 의해 표시된다. PUMP 규칙 캐시에 규칙 삽입을 제어하는 것과 연관된 PUMP I/O는 예(1010)에서 좌측(입력(1016))으로부터 우측(출력(1018))으로의 수평 방향의 입력 및 출력에 의해 표시된다. 또한, 다른 곳에서 더 상세히 설명된 바와 같이, 요소(1012)는 규칙 삽입과 관련하여 사용되기도 하는 추가 입력을 나타낸다.
먼저, 정상적인 PUMP 검증 처리와 연관된 PUMP I/O를 고려해 본다. PUMP 입력(1012)은 PC tag, CI tag, 명령어 오퍼랜드 태그(예를 들어, (RISC-V 내의 CSR 기반 명령어에 대한) OP1 tag, OP2 tag 또는 CSR tag), OP3 tag, (메모리 명령어에 대한 메모리 위치에 대한) Mtag(Mtag는 또한 본 명세서에서 메모리 명령어에 대한 MR 태그로서 지칭될 수 있음을 유의할 것), opcode 정보(예를 들어, Opgrp 입력으로 표시된 op group, 확장된 opcode의 RISC-V에 대한 funct12(funct7) 입력, 그의 명령어가 예(200 및 220)에서와 같은 다수의 명령어를 포함하는 명령어 워드에서 현재 명령어인 표시자를 제공하는 subinstr 입력) 및 care 입력 비트를 포함할 수 있다. Opgrp는 현재 명령어에 대한 opgroup일 수 있으며, 본 명세서의 다른 곳에서 설명된 바와 같이 Opgrp는 앞의 스테이지(예를 들어, 스테이지 3 또는 스테이지 4)의 출력일 수 있다. Funct 12 (funct 7) PUMP 입력은 명령어 워드의 추가 비트를 사용하는 그러한 RISC-V opcode에 대한, 만일 있다면, 추가 opcode 비트일 수 있다(예를 들어, 예(400)). PUMP 출력(1014)은 Rtag(예를 들어, 명령어 결과 레지스터 또는 목적지 메모리 위치에 대한 태그), PC new tag(다음 명령어를 위해 사용된 PC 상에 놓인 전파된 태그를 나타냄), 및 스테이지 6에서 미스 핸들러로의 트랩을 초래하는 PUMP 규칙 캐시 미스가 있었는지를 나타내는 표시자(1014a)를 포함할 수 있다.
care 비트(1012a)는 특정 명령어에 대해 어떤 PUMP 입력(1012) 및 어떤 PUMP 출력(1014)이 관심 있는지(cared)/관심 없는지(not cared)(예를 들어, 무시되는지)를 나타낼 수 있다. PUMP 입력에 관한 care 비트는 funct12에 대한 care 비트와 funct7에 대한 제 2 care 비트를 포함할 수 있다. 본 명세서의 다른 곳에서 설명된 바와 같이, 전술한 care 비트 둘 모두는 현재 명령어의 특정 opcode가 RISC-V 명령어에 대해 확장된 12 opcode 비트 부분에 대한 임의의 비트를 포함하는지를 나타낸다(예를 들어, 예(400)의 (404a)). funct12 및 funct7 care 비트 둘 모두가 "don't care"이면, 확장된 12 opcode 비트 부분의 모든 12 비트가 마스킹된다(masked-out). funct7이 "care"를 표시하면, 확장된 12 opcode 비트 부분의 아래쪽 5 비트가 모두 마스킹된다. funct12가 "care"를 표시하면, 확장된 12 opcode 비트 부분에 대해 마스킹은 없다.
이제 PUMP 규칙 캐시로의 규칙 삽입을 제어하는 것과 연관된 PUMP I/O를 고려해 본다. PUMP 입력(1016)은 PUMP 캐시 규칙 삽입과 관련하여 입력(1012)과 조합하여 사용될 수 있다. PUMP 입력(1016)은 Op1 데이터(메타데이터 프로세서 또는 서브시스템으로부터의 출력), (스테이지 6으로부터의) 명령어, 및 태그 모드(메타데이터 프로세서 또는 서브시스템으로부터의 출력)와 권한(RISC-V 권한을 표시하는 priv)를 포함할 수 있다. (1016)의 태그 모드 및 priv 입력은 메타데이터 프로세서 또는 서브시스템에 의해 사용되어, 메타데이터 프로세서에서 실행되는 미스 핸들러 또는 다른 코드와 같은 코드가 (예를 들어, 입력(1012)과 같은) 다양한 입력을 메타데이터 프로세서에 제공하는, 아래에서 그리고 본 명세서의 다른 곳에서 설명되는 CSR에 액세스하기에 충분한 권한을 갖는지를 결정한다. Rdata(1018)는 스테이지 6에서 사용하기 위한 메타데이터 프로세서 또는 서브시스템으로의 입력(예를 들어, 캐시 미스 핸들러 처리 입력)이다. Op1 데이터, R 데이터 및 예(1010)의 다른 아이템은 다음 단락과 도면에서 보다 상세히 설명된다.
따라서 일반적으로, 예(1010)에서, 요소(1012)는 PUMP 및 사용자 코드를 실행하는 프로세서(예를 들어, (1002)와 같은 비-메타데이터 프로세서 또는 서브시스템)로의 입력을 나타내고, 요소(1014)는 메타데이터 프로세서에 의해 발생된 출력을 나타내고, 요소(1016)는 PUMP로의 메타데이터 프로세서 입력에 의해 발성된 출력을 나타내며, 요소(1018)는 메타데이터 프로세서로의 입력을 나타낸다.
도 29를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 opgroup/care 테이블(예를 들어, 예(420)의 요소(422))과 관련하여 I/O를 요약한 예(1020)가 도시된다. 본 명세서의 다른 부분에서 설명된 바와 같이, opgroup/care 테이블은 각 명령어에 대해 현재 명령어의 opcode에 대한 opgroup 및 care 비트를 룩업하고 출력하는데 사용될 수 있다. I/O의 이러한 제 1 흐름은 (1020)에서 상단(입력(1022))으로부터 하단(출력(1024))으로의 수직 방향의 입력 및 출력에 의해 도시된다. 본 명세서의 다른 곳에서 설명된 바와 같이, 입력(1022)은 opcode/care 테이블에 인덱스를 사용하는 (예를 들어, 예(420)의 opcode 부분의 예와 관련하여 설명된 것과 같은) opcode 또는 그 일부분일 수 있다. 입력(1022)은 스테이지 3으로부터 온 것일 수 있다. 출력(1024)은 특정 opcode에 대한 opgroup(opgrp) 및 care 비트일 수 있다. 출력(1024)은 스테이지 5 로의 입력(예를 들어, (1012)에 포함되어 있는 PUMP 입력 opgrp 및 care의 두 개)이다.
I/O의 제 2 흐름은 (1020)에서 좌측(입력(1026))으로부터 우측(출력(1028))으로의 수평 방향으로의 입력 및 출력에 의해 도시된다. (1020)에서 I/O의 제 2 흐름은 메타데이터 프로세서 또는 스테이지(6)에 입력되는 PUMP 출력 Rdata(1028)의 선택을 제어하는 것과 관련하여 수행되는 처리의 예시이다. 입력(1026)은 (1016)과 관련하여 전술한 바와 같다. 출력(1028)은 (1018)과 관련하여 위에서 설명된 바와 같다.
도 30을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 PUMP에 의해 수행되는 처리를 추상적으로 나타내는 예(1030)가 도시된다. 예(1030)는 예(1010)에서 수평 PUMP I/O 흐름(예를 들어, 요소(1012, 1016 및 1018))와 관련하여 전술한 규칙 삽입을 위한 PUMP 제어에 대응하는 PUMP 제어(1031)를 포함한다. 예(1030)는 마스킹(1032), 해시(1034), 규칙 캐시 룩업(1036) 및 출력 태그 선택(1038)을 포함하며, 출력 태그 선택은 예(1010)에서 수직 PUMP I/O 흐름(예를 들어, 요소(1012 및 1014))과 관련하여 전술한 바와 같이 각각의 명령어에 대해 수행된 정상적인 PUMP 검증 경로 I/O 흐름에 대응한다. 마스킹(1032)은 (1012)의 사용되지 않는 PUMP 입력을 마스킹하기 위해 (1012)의 care 비트를 적용하는 것을 나타낸다. 해시(1034)는 (1036)으로 표시된 규칙 캐시 룩업 동안 사용된 해시의 계산을 나타낸다. 일 실시예에서 (1032, 1034 및 1036)에 의해 표시된 로직을 구현하는데 사용될 수 있는 컴포넌트는 도 22와 관련하여 도시되고 설명된다. 출력 태그 선택(1038)은 케어 벡터 비트(입력(1012)에 포함된 care) 및 (현재 태그 모드를 나타내는) htagmode CSR에 기초하여 (1014)에 포함된 PUMP 출력(Rtag 및 PC new tag)의 선택을 나타낸다.
도 31을 참조하면, 본 명세서에서의 기술에 따른 일 실시예에서 PUMP의 출력 태그 선택(1038)의 로직을 구현하는데 사용될 수 있는 컴포넌트를 나타내는 예(1040)가 도시된다. 예(1040)는 멀티플렉서(MUX)(1043a-1043b)를 포함한다. 일반적으로, MUX(1043a)는 PUMP에 의한 출력(예를 들어, (1014)의 PCnew tag)으로서 PCnew tag(1043)에 대한 최종 태그 값을 선택하는데 사용될 수 있고, MUX(1043b)는 PUMP에 의한 출력(예를 들어, (1014)의 Rtag)으로서 Rtag(1047)에 대한 최종 태그 값을 선택하는데 사용될 수 있다. 요소(1042)는 MUX(1043a)에 대해 선택기로서 사용되는 입력을 나타낸다. 입력(1042)은 PCnew tag(1043)로서 (1041a) 또는 (1041b) 중 하나를 선택하기 위해 사용된다. 입력(1042)은 연계된(PUMP가 연계되는지를 나타내는 부울)과 논리적으로 AND(&&)된 (예를 들어, (1012)의 케어 비트로부터의) PCnew tag 케어 비트를 포함할 수 있다. 요소(1043)는 MUX(1043b)에 대해 선택기로서 사용되는 입력을 나타낸다. 입력(1043)은 (1045a-1045b)에 의해 표시된 입력 중 하나를 Rtag(1047)로서 선택하는데 사용된다. 입력(1043)은 engaged와 논리적으로 AND($$)된 (예를 들어, (1012)의 케어 비트로부터의) Rtag care 비트를 포함할 수 있다. 따라서, 일반적으로 PUMP 입력(1012)에 포함된 care 비트는 어떤 PUMP 입력이 don't care인지(마스킹되는지) 및 어떤 PUMP 출력(Rtag 및 PCnew tag)이 don't care인지(마스킹되는지)를 식별한다. 또한, 프로세서가 현재 tagmode가 PUMP 동작에 대한 문턱치로서 명시하는 것보다 높은 권한 레벨에서 실행되기 때문에 PUMP가 연계 해지될 때 출력(1043 및 1047)은 "don't care" 값으로 처리된다.
요소(1049)는 부울 engaged가 현재 RISC-V 권한 및 현재 tagmode의 함수로서 결정되는 방법을 나타낸다. 요소(1049)는 관련 기술분야에서 공지된 표준 표기법을 사용하는 논리적 표현을 포함하며, 이에 의하면 "A == B"는 A와 B 간의 균등 여부에 관한 논리적 검사를 나타내고, "A && B"는 A와 B의 논리 AND 연산을 나타내며, "A || B"는 A와 B 사이의 논리 배타 OR 연산을 나타낸다.
요소(1041a 및 1045a)는 규칙 캐시 룩업(1036)으로부터의 출력인 (1043a)으로의 입력을 나타낸다. PC tag(1041b)는 PUMP 입력(1012)에 포함된 PC 태그이다. 다른 입력(1041b)은 일반적으로 PUMP에 의해 출력된 아마도 최종 Rtag(1047))로서 선택될 수 있는 다수의 다른 입력이다. 예를 들어, 일 실시예에서, 다른 입력(1041b)은 명령어에 따라 M tag, PC tag, CI tag, OP1 tag, OP2 tag, OP3 tag 및 가능하게는 다른 것들을 포함할 수 있다. 특정 Rtag 출력(1047)은 특정 RISC-V 명령어/opcode에 따라 변할 수 있다.
다음은 일 실시예에서 PUMP 출력 값으로서 발생된 Rtag(1047) 및 PCnew tag(1043)에 대한 특정 값을 요약할 수 있다. 다음은 RISC-V 명령어가 상이한 경우의 특정 R tag 출력 값을 나타낸다는 것을 주목하여야 한다. 따라서, 최종 PUMP R tag 값으로서 출력된 특정 R tag 값은 후속 메타데이터 처리와 관련하여 그러한 PUMP 출력을 이용하는 명령어에 따라 변할 수 있다.
1. PCtag는 출력 케어 비트가 Pc new tag에 대해 꺼져있을 때 변경되지 않는다.
2. Rtag는 CSRRW 동작을 위한 Op1tag이다.
3. Rtag는 CSRR?I, CSRRS, CSRRC 동작을 위한 Op2tag(CSRtag)이다.
4. Rtag는 JAL 및 JALR 명령어에 대한 PCtag이다.
5. Rtag는 AUIPC 명령어에 대한 PCtag이다.
6. Rtag는 LUI 명령어에 대한 CItag이다.
7. Rtag는 출력 케어 비트가 오프일 때(Rtag에 대해 care임을 표시함) 비 메모리, 비-CSR, 비-JAL(R)/AUIPC/LUI 동작을 위한 Op1tag이다.
8. Rtag는 출력 care bit가 off일 때 메모리 기입 동작을 위한 Op2tag이다.
9. Rtag는 출력 케어 비트가 오프일 때 메모리 로드 동작을 위한 Mtag이다.
도 32를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 PUMP I/O를 제어하는데 사용될 수 있는 컴포넌트의 예(1050)가 도시된다. 일반적으로, 예(1030)을 다시 참조하면, (1050)의 컴포넌트는 논리적으로 (1032)의 최상부에 (예를 들어, 도 22의 컴포넌트와 인터페이스하는) 또 다른 계층을 포함할 수 있다. 요소(M1 내지 M14)는 다양한 입력을 선택하기 위해 사용되는 멀티플렉서를 나타낸다. 요소(1052)는 일반적으로 현재 명령어에 대해 (1012)로부터의 입력 opcode인 PC tag, CI tag, Op1 tag, Op2 tag, Op3 tag 및 M tag를 나타낸다. 요소(1056)는 일반적으로 멀티플렉서(M1 내지 M7)의 선택된 출력을 저장하는데 사용되는 레지스터들의 행을 지칭한다. RISC-V 아키텍처에 기초한 일 실시예에서, 행(1056)에서 각각의 박스는 레지스터일 수 있고, 특히 본 명세서의 다른 곳(예를 들어, 일 실시예에서 사용될 수 있는 CSR을 나타내는 예(900))에서 설명된 바와 같은 특정 값을 포함하는 CSR일 수 있다.
예(1050)의 요소(1052)는 (1012)의 모든 입력을 포함하지 않는다는 것을 유의하여야 한다. 예를 들어, funct12(funct7) 및 (1012)의 subinstr 입력은 간략화를 위해 예(1050)에 도시되지 않았다. 그러나, 관련 기술분야에서 통상의 기술자라면 (1012)로부터의 입력 funct12(funct7) 및 subinstr가 또한 (1052)에 포함될 수 있음을 알고 있다. 보다 일반적으로, 입력(1052)은 실시예에서 사용될 수 있는 메타데이터 규칙 처리를 위한 특정 입력에 적용될 수 있다.
PUMP가 정상적인 PUMP 검증(예를 들어, 현재 명령어가 정책 규칙을 사용할 수 있는지를 검증)에 대한 처리를 수행할 때, 입력(1052)은 간단히 출력(1054)으로서 통과할 수 있다. 이 경우 출력(1054)은 메타데이터 처리를 위한 도 22의 컴포넌트로의 입력과 같은 입력으로서 PUMP로 통과한다(또는 보다 일반적으로는 메타데이터 프로세서 또는 서브시스템으로 통과한다). 정상적인 PUMP 검증에 따라, PUMP는 출력(1014)을 생성할 수 있다(예를 들어, 현재 명령어에 대한 매칭 규칙이 규칙 캐시에서 발견되면 Rtag 및 PC new tag를 발생하고, 그렇지 않으면 캐시 미스(1014a)를 발생한다).
규칙 캐시 미스가 발생하면, 제 1 단계로서, 현재 명령어에 대해 (1052)로부터의 현재 값은 (1056)의 레지스터(G1 내지 G7)에 로드된다. 따라서, (G1 내지 G7)은 규칙 캐시 미스를 유발했던 현재의 명령어에 대한 opcode 및 tag 값의 스냅샷을 포함하며 그러한 값은 이제 그러한 처리를 하기 위한 필요에 따라 (G1 내지 G7)의 하나 이상의 원하는 값을 판독하는 캐시 미스 핸들러에 의한 후속 처리와 관련하여 사용될 수 있다.
따라서, 제 2 단계에서, 캐시 미스 핸들러는 실행하고, (G1 내지 G7)로부터 입력 값으로서 판독하고, 현재 명령어에 대한 새로운 규칙을 발생한다. 멀티플렉서(M16)는 (M10)으로부터의 선택된 출력이 (예를 들어, 프로그램 코드를 실행하는 때와 동일한 프로세서에서 실행될 수 있거나, 그렇지 않으면 예(1000)에서와 같이 별도의 메타데이터 프로세서에서 실행될 수 있는) 캐시 미스 핸들러에 의해 처리하기 위한 R data(1053)로 표시되는 (G1 내지 G7)로부터의 다양한 가능한 입력의 선택을 제어하는데 사용될 수 있다. 규칙 캐시 미스를 야기하는 현재 명령어에 대한 입력(G1 내지 G7)이 주어지면, 캐시 미스 핸들러는 캐시에 삽입될 새로운 규칙을 결정하는 처리를 수행한다. 캐시 미스 핸들러는 방금 결정된 새로운 규칙에 대한 출력인 R tag 및 PC new tag를 발생하고 Rtag를 Rtag CSR(G8)에 기입하고, PC new tag를 PC new CSR(G9)에 기입한다. 예(1050)에서, Op1 data(1051)는 새로운 규칙에 대해 메타데이터 프로세서에 의해 발생된 출력(Rtag 및 PC new tag)과 같은 출력을 나타내며, 그러한 출력은 설명된 바와 같이 CSR(G8 및 G9)에 저장된다.
이때, CSR(G1 내지 G9)의 값은 캐시 미스 핸들러에 의해 발생된 새로운 규칙의 태그 값이며 제 3 단계에서 새로운 규칙으로서 규칙 캐시에 삽입/기입될 수 있다. RISC-V 아키텍처와 함께 본 명세서에서의 기술을 사용하는 적어도 하나의 실시예에서, G8에 의해 표시된 R tag CSR에 기입은 새로운 규칙(예를 들어, CSR(G1 내지 G9)의 내용)을 규칙 캐시에 기입하도록 트리거한다. 규칙 삽입과 관련하여, CSR(G1 내지 G7)은 출력(1052)으로서 제공되고, CSR(G8 및 G9)은 규칙 캐시에 저장을 위해 출력(1055)으로서 PUMP에 제공된다. 보다 구체적으로, 일 실시예에서, 출력(1052 및 1055)은 규칙 삽입을 위해 도 22의 컴포넌트에 제공될 수 있다.
간단한 사례에서, 실시예는 방금 설명된 바와 같이 (예를 들어, 출력(1052 및 1055)을 통해) 새로운 규칙에 대한 CSR(G1 내지 G9)의 내용들을 PUMP 규칙 캐시에 기입함으로써 현재 규칙 미스를 충족하는 하나의 새로운 규칙을 삽입할 수 있다. 이러한 실시예에서, 캐시 미스 핸들러를 실행하는 메타데이터 규칙 프로세서에 의해 출력된 Op1 data(1051)는 새로운 규칙에 대한 R tag 및 PC new tag만을 발생하기 때문에 멀티플렉서(M1 내지 M7)는 필요하지 않다. 그러나, 실시예는 다수의 규칙을 프리페칭하거나 규칙 캐시에 다수의 규칙을 삽입하는 것을 또한 가능하게 한다. 예를 들어, 규칙 캐시 미스의 발생시, 캐시 미스 핸들러는 현재 명령어에 대한 하나의 새로운 규칙 대신에 규칙 캐시에 기입/삽입 될 다수의 규칙을 결정할 수 있다. 이 경우, Op1 data(1051)는 (CSR(G1 내지 G7에 기입된) opcode, PCtag, CItag, Op1tag, Op2tag, Op3tag 및 Mtag 에 대한 추가의 새로운 값뿐만 아니라 (CSR(G8 및 G9)에 기입되는 것으로서) Rtag 및 PC new tag에 대한 새로운 값을 포함할 수 있다. 이러한 경우, 멀티플렉서(M1 내지 M7)는 CSR(G1 내지 G7)에 대한 입력으로서 Op1 data(1051)로부터의 상기 새로운 값을 각각 선택하기 위해 사용될 수 있다.
일반적으로, Op1 data(1051)는 메타데이터 프로세서로부터 PUMP 로의 출력을 나타내고, R data(1053)는 PUMP로부터 메타데이터 프로세서로의 출력을 나타낸다. 또한, 요소(1052)는 정상적 PUMP 검증을 수행할 때(예를 들어, 현재 명령어가 정책 규칙을 사용하는 것이 가능한지를 검증할 때) 요소(1054)의 값이 (1052)에서와 같은 값과 동일한 사용자 코드를 (예를 들어, 정상적인 명령어 처리의 일환으로서) 실행하는 프로세서로부터 PUMP로의 입력을 나타낸다.
도 33을 참조하면, 분기 예측(branch prediction)을 하는 RISC-V 아키텍처를 갖는 본 명세서에서의 기술에 따른 일 실시예에서 6 스테이지 프로세서 파이프라인과 조합된 PUMP 처리 스테이지를 도시하는 예(1060)가 도시된다. 예(1060)은 6 스테이지 파이프라인을 도시하는데, 스테이지 1은 실행될 다음 명령어(예를 들어, 페치된 명령어를 I 캐시(1063a)에서 저장하는 것) 및 분기 예측을 페치하는 것을 포함하고, 스테이지 2는 디코드 명령어 스테이지를 나타내고, 스테이지 3은 레지스터로부터 값을 획득(예를 들어, 레지스터 판독)하고 현재 명령어에 대한 분기 해결(branch resolution)을 획득하는 것을 포함하고, 스테이지 4는 명령어 실행(예를 들어, 고속 ALU 연산을 실행하고 부동 소수점(floating point, FP), 정수 곱셈 및 나눗셈과 같은 다단계 연산을 시작함)을 포함하고, 스테이지 5는 다중 스테이지 동작에 대한 응답을 수신하는 것을 포함하며, 스테이지 6은 명령어를 커밋(commit)하는 것(예를 들어, (1069)에 의해 표시된 바와 같이 결과를 목적지 및 데이터 캐시(1063b)에 저장하는 것) 및 예외, 트랩 및 인터럽트를 처리하는 것을 포함한다. 또한 예(1060)에는 PUMP 처리 단계가 도시된다. 요소(1062)는 opgrp/care 테이블 룩업이 스테이지 3에서 수행될 수 있음을 나타내며, 이때 출력(1062a)는 스테이지 4에서 PUMP 해시(1064)로의 입력으로서 제공된다. PUMP 해시(1064)로의 다른 입력은 Mtag(1061)(예를 들어, 현재 명령어에 대한 피연자인 메모리 위치의 태그) 및 다른 태그 값(1062b)을 포함하며, 이에 의해 입력(1061 및 1062a-1062b)는 PUMP 규칙 캐시(1066)의 캐시 어드레스 또는 위치를 나타내는 출력(1064a)을 결정하는데 사용된다. 명령어 오퍼랜드의 다른 태그 값(1062b), PC, 현재 명령 등의 예는 본 명세서의 다른 곳에서 설명되며, 현재 명령어에 대해 규칙 캐시(1066) 내의 위치를 결정하는 것과 관련하여 사용될 수 있다(예를 들어, 도 22). 요소(1068)는 스테이지 5로부터 PUMP 처리의 출력(1066a)에 기초한 캐시 규칙 미스 검출을 나타낸다. 출력(1066a)은 현재 명령어에 대해 규칙 캐시 미스가 있었는지에 관한 표시자를 포함할 수 있다. (1066a)가 잠재적 히트를 보고하면, (1068)은 히트가 참(true) 히트인지 거짓(false) 히트인지를 결정하여, 거짓 히트를 미스로 바꾸어 놓는다. 요소(1066b)는 규칙 캐시 미스가 없었고 현재 명령어와 매칭하는 캐시 내에 규칙이 있는 경우에 스테이지 6으로의 PUMP 출력을 나타낸다. 출력(1066b)은 PC new tag 및 R tag를 포함할 수 있다. 실시예(1060)의 PUMP 스테이지는 변경될 수 있음을 유의하여야 한다. 예를 들어, opgroup/care 룩업(1062)은 (예를 들어, 특정 PUMP 규칙 캐시 구현에 따라) 스테이지 5에서 행해지는 PUMP 규칙 캐시 위치 및 룩업 둘 모두의 결정에 따라 스테이지 3보다는 스테이지 4에서 수행될 수 있다.
비-메모리 동작과 관련하여, Mtag는 PUMP 스테이지로의 입력으로 필요하지 않으며, PUMP는 이것 없이 처리를 계속 수행할 수 있다. 메모리 동작 명령어의 경우, PUMP는 Mtag가 메모리에서 검색될 때까지 기능 정지된다. 대안적으로, 실시예는 본 명세서의 다른 곳에서 설명된 바와 같이 Mtag 예측을 수행할 수 있다. 본 명세서의 다른 곳에서의 논의와 일관하여, PC new tag는 도 1과 관련하여 도시되고 설명된 바와 같이 스테이지 1에 다시 제공되어야 한다. 명령어가 커밋되는 한, PC new tag는 다음 명령어에 적절한 PC 태그이다. 현재 명령어가 커밋하지 않으면(예를 들어, 규칙 캐시 히트 없으면), (스테이지 1로 패스백(pass back)됨으로써) PC new tag는 규칙 캐시 미스 핸들러에 의해 결정된다. 트랩 핸들러가 시작되거나 컨텍스트 스위치가 수행(예를 들어, PC 복원)되면, 태그는 저장된 PC로부터 가져온다.
본 명세서에서 설명된 바와 같이, 실시예는 단일 태그를 각 워드와 연관시킬 수 있다. 적어도 하나의 실시예에서, 각 태그와 연관된 워드 크기는 64 비트일 수 있다. 태깅된 워드의 내용은 예를 들어 명령어 또는 데이터를 포함할 수 있다. 이러한 실시예에서, 단일 명령어의 크기. 그러나, 실시예는 64 비트 이외의 다른 크기의 명령어를 또한 지원할 수도 있다. 예를 들어, 실시예는 본 명세서의 다른 곳에서 더 상세히 설명된 바와 같이, 구축된 축소 명령어 집합 컴퓨팅(RISC) 원리에 기초한 오픈 소스 명령어 집합 아키텍처(ISA)인 RISC-V 아키텍처에 기초할 수 있다. RISC-V 아키텍처를 사용하는 실시예는 예를 들어 32 비트 명령어뿐만 아니라 64 비트 명령어와 같은 다수의 상이한 크기의 명령어를 포함할 수 있다. 이러한 경우, 본 명세서에서의 기술에 따른 실시예는 단일 태그를 단일의 64 비트 워드와 연관시킬 수 있고, 그러므로 단일의 워드는 하나의 64 비트 명령어 또는 두 개의 32 비트 명령어를 포함할 수 있다.
도 34를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 명령어와 연관될 수 있는 태그의 예(200)가 도시된다. 요소(201)는 단일 태그(202a)가 단일 명령어(204a)와 연관되는 위에서 언급한 경우를 도시한다. 적어도 하나의 실시예에서, (202a 및 204a) 각각의 크기는 64 비트 워드일 수 있다. 요소(203)는 단일 태그(202b)가 두 개의 명령어(204b 및 204c)와 연관되는 위에서도 언급한 대안을 도시한다. 적어도 하나의 실시예에서, (202b)의 크기는 64 비트 워드일 수 있고, 명령어(204b 및 204c)는 각각 태그(202b)와 연관된 동일한 64 비트 명령어 워드(205)에 포함된 32 비트 명령어일 수 있다. 보다 일반적으로, 실시예에서 사용된 명령어 크기(들)에 따라 단일의 태깅된 명령어에 두 개 초과의 명령어가 있을 수 있음을 유의하여야 한다. 요소(203)에 의해 도시된 바와 같이, 태깅의 세분성이 명령어의 세분성과 매칭하지 않으면, 다수의 명령어는 단일 태그와 연관된다. 경우에 따라, 동일한 태그(202b)가 명령어(204b, 204c) 각각에 사용될 수 있다. 그러나, 경우에 따라, 동일한 태그(202b)가 명령어(204b, 204c) 각각에 사용되지 않을 수 있다. 다음 단락에서, 단일의 태깅된 워드와 연관된 단일 명령어에 포함된 (204b 및 204c)와 같은 다수의 명령어 각각은 서브 명령어(subinstruction)로 지칭될 수 있다.
따라서 이제는 복수의 서브 명령어 각각과 관련하여 상이한 태그가 사용될 수 있는, 동일한 명령어 워드 내의 다수의 서브 명령어와 관련한 실시예에서 사용될 수 있는 기술이 설명될 것이다.
도 35를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 명령어 및 태그를 도시하는 예가 도시된다. 예(220)는 두 개의 32 비트 서브 명령어(204b 및 204c)를 포함하는 단일 64 비트 명령어 워드(205)를 포함한다. 태그(202b)는 예(200)에서 전술한 바와 같이 명령어 워드(205) 상의 태그일 수 있다. 본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 명령어 워드(205)의 태그(202b)는 태그들의 쌍을 포함하는 다른 메모리 위치(222)를 가리키는 포인터(221)일 수 있고, 여기서 쌍은 명령어 워드(205)의 서브 명령어(204b-204c)의 각각에 대한 태그를 포함한다. 이 예(220)에서, 태그 쌍(222)은 서브 명령어1(204b)에 대한 제 1 태그인 tag1을 나타내는 (222a)를 포함하고, 또한 서브 명령어2(204c)에 대한 제 2 태그인 tag2를 나타내는 (222b)를 포함한다. 적어도 일 실시예에서, 쌍(222)의 각각의 태그(222a-222b)는 비-포인터 태그(예를 들어, 스칼라)일 수 있고, 본 명세서에 설명된 바와 같이 처리를 위해 PUMP에 의해 사용되는 정보를 포함하는 또 다른 메모리 위치를 가리키는 포인터 태그일 수 있거나, 그렇지 않으면 하나 이상의 비-포인터 필드 및/또는 하나 이상의 비-포인터 필드를 포함하는 보다 복잡한 구조체일 수 있다. 예를 들어, tag1(222a)은 서브 명령어1(204a)에 대한 포인터 태그일 수 있고, tag2(222b)는 서브 명령어2(204b)에 대한 포인터 태그일 수 있다. (220)에서 도시된 바와 같이, 요소(223a)는 서브 명령어1(204b)를 처리하기 위해 PUMP에 의해 사용되는 정보를 포함하는 다른 메모리 위치(224a)를 가리키거나 식별하는 tag1(222a)를 나타내며, 요소(223b)는 서브 명령어2(204c)를 처리하기 위해 PUMP에 의해 사용되는 정보를 포함하는 다른 메모리 위치(224b)를 가리키거나 식별하는 tag2(222b)를 나타낸다. 실시예 및 서브 명령어에 따라, (224a 및 224b) 각각은 비-포인터일 수 있고, 메모리 위치를 가리키는 또 다른 포인터일 수 있거나, 하나 이상의 포인터와 하나 이상의 포인트의 일부 조합을 포함하는 복잡한 구조체일 수 있다.
동일한 명령어 워드(205) 내에 다수의 서브 명령어를 갖는 실시예에서, 명령어 워드(205)에 포함된 서브 명령어 중 어느 것이 어느 한 시점에서 실행되는지를 나타내는 추가 입력이 PUMP에 제공될 수 있다. 예를 들어, 명령어 워드(205)에 두 개의 서브 명령어(204b-204c)가 있는 경우, PUMP로의 추가 입력은 서브 명령어1(204b) 또는 서브 명령어2(204c)가 특정 시점에서 실행 중인지를 나타내는 0 또는 1일 수 있다. RISC-V 아키텍처에 기초한 본 명세서의 다른 곳에서의 논의와 일관하는 적어도 하나의 실시예에서, PUMP로의 (어느 서브 명령어가 실행 중인지를 나타내는) 추가 입력을 기록하거나 저장하는 (본 명세서 다른 곳에서 설명된 ssuninstr CSR과 같은) CSR이 정의될 수 있다. 적어도 하나의 실시예에서, PUMP는 CSR을 사용하지 않고 데이터 경로로부터 (예를 들어, 코드 실행 도메인으로부터) 전술한 추가 입력을 정상적으로 수신할 수 있다. 그러나, 규칙 미스 시, 전술한 추가 입력은 CSR에 기록되어, 규칙 미스 핸들러가 실행되는 메타데이터 처리 도메인이 전술한 추가 입력을 획득할 수 있도록 한다(예를 들어, 전술한 추가 입력에 대한 CSR 값은 규칙 삽입시에 PUMP에 제공된다).
추가로 설명하면, 실시예는 프로그램의 두 위치들 사이에서 제어의 이전을 제공하는 서브 명령어를 포함할 수 있다. 그러한 서브 명령어의 예는 점핑하기, 분기하기, 리턴하기 또는 보다 일반적으로 코드의 소스 위치로부터 코드의 타깃(예를 들어, 싱크 또는 목적지) 위치로 제어를 이전하는 것일 수 있다. 본 명세서의 다른 곳에서 설명된 CFI 또는 제어 흐름 무결성과 관련하여, PUMP가 위치들 간의 이전을 프로그램에 의해 지원되는 위치만으로 제한하거나 제어하는 CFI 정책의 규칙을 구현하게 하는 것이 바람직할 수 있다. 예를 들어, 태그 T1을 갖는 코드의 소스 위치로부터 태그 T2를 갖는 코드의 타깃 위치로 제어의 이전이 이루어지는 경우를 고려해 본다. CFI 정책을 시행할 때 PUMP에 의해 사용되는 정보는 제어를 T2로 이전하도록 허용된 유효한 소스 위치 리스트일 수 있다. CFI 정책의 실시예에서, 소스로부터 타깃 위치로 제어를 이전할 때 두 개의 명령어 또는 opcode의 두 번 체크를 제공하기 위해 두 개의 규칙이 사용될 수 있다. 도 36의 예(230)에 도시된 바와 같이, 이전 또는 호출의 의사-코드 표현을 고려해 본다. 예(230)에서, foo 루틴(231)에 있는 소스 위치로부터 루틴 바(routine bar)(233)에 있는 타깃 위치로 제어(23a)를 이전하는 호출이 만들어질 수 있다. 구체적으로, 제어는 태그 T1을 갖는 소스 위치 X1(232)로부터 태그 T2를 갖는 타깃 위치 X2(234)로 이전(231a)될 수 있다. 타깃 위치 X2는 루틴 바의 코드의 본문(body)(233a)에 있는 제 1 명령어일 수 있다. CFI 정책의 규칙은 (232)로부터 (234)로 이전이 허용되거나 유효한지 확인하는지를 체크하는데 사용될 수 있다. 적어도 하나의 실시예에서, (232)로부터 (234)로 제어의 이전이 유효함을 보장하기 위해 체크를 각각 수행하는 CFI 정책의 두 개의 규칙이 사용될 수 있다. 소스 위치 X1에 있는 명령어는 제어가 타깃으로 이전되는 분기 포인트 또는 소스 포인트이다. 소스에서(예를 들어, 소스 위치 X1(232)에 있는 명령어를 실행하기 이전에), 제 1 규칙은 PC의 태그를 마킹하거나 설정하여 소스 위치를 표시하는데 사용될 수 있다. 예를 들어, 제 1 규칙은 PC의 태그를 어드레스 X1로 마킹하거나 설정하여 소스 위치를 표시할 수 있다. 이어서, (타깃 위치 X2(234)에 있는 명령어를 실행하기 이전에), 제 2 규칙은 소스 위치 X1이 제어가 타깃 위치 X2로 이전되도록 허용된 유효한 소스 위치인지를 체크하는데 사용될 수 있다.
적어도 하나의 실시예에서, 제 2 규칙의 체크는 (예를 들어, 소스 위치 어드레스 X1을 표시하는) 소스 위치(232)를 식별하는 (제 1 규칙에 의해 설정된) PC의 마킹된 태그가 타깃 위치(234)로 제어가 이전될 수 있는 유효한 소스 위치를 식별하는지를 결정함으로써 수행될 수 있다. 이러한 실시예에서, 제 2 규칙에는 타깃 위치(234)로 제어를 이전하도록 허용된 모든 유효한 소스 위치를 나타내는 정의된 리스트가 제공될 수 있다. 적어도 하나의 일 실시예에서, 정의된 리스트는 예를 들어 위에 언급된 X1과 같은 어드레스에 의해 유효한 소스 위치를 식별할 수 있다.
도 37을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 소스 및 타깃 위치의 서브 명령어와 관련하여 사용될 수 있는 태그를 도시하는 예(240)가 도시된다. 예(240)는 전술한 바와 같이 단일 명령어 워드의 두 개의 서브 명령어(204b 내지 201c)에 대해 특정된 단일 태그(202b)를 나타내는 요소(203)를 포함한다. 명령어 워드상의 태그(202b)는 두 개의 서브 명령어(204b-204c)에 대해 각각 두 개의 태그(242a-204b)를 나타내는 태그 쌍(242)을 가리킬 수 있다. 두 개의 태그(242a-b) 각각은 일반적으로 두 개의 태그(242a-242b) 각각과 연관된 특정 서브 명령어에 따라 소스 또는 타깃 위치와 관련하여 CFI 유효 입증을 위해 PUMP 규칙에 의해 사용되는 정보를 가리키는 포인터일 수 있다.
예(240)는 두 개의 서브 명령어(204b-204c)가 타깃 위치가 되는 일 실시예에서의 구조체를 도시한다. 서브 명령어 태그(242a)는 소스 id 필드(245a) 및 허용된 소스 세트 필드(245b)를 포함하는 구조체(245)의 위치를 가리킨다(243a). 소스 id 필드(245a)는 본 명세서에서 서브 명령어(204b)가 타깃 위치인 경우와 같이, 서브 명령어(204b)가 소스 위치가 아닌 경우에는 널(null)일 수 있다. 소스 세트 필드(245b)는 서브 명령어(204b)를 포함하는 특정 타깃 위치로 제어를 이전하도록 허용되는 하나 이상의 유효 소스 위치를 식별하는 리스트 구조체(247)를 포함하는 위치를 가리키는 포인터일 수 있다. 적어도 하나의 실시예에서, 리스트 구조체(247)는 유효 소스 위치들의 크기 또는 개수를 나타내는 제 1 요소를 포함할 수 있다. 따라서, "n"(n은 0을 초과하는 정수)의 크기(247a)는 리스트(247) 내의 요소(247b 내지 247n)에 의해 표시되는 소스 위치의 수를 나타낸다. 요소(247b 내지 247n) 각각은 서브 명령어(204b)를 포함하는 타깃 위치로 제어를 이전할 수 있는 상이한 유효 소스 위치를 식별할 수 있다. 적어도 하나의 실시예에서, 허용된 소스(247b 내지 n) 각각은 예를 들어 유효한 소스 위치 중 하나의 어드레스인 스칼라 또는 비-포인터일 수 있다.
예(240)에서, 서브 명령어2(204c)와 함께 사용되는 요소(243b, 246 및 248)은 서브 명령어1(204b)과 함께 사용되는 요소(243a, 245 및 247)와 각각 유사하다. 일반적으로, (240)의 구조체를 사용하는 그러한 실시예에서, 존재하지 않는 임의의 아이템에는 널 또는 제로 값이 할당될 수 있다. 명령어 워드(205)가 소스 또는 목적지 위치가 아닌 한 쌍의 서브 명령어(204b-204c)를 포함하면, 태그(202b)는 널일 수 있다(예를 들어, 그렇지 않으면, 구조체(242)를 가리키지 않는 비-포인터 또는 다른 포인터를 식별할 수 있다). 서브 명령어(204b-204c) 중 하나가 이전의 소스 위치도 아니고 타깃 위치도 아니면, (242)에서 연관된 태그는 널이다. 예를 들어, 서브 명령어(204b)가 소스 위치도 타깃 위치도 아니지만 서브 명령어(204)가 타깃이면, (242a)는 널일 수 있고, (242b)는 예 240에 도시된 바와 같을 수 있다. 서브 명령어(204b-204c)가 소스 위치가 아니면, 소스 id는 널이다(예를 들어, 예(240)의 (204b-204c)가 타깃 위치이기 때문에, (245a 및 236a)는 둘 모두 널이다). 서브 명령어(204b-204c)가 타깃 위치가 아니면, 허용된 소스 세트 필드 포인터는 널이다. 예를 들어, 서브 명령어(204b)가 타깃 위치가 아닌 소스 위치를 식별하면, 소스 id(245a)는 소스 위치 명령어의 어드레스를 식별하며, (245b)는 널일 것이다.
추가로 설명하면, 예(240)에서 설명된 바와 같은 구조체를 이용하는 다른 예(250)의 도 38이 참조되는데, 차이점은 제 1 서브 명령어(251a)가 소스 위치도 타깃 위치도 아니고, 제 2 서브 명령어(251b)가 3 개의 유효한 소스 위치 중 임의의 위치로부터 제어가 이전될 수 있는 타깃 위치라는 점이다. 요소(251a-251b)는 태그(251)를 갖는 단일 태깅된 워드에 포함된 두 개의 32 비트 서브 명령어를 나타낼 수 있다. 태그(251)는 서브 명령어(251a-251b)에 대한 태그 쌍을 갖는 구조체(252)를 포함하는 메모리 내의 위치를 식별하는 포인터(1228)일 수 있다. 요소(252)는 예(240)의 (242)와 유사할 수 있다. 요소(252a)는 서브 명령어(251a)에 대한 태그 포인터일 수 있고, 요소(252b)는 서브 명령어(251b)에 대한 태그 포인터일 수 있다. 서브 명령어(251a)는 소스도 타깃 위치도 아니므로, (252a)는 0으로 표시된 바와 같이 널이다. 서브 명령어(251b)는 타깃 위치이므로, (252b)는 구조체(254)를 가리키는 포인터(1238)이다. 요소(254)는 예(240)의 (246)과 유사할 수 있다. 요소(254a)는 ((246a)와 같은) 소스 id 필드이고, 요소(254b)는 (예(240)의 (248)과 유사한) 허용된 소스 세트 구조체(256)를 가리키는 포인터(어드레스(1248))를 포함하는 ((246b)와 같은) 허용된 소스 세트 필드이다. 서브 명령어(251b)는 단지 타깃 위치이지 소스가 아니기 때문에, 소스 id(254a)는 널이다. 요소(256a)는 유효한 소스 위치의 수를 나타내는 (248a와 같은) 크기 필드일 수 있다. 요소(256b 내지 256d)는 예를 들면 유효 소스 위치 명령어의 어드레스일 수 있는 유효 소스 id를 나타낼 수 있다. 이 예에서, (256a)는 엔트리(256b 내지 256d)에 각각 저장되는 어드레스(50bc, 5078, 5100)을 갖는 3 개의 유효 소스 위치가 있음을 나타낸다. 전술한 바와 관련하여, 일반적으로 명령어는 타깃 및 소스 둘 모두가 될 수 있어서 타깃이 된다는 것이 소스 id가 항상 널임을 의미하지 않는 것임을 유의하여야 한다. 예를 들어, 명령어가 타깃 및 소스 둘 다이면, 소스 id는 널이 아닐 것이고, 명령어의 태그는 허용 가능/허용된 소스의 리스트를 포함한다.
예컨대 엔트리(256b 내지 256d)에서 및 보다 일반적으로는 허용된 소스 세트 중 임의의 허용된 소스(예를 들어, 예(240)의 (248b 내지 248n) 중 임의의 소스)에서 소스 위치의 어드레스는 바이트 레벨 어드레스 세분성일 수 있다는 것을 유의하여야 한다.
단일의 태깅된 워드에 포함된 다수의 명령어(서브 명령어라고도 지칭함)에 관해 방금 설명된 것과 유사한 방식으로, 실시예는 데이터의 단일의 태깅된 데이터보다 적은 데이터 부분에 대한 액세스를 허용할 수 있다. 예를 들어, 실시예는 바이트 레벨에서 데이터에 액세스하는 명령어를 포함할 수 있으며, 각 바이트가 단일 태깅된 워드에 포함된 다수의 서브 명령어 각각에 상이한 태그를 제공하는 것과 유사한 방식으로 자신의 연관된 태그를 가질 수 있도록 바이트 레벨 태그 태깅을 제공하는 것이 바람직할 수 있다. 다음의 예에서는 바이트 레벨 태깅을 제공하는 것이 언급되며, 여기서 64 비트 워드에 포함된 8 바이트 각각은 자체의 연관된 태그를 가질 수 있다. 그러나, 보다 일반적으로, 본 명세서에서의 기술은 단일 태깅된 워드에 포함된 임의의 수의 다중 데이터 아이템에 서브워드 태깅을 제공하는데 사용될 수 있다. 이러한 경우, 태깅된 데이터 워드와 연관된 태그는 태깅된 데이터 워드의 바이트에 대한 바이트 레벨 태그를 식별하는 구조체를 가리키는 포인터일 수 있다.
도 39를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 바이트 레벨 태깅의 예(260)가 도시된다. 요소(262)는 태깅된 64 비트 워드(265)와 연관된 태그(262a)를 나타내며, 여기서 워드(265)는 B1 내지 B8로 표시된 8 바이트를 포함한다. 태그(262a)는 데이터 워드(265)의 각각의 바이트(B1 내지 B8)에 대한 태그를 포함하는 구조체(266)의 메모리 위치를 가리키는(261) 포인터일 수 있다. 구조체(266)는 구조체에 남아 있는 엔트리의 수를 나타내는 크기 필드인 제 1 필드(265a)를 포함한다. 구조체 내의 각각의 후속 엔트리는 태그 값을 포함할 수 있고, 그 특정 태그 값을 갖는 워드(265)의 하나 이상의 바이트를 나타낼 수 있다. 이 예에서, 크기(265a)는 8이며, 여기서 (265)의 바이트 B1-B8 각각은 상이한 태그 값을 갖는다. 요소(266a 내지 266h)는 각각 워드(265)의 바이트 B1 내지B8에 대한 태그 값을 나타낸다.
도 40을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 바이트 레벨 태깅의 제 2 예(267)가 도시된다. 요소(262)는 태깅된 64 비트 워드(265)와 연관된 태그(262a)를 나타내며, 여기서 워드(265)는 B1 내지 B8로 표시된 8 바이트를 포함한다. 태그(262a)는 데이터 워드(265)의 각각의 바이트(B1 내지 B8)에 대한 태그를 포함하는 구조체(268b)의 메모리 위치를 가리키는(268a) 포인터일 수 있다. 구조체(268b)는 구조체에 남아 있는 엔트리의 수를 나타내는 크기 필드인 제 1 필드(265b)를 포함할 수 있다. 따라서, (265b)는 도 39의 (265a)와 유사하다. 구조체(268b) 내의 각각의 후속 엔트리는 태그 값을 포함할 수 있고 그 특정 태그 값을 갖는 워드(265)의 하나 이상의 바이트를 나타낼 수 있다. 이 예에서, 크기(265b)는 7 개의 후속 엔트리(266a 내지 226f 및 268c)를 나타내는 7이다. 요소(266a 내지 266f)는 도 39의 예(260)와 관련하여 설명된 바와 같다. 요소(268c)는 태그 7이 바이트(B7 및 B8) 둘 모두에 대한 태그임을 나타낸다. 따라서, 예(267)에서, 바이트(B7 및 B8)은 태그 7의 동일한 태그 값을 갖기 때문에, 구조체(268b)는 도 39의 구조체(266)보다 하나 적은 엔트리를 포함한다. 이러한 방식으로, 데이터 워드의 태그(예를 들어, (262a))가 가리키는 구조체(예를 들어, (268b))는 필요에 따라 특정 바이트 레벨 태그에 따라 다양한 수의 엔트리를 가질 수 있다.
데이터 액세스 세분성의 특정 레벨은 실시예에서 특정 아키텍처 및 명령어 세트에 따라 달라질 수 있음을 유의하여야 한다. 전술한 바는 바이트 레벨 데이터 액세스를 허용하는 실시예에서 바이트 레벨 태깅을 제공하는데 사용될 수 있다. 변형예로서, 실시예는 세분성의 상이한 레벨에서 데이터 액세스를 지원할 수 있으며, 본 명세서에서의 기술은 세분성의 임의의 서브워드 태깅 레벨로 용이하게 확장될 수 있다.
유사하게, 예(260 및 267)는 바이트 레벨 또는 다른 서브워드 데이터 태깅을 유지하는데 사용될 수 있는 데이터 구조체의 하나의 예를 도시한다. 변형예로서, 실시예는 트리 또는 다른 계층 구조체를 사용하여 단일 태깅된 데이터 워드의 바이트에 대한 바이트 레벨 태그를 특정할 수 있다. 바이트 레벨 태그를 표현하는 트리 또는 다른 계층 구조체는 예를 들어 본 명세서의 다른 곳에서 설명된 도 78 내지 도 81의 각각의 요소(100, 120, 130 및 140)와 관련하여 워드 레벨 태그를 저장하기 위해 본 명세서에서 설명된 계층적 구조체와 유사할 수 있다.
추가로 설명하면, 실시예는 도 41의 예(270)에서와 같이 바이트 레벨 태그를 표현하는 위해 트리 구조체를 사용할 수 있다. 예(270)에서, 요소(262)는 바이트(B1 내지 B8)를 포함하는 태깅된 워드(265)와 연관된 태그(262a)를 나타낼 수 있다. 태그(262a)는 B1 내지 B8(265)에 대한 바이트 레벨 태그를 나타내는 트리 구조체에 대한 포인터 또는 어드레스일 수 있다. 예를 들어, 태그(262a)는 트리 구조체의 루트 노드(272)의 위치를 가리킬 수 있다. 이 예에서 트리 구조체는 레벨 1의 루트 노드(272), 레벨 2의 노드(274a-274b), 레벨 3의 노드(276a 내지 276d) 및 레벨 4의 노드(278a 내지 278h)를 포함할 수 있다. 트리의 각 노드는 하나 이상의 바이트의 바이트 범위와 연관될 수 있다. 트리의 리프(leaf)들은 바이트(B1 내지 B8)에 대한 바이트 레벨 태그를 나타낼 수 있다. 그러므로 트리의 비-리프(non-leaf) 노드는 태그 값을 특정하지 않고 오히려 하나 이상의 하위 레벨에 있는 하나 이상의 자손 노드가 참고하여 비-리프 노드와 연관된 바이트 범위에 대한 바이트 레벨 태그를 결정해야 함을 나타낸다. 리프 노드는 (265)의 다중 바이트의 범위에 대한 동종 또는 동일한 태그 값을 나타낼 수 있다. 각각의 비-리프 노드는 비-리프 노드의 좌측 자식 노드를 가리키는 좌측 포인터 및 비-리프 노드의 우측 자식 노드를 가리키는 우측 포인터를 포함할 수 있다. 부모 노드의 자식 노드들 각각은 부모 노드와 연관된 바이트 범위의 분할을 나타낼 수 있다.
예(270)는 동종 바이트 레벨 태그가 없고 (265)의 바이트(B1 내지 B8) 각각이 상이한 태그 값을 갖는 트리 구조체를 도시한다. 본 명세서의 다른 곳에서의 논의(예를 들어, 도 78 내지 도 81의 요소(100, 120, 130 및 140))와 일관된 방식으로, 실시예는 서브트리가 그의 루트로서 제 1 노드와 연관된 바이트 범위에 대한 동종 태그 값을 나타내는 제 1 노드를 갖는다면, 서브트리로부터 자손 노드를 생략할 수 있다. 예를 들어, 추가로 설명하면, 도 42가 참조될 수 있다. 예(280)에서, 요소(262)는 전술한 바와 같이 바이트(B1 내지 B8)를 포함하는 태깅된 워드(265)와 연관된 태그(262a)를 나타낼 수 있다. 태그(262a)는 B1 내지 B8(265)에 대한 바이트 레벨 태그를 나타내는 트리 구조체를 가리키는 포인터 또는 어드레스일 수 있다. 이 예(280)에서, 바이트(B1 내지 B8) 각각은 동일한 태그 T1을 가지며, 그래서 트리 구조체는 루트 노드(281)만을 포함해야 한다. 바이트(B1 내지 B8)에 대한 바이트 레벨 태그가 시간 경과에 따라 수정되거나 변경될 수 있기 때문에, 태그(262a)가 가리키는 트리 구조체 또는 다른 구조체는 이에 따라 이러한 바이트 레벨 태그 수정을 반영하기 위해 적절히 업데이트될 수 있다.
동일한 데이터 워드(265) 내에서 바이트 레벨 태깅, 또는 보다 일반적으로 서브워드 태깅을 제공하는 실시예에서, (워드(265)에 포함된 바이트 중 어느 하나 이상의 바이트에 대응하는) 하나 이상의 바이트 레벨 태그가 참조되는 것을 나타내는 추가 입력이 PUMP에 제공될 수 있다. 예를 들어, 단일 태깅된 데이터 워드(265) 내에 8 바이트(B1 내지 B8)가 있는 바이트 레벨 태깅에서, PUMP로의 추가 입력은 8 비트의 비트마스크일 수 있으며, 여기서 8 비트 각각은 바이트(B1 내지 B8)의 서로 다른 바이트와 연관되고 워드(265)의 특정 바이트에 대한 바이트 레벨 태그를 사용할지를 나타낸다. 변형예로서, 실시예는 시작 바이트 및 길이 또는 크기와 같은 바이트 범위를 특정함으로써 하나 이상의 바이트를 나타낼 수 있다(예를 들어, 시작 바이트 B4를 특정하고 5라는 크기 또는 길이를 표시함으로써 바이트(B4 내지 B8)를 나타낼 수 있다). RISC-V 아키텍처에 기초한 본 명세서의 다른 곳에서의 논의와 일관하는 적어도 하나의 실시예에서, 하나 이상의 바이트(B1 내지 B8)에 대한 하나 이상의 바이트 레벨 태그가 PUMP에 의해 사용될 것임을 나타내는 추가 입력을 기록 또는 저장하는 CSR이 정의될 수 있다. 추가 입력은, 예를 들어, 비트마스크 또는 PUMP에 의해 사용된 특정 바이트 레벨 태그를 식별하는 다른 적합한 표현일 수 있다. 적어도 하나의 실시예에서, PUMP는 CSR을 사용하지 않고 어느 하나 이상의 바이트가 데이터 경로로부터의 (예를 들어, 코드 실행 도메인으로부터의) 입력으로서 사용될 것임을 나타내는 전술한 추가 입력을 정상적으로 수신할 수 있다. 그러나, 규칙 미스 시, 전술한 추가 입력은 규칙 미스 핸들러가 실행되는 메타데이터 처리 도메인이 전술한 추가 입력을 획득할 수 있도록 CSR에 기록될 수 있다(예를 들어, 규칙 삽입시 전술한 추가 입력에 대한 CSR 값이 PUMP에 제공된다).
본 명세서의 다른 곳에서 논의된 바와 같이, 정책 레벨에서 많은 명령어가 유사한 방식으로 취급될 수 있다. 예를 들어, 가산 및 감산 명령어 연산 코드 또는 opcode는 전형적으로 그의 메타데이터를 동일하게 취급할 수 있어서, 둘 모두의 opcode는 PUMP로의 동일한 태그 입력 및 PUMP에 의해 전파된 동일한 태그 출력을 고려함으로써 특정 정책에 대한 규칙 레벨에서 유사하게 거동할 수 있다. 그러한 경우에, 가산 및 감산 opcode는 단일 연산 그룹 또는 "opgroup"에서 함께 그룹화될 수 있으므로 동일한 규칙 세트가 그 opgroup 내 모든 opcode에 사용될 수 있다. opcode가 함께 그룹화되는 방법은 정책에 종속적이며 따라서 정책에 따라 다를 수 있다. 일 실시예에서, 정책 레벨마다 특정 opcode를 그의 연관된 opgroup에 매핑하는 변환 또는 매핑 테이블이 사용될 수 있다. 다시 말해서, 매핑은 정책마다 변할 수 있기 때문에 각 정책(또는 opgroup 매핑에 특정된 동일한 opcode를 갖는 다수의 정책 그룹)에 대해 상이한 매핑 테이블이 생성될 수 있다.
특정 opcode의 경우, 변환 또는 매핑 테이블은 위에서 언급한 바와 같이 opgroup을 결정할 수 있으며 특정 opcode 에 대한 추가 정보를 또한 결정할 수도 있다. 이러한 부가적인 정보는 어느 PUMP 입력 및 PUMP 출력(예를 들어, 입력 태그 및 전파된 출력 태그)이 각각 규칙 처리를 위한 입력으로서 실제로 사용되는지 그리고 특정 opcode에 대한 규칙 처리의 관련 출력으로서 전파될 수 있는지를 나타낼 수 있는, 본 명세서의 다른 곳에서도 또한 논의된 바와 같은 care/don't care 비트 벡터를 포함할 수 있다. 실시예에서, don't care 비트 벡터는 임의의 PUMP 입력 및 출력에 대해 결정될 수 있다. 일 실시예에서, don't care 비트 벡터는 어느 입력 태그 및 출력 태그가 관련 있는지를 나타낼 수 있고 또한 특정 opcode 비트가 특정 opcode에 실제로 사용되는지를 나타낼 수도 있다. 이것은 RISC-V 아키텍처 및 명령어 포맷에 대해 아래에서 보다 상세하게 설명되지만, 다른 아키텍처의 다른 적합한 명령어 포맷과 관련하여 보다 일반적으로 사용될 수도 있다. opgroup 및 특정 opcode에 대한 care/don't care비트(예를 들어, 아래에서 논의되는 예(420)의 요소(422))를 포함하는 전술한 변환 또는 매핑 테이블은 또한 본 명세서의 다른 곳에서 opgroup/care 표라고 언급될 수도 있다.
RISC-V는 opcode에 대해 상이한 세트의 명령어 비트를 각각 사용하는 상이한 명령어 포맷을 가지고 있다. 도 43의 예(400)를 참조하면, RISC-V 아키텍처의 명령어를 사용하는 실시예에서 상이한 opcode에 대해 상이한 비트 인코딩에 포함될 수 있는 명령어의 비트들이 도시된다. 일반적으로, RISC-V 아키텍처는 명령어의 서로 다른 비트가 opcode 인코딩의 일부로서 사용될 수 있는 다중 명령어 포맷을 포함한다. 32 비트 명령어의 경우, 총 22 비트까지 opcode의 인코딩을 나타내는데 사용될 수 있다. 요소(404)는 명령어 포맷에 따라 특정 opcode에 대한 비트 인코딩을 나타내는데 사용될 수 있는 RISC-V 아키텍처에서 명령어의 부분을 나타낸다. 요소(404)는 특정 opcode를 인코딩하는데 사용될 수 있는 비트의 3 필드(404a 내지 404c)를 포함한다. 요소(404a)는 7 비트의 제 1 opcode 필드, opcode A를 나타낸다. 요소(404b)는 3 비트의 제 2 opcode 필드, funct3을 나타낸다. 요소(404a)는 12 비트의 제 3 opcode 필드, funct12를 나타낸다. (예를 들어, 시스템 호출과 같은) 명령어에 따라, opcode 인코딩은 (404a 내지 404c)로 표시된 비트들 중 모두 22 개까지를 포함할 수 있다. 보다 구체적으로, RISC-V에서, opcode는 (404b)의 단지 7 비트를 사용하여, (404b 및 404c)의 단지 10 비트((404a) 제외함) 또는 (404a 내지 404c)의 22 비트 모두를 사용하여 인코딩될 수 있다. 또 다른 변형예로서, RISC-V 아키텍처의 명령어는 (402)로 표시된 바와 같이 필드를 사용하는 opcode 인코딩을 가질 수 있다. 요소(402)는 전술한 바와 같이 비트의 두 필드(404b 및 404c)를 포함한다. 또한, opcode 인코딩에서 funct12(404a)의 12 비트 모두 사용하기 보다는, 명령어는 funct7(402a)에 의해 표시되는 12 비트 중 7 비트만을 사용할 수 있다. 따라서, 또 다른 가능성으로서, opcode는 요소(402)에 의해 도시된 바와 같이 필드(402, 404b 및 404c)를 사용하는 인코딩을 가질 수 있다.
도 44에는 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 매핑 또는 변환 테이블을 도시하는 예(420)가 도시된다. 위에서 논의된 바와 같이, opcode(421)는 opcode 매핑 테이블(422)에 입력 또는 인덱스로서 제공되어 opcode(421)에 매핑된 출력(424)을 룩업하거나 결정할 수 있다. 매핑된 출력(424)은 특정 opcode(421)에 대한 PUMP 입력 및 출력의 opgroup 및 care/don't care 비트 벡터를 포함할 수 있다. RISC 아키텍처 및 명령어 포맷에 기초한 실시예에서, opcode는 잠재적으로 최대 22 비트의 인코딩을 가질 수 있다. 그러나 22 비트 opcode를 수용하는데 필요한 많은 수의 엔트리로 인해 이렇게 큰 22 비트 opcode를 테이블에 인덱스로서 사용하는 것은 불합리하다 (예를 들어, 테이블은 22 비트 opcode를 위한 수백만 개의 엔트리를 만들어내는 연관된 opgroup 및 care/don't care 비트 벡터 정보를 나타내는 각 opcode마다 엔트리를 포함할 수 있다). 이러한 실시예에서 테이블(422)의 크기를 줄이기 위해, 테이블(422)은 22 비트 opcode 필드의 일부만을 사용하여 인덱싱될 수 있다. 예를 들어, 적어도 하나의 실시예에서, opcode(421) 입력은 예(400)의 요소(404b 및 404c)에 의해 나타낸 opcode의 10 비트일 수 있다. 따라서, 테이블(422)는 opcode의 (404b 및 404c)의 opcode 비트를 사용하여 인덱싱되어 opcode의 opgroup 및 연관된 care/don't care 비트 벡터를 결정할 수 있다.
이러한 실시예에서, 명령어의 funct12(404a)의 나머지 12 opcode 비트는 PUMP의 입력으로서 제공될 수 있고, PUMP에서 (404a)의 적절한 부분은 특정 opcode에 대해 마스킹된다. funct12(404a)의 어떤 특정 비트가 특정 opcode에 대해 마스킹되어야하는지/마스킹되지 않아야하는지에 관한 정보는 opcode에 대한 매핑 테이블(422) 룩업으로부터 출력된 care/don't care 비트 벡터 정보에 포함될 수 있다. RISC-V 아키텍처에 기초한 적어도 하나의 실시예에서, care/don't care 비트 벡터 정보는 opcode에 대한 funct12(404a)의 12 opcode 비트에 대해 다음 중 하나를 나타낼 수 있다:
1. (404a)의 비트가 아무것도 사용되지 않기 때문에 모든 12 비트가 마스킹될 수 있다.
2. (402a)에 의해 표시된 바와 같이, 12 비트 중 7 비트는 (404a)의 최하위 5 비트(예를 들어, 비트 20 내지 25)가 마스킹된 곳에서 사용된다; 또는
3. (404a)의 모든 12 비트가 사용되며 그래서 (404a)의 비트의 마스킹은 없다.
또한, 이러한 실시예에서, funct12(404a)의 12 opcode 비트는 PUMP 내에 삽입을 수행하는 것과 관련하여 PUMP 입력으로서 제공되는, 본 명세서의 다른 곳에서 설명된 sfunct12 CSR과 같은 CSR에 기록되거나 저장될 수 있다. 적어도 하나의 실시예에서, PUMP는 CSR을 사용하지 않고 데이터 경로로부터 (예를 들어, 코드 실행 도메인으로부터) 전술한 opcode 비트를 정상적으로 수신할 수 있다. 그러나, 규칙 미스 시, 전술한 것은 CSR에 기입되어, 규칙 미스 핸들러가 실행되는 메타데이터 처리 도메인이 전술한 것을 입력으로서 획득할 수 있도록 CSR에 기록된다(예를 들어, 규칙 삽입 시CSR 값은 PUMP에 대한 입력으로서 제공된다).
본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 다중 사용자 프로세스는 물리적 페이지가 사용자 프로세스 어드레스 공간으로 매핑되는 가상 메모리 환경을 사용하여 실행할 수 있다. 본 명세서에서의 기술은 다중 사용자 프로세스 사이에서 메모리의 물리적 페이지를 공유할 수 있도록 이용될 수 있으며, 이 경우 하나 이상의 물리적 페이지의 동일한 세트가 다중 사용자 프로세스 어드레스 공간으로 동시에 매핑될 수 있다. 적어도 하나의 실시예에서, 공유가 허용되는 그러한 프로세스에 의해 사용되는 태그는 사용자 프로세스 어드레스 공간에 걸쳐 값 및 의미 또는 해석이 동일한 글로벌 태그인 것으로 특징지을 수 있다.
도 45를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 프로세스들 사이에서 물리적 페이지의 공유를 도시하는 예(430)가 도시된다. (430)는 어드레스 공간(434)을 갖는 프로세스 PI 및 어드레스 공간(436)을 갖는 프로세스 P2를 포함한다. 요소(434)는 가상 메모리 프로세스 어드레스 공간 또는 0 내지 MAX의 범위를 나타낼 수 있으며, 여기서 MAX는 PI에 의해 사용되는 최대 가상 메모리 어드레스를 나타내고 0은 PI에 의해 사용되는 최소 가상 어드레스를 나타낸다. 관련 기술분야에서 공지된 바와 같이, 메모리(432)의 물리적 페이지는 (434)와 같은 가상 어드레스 공간에 매핑되고, 이 가상 어드레스 공간에서 매핑된 물리적 페이지의 내용은 그렇게 매핑된 물리적 페이지의 매핑된 가상 어드레스를 사용하여 PI에 의해 액세스될 수 있다. 예를 들어, 물리적 페이지 A(432a)는 P1의 가상 어드레스 공간의 서브 범위 X1에 매핑될 수 있다. 프로세스 P1은 예를 들어, 서브 범위 X1에서 특정 가상 어드레스를 참조함으로써 페이지 A(432a) 내의 위치로부터 데이터 아이템 또는 명령어를 판독할 수 있다.
마찬가지로, 메모리의 물리적 페이지(432)는 가상 어드레스 공간(436)으로 매핑될 수 있고, 이 가상 어드레스공간에서 매핑된 물리적 페이지의 내용은 그렇게 매핑된 물리적 페이지의 매핑된 가상 어드레스를 사용하여 P2에 의해 액세스될 수 있다. 예를 들어, 물리적 페이지 A(432a)는 P2의 가상 어드레스 공간의 서브 범위 X2에 매핑될 수 있다. 프로세스 P2는, 예를 들어, 서브 범위 X2에서 특정 가상 어드레스를 참조함으로써 페이지 A(432a) 내의 위치로부터 데이터 아이템 또는 명령어를 판독할 수 있다.
태그(431)는 페이지 A(432)의 메모리 위치상의 태그를 나타낼 수 있고, 이 페이지에서 이러한 태그는 본 명세서에서 설명된 규칙 처리와 관련하여 PUMP에 의해 사용될 수 있다. 페이지 A(432)는 도시된 바와 같이 매핑을 통해 PI 및 P2 둘 모두에 의해 공유되기 때문에, 동일한 세트의 태그(431)가 또한 P1 및 P2 둘 모두의 명령어를 실행하는 것과 관련하여 PUMP에 의해 사용된다. 이러한 실시예에서, 태그(431)는 PI 및 P2 둘 모두에 의해 공유되는 글로벌 태그라고 특징지을 수 있다. 또한, 적어도 하나의 실시예에서, 다수의 프로세스(P1 및 P2)에 의해 공유되는 글로벌 태그(431)는 동일한 규칙 및 정책을 사용하는 것과 같은 유사한 방식으로 해석된다. 예를 들어, 값이 100 인 제 1 태그는 (432a) 내의 제 1 메모리 위치와 연관될 수 있다. 제 1 태그는 특정 실행 명령어가 제 1 메모리 위치 또는 그 내용을 참조하는 동작을 수행할 수 있는지를 결정하는 정책의 규칙과 관련하여 사용되는 제 1 메모리 위치의 컬러화를 나타내는 값을 표시할 수 있다. 제 1 태그는 P1 및 P2 둘 모두의 명령어 실행과 관련하여 규칙에 의해 동일한 컬러로 해석될 수 있다. 예를 들어, 100이라는 태그 값은 P1 및 P2 둘 모두와 관련한 규칙에 의해 동일한 컬러로서 해석되어야 한다. 또한, 동일한 세트 또는 인스턴스의 정책 및 규칙은 P1 및 P2 둘 모두에 대해 PUMP에 의해 사용될 수 있다.
전술한 바와 같이 공유 메모리 상에 글로벌 태그를 사용하는 그러한 실시예에서, 프로세스 단위로 상이한 액세스, 인가 또는 동작을 더 차별화하거나 허용하는 것이 또한 바람직할 수 있다. 예를 들어, 페이지 A(432a)가 P1 및 P2 둘 모두에 의해 공유된 데이터를 포함한다고 가정한다. 그러나 글로벌 태그가 공유 페이지 A(432a)에 태깅하기 위해 사용되더라도, 프로세스 별로 (432a)의 공유 데이터에 대해 상이한 동작 또는 액세스를 허용하는 것이 바람직할 수 있다. 예를 들어, 프로세스 P1는 페이지(432a)에 대해 기입 액세스를 가질 수 있고 프로세스 P2는 페이지(432a)에 대해 판독 전용 액세스를 가질 수 있다. 그러나 (432a)는 글로벌 태그로 태깅된 공유 메모리 페이지일 수 있다. 공유 페이지상의 글로벌 태그를 갖는 그러한 실시예에서, 동일한 정책 및 규칙 세트는 각각의 프로세스에 대해 상이한 판독 및 기입 액세스 능력이 PC상의 상이한 태그 값을 사용하여 차별화될 수 있는 P1 및 P2에 관련하여 사용될 수 있다. 예를 들어, 프로세스 P1은 (432a) 내의 메모리 위치에 기입을 수행하는 제 1 명령어를 포함할 수 있고 현재 PC 태그는 X의 값을 갖고 있다. 액세스 정책의 규칙은 다음의 로직을 수행할 수 있다:
PCtag = X이면, 기입 허용
PCtag = Y이면, 판독만 허용
이러한 경우에, PC 태그는 규칙에 의해 프로세스 P1에 대해 기입 액세스를 허용하는 것으로 해석되는 X라는 값을 가지며 이에 따라 P1은 제 1 명령어를 실행할 수 있다. 프로세스 P2는 (432a) 내의 메모리 위치에 대해 마찬가지로 기입을 수행하는 제 2 명령어를 가질 수 있고 현재 PC 태그는 Y의 값을 갖고 있다. 이러한 경우에, PC 태그는 규칙에 의해 기입 액세스를 허용하지 않고 대신 프로세스 P2에 대한 판독 전용 액세스를 허용하는 것으로 해석되는 Y 값을 가지며 이에 따라 P2는 제 2 명령어를 실행하는 것이 허용되지 않는다.
따라서, 적어도 하나의 실시예에서, PC 태그는 프로세스 별로 다를 수 있는 권한, 액세스 또는 인가를 인코딩하는데 사용될 수 있고, 이에 따라 특정의 허용된 권한, 액세스 또는 인가가 상이한 PC 태그 값에 의해 표현될 수 있다.
실시예는 임의의 적절한 방식으로 각 프로세스에 대해 사용될 특정 PC 태그 값을 특정할 수 있다. 예를 들어, 권한 있는 코드는 특정 프로세스에 사용될 PC 태그 값을 초기에 특정하는 오퍼레이팅 시스템 스타트업 또는 초기화의 일부로서 실행할 수 있다. 변형예로서, 실시예는 공유 페이지 A(432a)를 프로세스 어드레스 공간으로 매핑하는 일부로서 매핑 동작을 수행할 수 있다. 매핑을 수행할 때 오퍼레이팅 시스템에 의해 적용된 규칙은 특정 프로세스에 기초하여 원하는 액세스, 권한 또는 인가를 나타내는 출력으로 특정 PC 태그를 전파하거나 생성할 수 있다.
이러한 방식으로, 동일한 세트의 규칙은 규칙이 PC 태그에 기초한 액세스, 권한 또는 인가의 차이에 대해 로직을 인코딩하는 글로벌 태그를 갖는 공유 페이지와 함께 사용될 수 있다. PC 태그는 또한 메모리 위치를 가리키는 포인터일 수 있으며, 그에 따라 포인터 태그는 다른 태그와 관련하여 본 명세서에서 설명된 방식으로 상이한 태그 값을 상이한 정책에 포함시키는 구조체를 가리킨다는 것을 유의하여야 한다. 이러한 방식으로, 동일한 세트의 PC 태그 값은 정책에 따라 다를 수 있는 프로세스의 상이한 능력을 나타내는데 사용될 수 있다. 예를 들어, P1를 갖는 전술한 바와 같은 X라는 PC 태그 값은 공유 영역에 대해 메모리 안전 정책 또는 데이터 액세스 정책이 있는 전술한 바와 같은 제 1 용도를 가질 수 있다. X라는 동일한 PC 태그 값은 제어 흐름 무결성(CFI)과 같은 제 2의 상이한 정책의 규칙에 의해 부여되는 제 2 용도 및 의미를 가질 수 있다.
허용 가능한 호출, 점프, 리턴 포인트 등의 정적 정의에 기초하여 제어 이전을 제한하는 것과 관련하여 사용될 수 있는 CFI 정책의 양상이 본 명세서서 설명된다. 그러나 CFI 정책에 포함될 수 있는 추가적인 양상 또는 차원은 동적 또는 런타임 호출 정보의 실시와 관련이 있으며, 그럼으로써 리턴되는 제어 이전이 이루어질 수 있는 조건을 더욱 세분화한다. 추가로 설명하면, 루틴 foo(502), bar(504) 및 baz(506)를 포함하는 도 46의 예(500)가 참조된다. 루틴 Foo(502)는 bar(504)로 제어의 런타임 이전(501a)을 초래하는 루틴 bar를 호출하는 어드레스 X1에 있는 호출 명령어를 포함할 수 있다. 그러면 루틴 bar(504)는 루틴 bar로의 제어를 어드레스 X2로 리턴(501b)하는 리턴 명령어를 포함시킨다. 따라서 X2는 X1에서 루틴 bar에게 호출한 다음 루틴 foo 내 명령어의 리턴 포인트 어드레스 또는 위치를 나타낸다. 루틴 Foo(502)는 baz(506)로 baz(506)로 제어의 런타임 이전(501a)을 초래하는 루틴 baz(506)를 호출하는 어드레스 Y1에 있는 제 2 호출 명령어를 포함한다. 그러면 루틴 baz(506)는 루틴 bar로의 제어를 어드레스 Y2로 리턴하는 리턴 명령어를 포함시킬 수 있다. 따라서, Y2는 Y1에서 루틴 baz에게 호출한 다음 루틴 foo에서 명령어의 리턴 포인트 어드레스 또는 위치를 나타낸다.
정적 CFI 정책은 예를 들어, 동적 런타임 제어 흐름 양상을 반영하는 현재 런타임 스택 또는 호출 체인을 기초로 한 제어 흐름 또는 이전을 더 이상 제한하지 않으면서 임의의 두 개의 이전 포인트 사이에서 모든 잠재적 제어 흐름을 가능하게 할 수 있다. 예를 들어, (500)에 도시된 바와 같이 foo(502)가 bar(504)를 호출할 수 있으면, foo 내 X1에서 bar를 호출한 후 반대로 bar로부터 명령어의 어드레스 X2로의 정적으로 허용된 제어 흐름이 있다. 그러나 foo가 지금까지 호출되지 않았거나, bar 호출 이전에 리턴해야 하는 다른 호출을 어떤 것에게 호출하였다면, 리턴 링크를 실행하여 X2로 리턴할 수 없어야 한다. 예(500)에 도시된 바와 같이 런타임 실행이 있는 다른 예로서, (501a)를 통해 Bar(504)에게로의 호출은 (501d)를 통해 Y2에 있는 Foo(502)로 리턴할 수 없어야 한다.
이제 리턴 흐름 경로 제어를 제어하는 동적 CFI 리턴 정책을 시행하는 CFI 정책의 규칙의 확장과 관련하여 사용될 수 있는 기술이 설명될 것이다. X1에 있는 bar에게로의 호출과 같은 특정 호출 또는 부름의 다음에 이루어질 때만 X2와 같은 특정 리턴 위치로의 리턴이 유효하다는 것을 보장하는 동적 CFI 리턴 정책의 경우, 동적 CFI 리턴 정책은 유효하지 않은 리턴을 배제하기 위해 호출이 행해졌을 때 정보를 예컨대 하나 이상의 태그에 저장할 수 있다. 관련 기술분야에서 공지된 바와 같이, 예컨대 RISC-V 명령 세트의 JAL(jump and link) 명령어를 사용하여 호출이 이루어질 때, 리턴 어드레스는 리턴 어드레스 레지스터(RA)에 저장된다. RISC-V 명령어 세트에는 리턴 명령어의 예인 JALR(jump and link register) 명령어가 또한 포함된다. 일 양태에서, JAL로부터 RA 레지스터에 저장된 리턴 어드레스는 그 포인트로 리턴하는 "능력(capability)"으로 특징지을 수 있다. 적어도 하나의 실시예에서, JAL 명령어는 규칙이 적합한 태그 능력을 결과로 생긴 리턴 어드레스로 푸시하게 하는 태그로 태깅될 수 있다. 예를 들어, 리턴 어드레스 레지스터로서 RA를 사용하는 경우, 규칙은 RA 레지스터가 유효한 또는 적합한 리턴 어드레스를 포함하고, 나중에 RA 레지스터의 어드레스가 제어가 이전될 수 있는 리턴 포인트로서 사용될 수 있음을 나타내는 태그를 RA 레지스터 상에 배치할 수 있다. 다시 말해서, RA 레지스터상의 태그는 RA 내의 어드레스가 PC에 로드되어 제어의 리턴 이전을 실행하는 리턴 어드레스로서 사용되는 인가를 제공한다. RA 어드레스를 PC에 로드할 때, RA 태그는 CFI 정책의 규칙에 의해 PC 태그로서 저장될 수도 있다.
리턴시 제어 흐름을 제한하는데 사용될 수 있는 기술을 추가로 설명하면, 실시예는 expect-A와 같은 동적 CFI 태그로 각 리턴 포인트(예를 들어, X2, Y2)에 코드 태깅할 수 있다. 또한 각 JAL 명령어(또는 호출 명령어)를 코드 태깅하면 규칙으로 하여금 JAL 명령어가 (리턴 어드레스가 JAL에 의해 계산되는) RA 레지스터 내의 리턴 어드레스를 적절한 동적-CFI-리턴-투-A(dynamic-CFI-return-to-A) 태그로 태깅하는 것에 대해 평가하게 한다. 동적-CFI-리턴-투-A 태그로 태깅된 RA 레지스터를 사용하는 각 JALR 명령어와 같은 각 리턴에 대해, PUMP 규칙은 다른 정적 CFI 정책 규칙과 관련하여 수행될 수 있는 것처럼 태그(동적-CFI-리턴-투-A)를 PC에 전파할 수 있다. CFI 정책의 규칙은 리턴 명령어에 사용된 RA 레지스터를 체크하는 로직을 구현할 수 있다. 리턴에 사용된 RA 레지스터가 동적-CFI-리턴-투-A 태그로 태깅되지 않으면, 레지스터에는 JALR 명령어와 함께 사용하도록 허용된 유효한 리턴 어드레스가 포함되지 않은 것으로 알려져 있다. 리턴 포인트(예를 들어, X2 및 Y2)에서, 규칙은 (예를 들어, X2의 명령어상의 태그로서) expect-A 코드 태그를 만날 때 PC가 동적-CFI-리턴-투-A로 태깅되어 있는 것을 체크하고, PC로부터 동적-CFI-리턴-투-A 태그를 클리어하는 로직을 구현할 수 있다.
위의 결과로서, 코드는 임의의 리턴 어드레스로 바로 리턴하는 것이 방지된다. 또한 리턴 어드레스가 다른 레지스터와 같은 다른 위치로 복사되면, 규칙은 복사된 값이 리턴 인가 능력을 유지하지 못하게 할 수 있고; 이것은 코드가 동일한 호출에 대해 다수 번 리턴을 수행하는데 사용될 수 있는 리턴 어드레스의 레지스터 내에 사본을 작성하지 못하게 한다. 위의 다른 결과로서, 스택상의 (적절하게 태깅된) 유효한 리턴 어드레스가 (적절하게 태깅되지 않은) 새로운 어드레스로 오버라이팅된 다음 새로운 어드레스로 리턴하려는 시도가 이루어지면, 리턴이 방지된다.
실시예는 동적-CFI-리턴-투-A 태그를 한번을 초과하여 사용하는 기능을 방지 또는 추가로 제한하는 규칙을 또한 포함할 수 있다. 제 1 구현예로서, 실시예는 (동적-CFI-리턴-투-A 태그로 태깅된 RA 레지스터에 저장된) 리턴 어드레스가 기입되거나 복사될 수 있는 곳을 제한하는 규칙을 사용할 수 있다. 예를 들어, 실시예는 적절하게 태깅된 RA 레지스터의 리턴 어드레스만이 적절하게 코드 태깅된 기능 코드 내의 스택에 리턴 어드레스를 기입하게만 하는 규칙을 사용할 수 있다. 제 2 대안적인 구현예로서, 실시예는 PC 상태(예를 들어, PC 태그) 및 원자 메모리 동작을 사용하여 리턴 어드레스를 선형적으로 만드는 (예를 들어, 호출에 뒤이어 오게 하거나 발생하게 하는) 규칙을 포함할 수 있다. 예를 들어, 호출을 수행하면 PC 태그가 유효-리턴-어드레스(valid-return-address)를 표시하도록 설정된다. 규칙은 PC 태그가 유효-리턴-어드레스로 설정되어 있어야만, 리턴을 허용할 수 있다. 리턴 어드레스를 메모리에 기입할 때, PC 태그를 노-리턴-어드레스(no-return-address)로 설정하는 추가 규칙이 사용될 수 있다. 리턴 어드레스를 타깃 레지스터에 복사할 때, PC 태그를 노-리턴-어드레스로 설정할 수 있고 타깃 레지스터는 유효-리턴-어드레스로 태깅되지 않는 규칙이 사용될 수 있다. RA 레지스터로부터의 리턴 어드레스를 사용하여 산술 연산이 수행될 때, 그 결과가 유효-리턴-어드레스로서 태깅되지 않는 규칙이 사용될 수 있다. (예를 들어, PC 태그가 유효-리턴-어드레스로 설정된 경우) 논-리턴-어드레스를 갖는 원자 교환 동작을 이용하여 메모리로부터 리턴 어드레스를 복구하는 것만을 허용하는 규칙이 사용될 수 있다.
일 실시예는 스택 보호 정책을 제공하는 규칙을 추가로 정의할 수 있다. 일 양태에서, 스택 보호 정책은 부분적으로, 정책이 정책 시행을 위한 명령어 및 데이터 둘 모두의 태그를 사용할 수 있는 메모리 안전과 같은 하나 이상의 다른 정책의 확장으로 간주될 수 있다. 다음의 논의 및 본 명세서의 다른 곳에서, 루틴 및 절차와 같은 용어는 상호 교환적으로 사용될 수 있으며 보다 일반적으로는 호출될 때, 결과적으로 호출 스택 상에 새로운 스택 프레임을 생성하는 코드의 호출 가능한 단위를 지칭한다는 것을 유의하여야 한다. 코드의 호출 가능한 단위에 사용될 수도 있는 다른 이름은 함수, 서브루틴, 서브프로그램, 메소드 등을 포함할 수 있다.
도 47을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 런타임 호출을 위한 프레임의 호출 스택을 도시하는 예(520)가 도시된다. (520)에서, 루틴 foo(502)가 G1에게 호출을 수행하여 결국 G2를 호출한다고 가정한다. 따라서 실행중의 한 포인트에서, 루틴 foo가 실행 중이고 루틴 G1에게 제 1 호출을 했고 G1은 루틴 G2에게 호출했다. 요소(522)는 루틴 foo에 대한 제 1 호출 스택 프레임을 표현할 수 있다. 요소(524)는 루틴 G1에 대한 제 2 호출 스택 프레임을 표현할 수 있다. 요소(526)는 루틴 G2에 대한 제 3 호출 스택 프레임을 표현할 수 있다.
런타임 호출 인스턴스 또는 호출을 위한 스택 프레임(예를 들어, 522, 524, 526)에 저장된 정보는 예를 들어 리턴 어드레스, 레지스터 대한 그 호출 인스턴스에 의해 사용된 데이터, 변수 또는 데이터 아이템 등을 포함할 수 있다. 요소(522a 및 524a)는 foo에 대한 프레임(522) 및 G1에 대한 프레임(524)에 각각 포함된 리턴 어드레스를 나타낼 수 있다. 예컨대 악의적인 코드에 의해 수행될 수 있는 하나의 일반적인 공격은 스택(520)에 저장된 (522a 및 524a)와 같은 리턴 어드레스를 수정하는 것일 수 있다. 동적 CFI 리턴 정책에 대해 본 명세서에서 설명된 (예를 들어, 예(500)에서 도 46과 관련하여 설명된)바와 같은 기술을 사용하면, 예컨대 부적절하게 수정된 스택 위치로부터 리턴 어드레스를 사용하여 부적절하거나 유효하지 않은 리턴을 방지할 수 있다. 그러나 스택 보호를 제공하고 리턴 어드레스와 같은 스택 저장 위치의 부적절한 수정을 방지하는 추가 규칙을 또한 시행하는 것이 더 바람직할 수 있다. 따라서 스택 프레임 보호 정책을 위한 이러한 추가 규칙은 (522a)의 부적절한 수정을 허용하기 보다는 (522a 또는 524a)의 수정을 방지한 다음 부적절하게 수정된 리턴 어드레스를 사용하는 리턴을 중지시킬 수 있다.
아래에서 보다 상세하게 설명되는 바와 같이, 상이한 레벨의 스택 보호가 제공될 수 있다. 일 양태에서, 스택 보호는 정적 절차 (본 명세서의 다른 곳에서 설명된 정적 인가 보호 모델이라고도 지칭함)에 기초하여 결정될 수 있거나, 절차 및 또한 특정 절차(본 명세서의 다른 곳에서 설명된 인스턴스 인가 보호 모델이라고도 지칭함)의 호출 인스턴스 둘 모두에 기초하여 결정될 수 있다. 정적 인가 보호 모델을 사용하면, 스택 보호 정책의 규칙은 프레임을 생성하는 특정 절차 또는 루틴에 기초하여 스택 보호를 제공할 수 있다. 예를 들어, 스택이 (520)에서와 같이 foo의 단일 인스턴스에 대해 단일 프레임만을 포함하는 대신에, 현재 시점에서 현재 호출 체인에 포함된 foo의 호출 인스턴스가 다수 개 있을 수 있고 그래서 (예를 들어, 예컨대 foo에 대한 재귀 호출(recurse call)에 기초하여) 루틴 foo에 대한 스택 내에 호출 스택 프레임이 다수 개 있을 수 있다. 정적 루틴 또는 절차에 기초하여, foo의 임의의 인스턴스는 foo의 인스턴스에 대한 임의의 호출 스택 프레임 내의 정보를 수정하거나 액세스할 수 있다. 예를 들어, foo 인스턴스 1은 호출 스택 프레임 1을 가질 수 있고 foo 인스턴스 2는 호출 스택 프레임 2를 가질 수 있다. 스택 보호를 위한 정적 루틴 또는 절차에 기초하여, foo 인스턴스 1의 코드는 스택 프레임 1 및 2에 액세스할 수 있고 foo 인스턴스 2의 코드 또한 스택 프레임 1 및 2에 액세스할 수 있다. 이러한 실시예에서, 동일한 절차 또는 루틴 foo의 모든 인스턴스에 대한 호출 스택 프레임은 동일한 태그로 컬러화될 수 있다. 예를 들어, foo 인스턴스 1에 대한 프레임 1 및 foo 인스턴스 2에 대한 프레임 2는 둘 모두 태그 T1로 컬러화되어 메모리 보안 정책의 규칙이 동일한 루틴 또는 절차의 상이한 인스턴스에 걸쳐 위에서 언급한 스택 프레임 액세스를 가능하게 할 것이다.
스택 보호의 보다 미세한 세분성으로서, 실시예는 정적 루틴 또는 절차뿐만 아니라 루틴 또는 절차의 특정 런타임 인스턴스에 기초하여 스택의 액세스를 추가로 제한하는 스택 보호 정책의 규칙을 사용할 수 있다(예를 들어, 인스턴스 인가 보호 모델). 예를 들어, 위에서 언급한 바와 같이, foo 인스턴스 1은 호출 스택 프레임 1을 가질 수 있고 foo 인스턴스 2는 호출 스택 프레임 2를 가질 수 있다. 정적 루틴 또는 절차 및 또한 스택 보호를 위한 호출 인스턴스에 기초하여, foo 인스턴스 1에 대한 코드는 스택 프레임 1에 액세스할 수 있지만 스택 프레임 2 에 액세스할 수 없으며, foo 인스턴스 2에 대한 코드는 스택 프레임 2에 액세스할 수 있지만 스택 프레임 1에 액세스할 수 없다. 이러한 실시예에서, 절차 또는 루틴의 각 호출 인스턴스에 대한 호출 스택 프레임은 상이한 태그로 컬러화될 수 있다. 예를 들어, foo 인스턴스 1에 대한 프레임 1은 태그 T1로 컬러화될 수 있고 foo 인스턴스 2에 대한 프레임 2는 태그 T2로 컬러화될 수 있으므로 메모리 안전 정책의 규칙은 특정 호출 및 루틴 또는 절차 각각에 기초하여 위에서 언급한 스택 프레임 액세스를 가능하게 할 것이다.
실시예는 예컨대 각각 컬러가 상이한 스택 프레임 내의 상이한 객체 또는 데이터 아이템을 컬러화함으로써 단일 절차 호출 인스턴스를 위한 스택의 상이한 영역 또는 부분의 보다 미세한 레벨의 세분성을 추가로 제공할 수 있다(본 명세서의 다른 곳에서 설명된 객체 보호 모델이라고도 지칭한다). 본 명세서의 다른 곳에서 설명된 바와 같이, 스택 프레임은 루틴 또는 절차의 특정 호출에서 사용되는 데이터 아이템 또는 객체에 대한 저장소를 포함할 수 있으며, 이곳에서 각각의 이러한 데이터 아이템 또는 객체는 상이한 컬러로 태깅될 수 있다. 예를 들어, 도 48을 참조하면, 루틴 또는 절차 foo에 의해 할당된 저장소를 갖는 데이터 아이템(540) 및 스택 프레임(531) 내의 연관된 태깅된 메모리를 도시하는 예(530)가 도시된다. 요소(540)는 루틴 foo에 할당된 저장소를 갖는 변수(540a 내지 540c)를 나타내고 요소(531)는 호출 스택 내의 루틴 foo의 이러한 특정 호출 인스턴스에 대한 호출 스택 프레임을 나타낸다. 요소(531)는 변수 어레이(540a)의 메모리 영역(532), 변수 라인(540b)의 메모리 영역(534) 및 변수 패스워드(540c)의 메모리 영역(536)을 포함한다. 또한, 프레임(531)은 저장된 리턴 어드레스의 메모리 영역(538)을 포함한다. 상이한 영역(532, 534, 536 및 538) 각각은 (533)으로 표시된 바와 같이 상이한 태그로 태깅되거나 컬러화될 수 있다. 영역(532) 내의 각 워드는 Red1로 태깅될 수 있다. 영역(534) 내의 각 워드는 Red2로 태깅될 수 있다. 영역(536)의 각 워드는 Red3로 태깅될 수 있다. 영역(538)의 각 워드는 Red4로 태깅될 수 있다.
또 다른 변형예로서, 실시예는 코드(예를 들어, 루틴, 절차 등) 세트에 대해 상이한 신뢰 영역 또는 경계를 정의하고 상이한 보호 레벨을 제공할 수 있다. 예를 들어, 호출된 모든 루틴이 동일한 신뢰 레벨을 가질 수는 없다. 예를 들어, 개발자는 자신이 작성한 제 1 세트의 루틴을 가질 수 있고 제 1 세트의 코드에 의해 수행된 동작이 악의적인 코드를 포함하지 않은 높은 신뢰 레벨을 가질 수 있다. 그러나 제 1 세트의 루틴은 제 3자에 의해 제공되었거나 인터넷으로부터 획득된 라이브러리로 호출될 수 있다. 라이브러리는 신뢰성 없을 수 있다. 따라서, 실시예는 코드의 상이한 본문 및 각 본문에 의해 사용되는 특정 데이터 아이템에 기초하여 보호 레벨을 변화시킬 수 있다. 예를 들어, 도 49의 예(550)를 참조하면, 신뢰성 있는 사용자 코드 내의 루틴 foo가 라이브러리 내의 루틴 악의(evil)를 호출하고, 영역(534)을 가리키는 악의 포인터(데이터 엔트리 라인(540b)을 가리키는 포인터)에 파라미터로서 통과시킨다고 가정한다. 이러한 경우, (531)의 각 영역을 다른 컬러로 컬러화하거나 태깅하는 대신, 영역(532, 536 및 538) 모두가 Red5와 같은 동일한 컬러로 컬러화될 수 있고, 영역(534)은 Red6과 같은 다른 컬러로 태깅될 수 있다. 이것은 루틴 악의가 신뢰성 없는 코드인 것으로 간주되기 때문에 루틴 악의에 의해 액세스되는 메모리 영역(534)이 메모리 안전의 레벨로서 다른 영역(531)과 상이한 컬러로 태깅되는 것을 추가로 보증하는데 사용될 수 있다. 또한, 악의에 통과된 영역(534)을 가리키는 포인터는 영역(534)과 동일한 컬러 Red6으로 컬러화되거나 태깅될 수 있다. 이러한 방식으로, 메모리 안전 정책 규칙은 악의에 의해 사용된 메모리로의 액세스를 Red6으로 태깅된 메모리로 제한할 수 있다.
특정 루틴, 라이브러리 또는 본문 또는 코드가 특정 신뢰 레벨을 갖고 있는지는 하나 이상의 기준 및 입력을 사용하여 분석한 것에 기초하여 결정될 수 있다. 예를 들어, 런타임 분석 및 라이브러리 코드의 사용에 기초하여, 신뢰 레벨이 결정될 수 있다. 예를 들어, 라이브러리가 다른 알지 못하거나 신뢰성 없는 외부 또는 제 3 자 라이브러리를 호출한다면, 신뢰 레벨은 상대적으로 낮을 수 있다. 코드의 본문에 대한 신뢰 레벨은 코드를 획득한 소스 또는 위치에서 사용될 수 있다. 예를 들어, 인터넷에서 획득한 라이브러리로부터의 코드를 사용하는 것은 신뢰성 없는 것으로 간주될 수 있다. 이에 반해, 임의의 신뢰성 없는 코드를 호출하지 않는 특정 개발자에 의해 개발된 코드는 높은 신뢰 레벨을 가질 수 있다.
스택 프레임 및 스택 보호의 전술한 양상 및 다른 양상은 아래에서 더 상세하게 설명된다.
스택 프레임과 관련하여 그리고 다시 예(530)을 참조하면, 컴파일러는 기존 스택 포인터에 정수(프레임의 크기)를 가산함으로써 새로운 스택 포인터를 생성할 수 있다. 이전 스택 포인터는 스택에 (프레임에) 푸시된 다음 스택으로부터 이를 다시 판독함으로써 복구될 수 있다. 스택 포인터로의 가산은 데이터 아이템(540a 내지 540c)에 대해 (531)에서 전술한 바와 같이 많은 독립 객체를 포함하는 프레임의 총 크기를 나타낼 수 있다. 스택은 이들 3 데이터 아이템(540a 내지 540c)을 위한 공간을 필요로 하고, 컴파일러는 데이터 아이템(540a 내지 540c)에 필요한 전체 공간을 결정할 수 있다. 표준 사용법에서, 컴파일러는 스택 포인터(또는 스택 포인터로부터 생성된 프레임 포인터)로부터 어드레스를 계산함으로써 이들 데이터 아이템(540a 내지 540c)의 스토어(532, 534 및 536)에 각각 액세스한다. 따라서, 실시예에서 컴파일러, 런타임 및 호출 관행은 간단한 포인터 산술을 수행함으로써 스택 호출 프레임의 상이한 영역을 가리키는 포인터를 생성하고 사용할 수 있다.
정적 인가 보호 모델은 객체에 대한 인가가 프레임을 생성하는 루틴 또는 절차와 같은 정적 코드 블록에 속한다는 것을 표시한다. 따라서, 본 명세서의 다른 곳에서 논의된 바와 같이, 프레임을 생성하는 절차 foo는 그 프레임 내의 것을 가리키는 포인터를 생성하는 인가를 갖는다. 가장 단순한 사례에서, 프레임이 더 이전 또는 이후에 스택에 있었더라도, 동일한 인가는 foo로 하여금 자기가 생성한 모든 프레임에 액세스할 수 있게 할 것이다. 정적 인가는 태그(예를 들어, 메모리 셀의 컬러, 컬러화된 포인터, (컬러화된 포인터를 생성하는 코드 태그(예를 들어, 명령어상의 명령어 태그 또는 태그라고도 지칭함)가 로드 시 미리 할당될 수 있음을 의미한다. 인스턴스 인가 보호는 스택상의 함수 호출의 깊이에 기초하여 인가를 제공한다. 객체 보호는 스택 프레임뿐만 아니라 스택에 할당된 객체 레벨에서 보호를 나타낸다. 따라서, 객체 보호는 프레임 내의 한 객체(예를 들어, 어레이, 버퍼)로부터 동일한 프레임상의 다른 객체로의 오버플로우를 검출하고 방지할 수 있게 하는데, 이것은 정적 인가 보호 모델 또는 인스턴스 보호 모델이 있는 간단한 스택 프레임 세분성 PUMP 규칙을 사용하여 달성되지 않은 것이다. 객체 보호는 정적 인가 보호 모델 및 인스턴스 보호 모델 둘 모두에 적용될 수 있다. 객체 보호의 변형예로서, 실시예는 또한 정수와 같은 다수의 상이한 데이터 아이템 서브 객체 및 어레이를 포함하는 구조체와 같은 계층적 객체의 계층적 객체 보호를 사용할 수 있다. 제 1 객체가 하나 이상의 서브 객체 각각의 하나 이상의 레벨을 포함하는 계층적 객체를 갖는 적어도 하나의 실시예에서, 제 1 태그는 제 1 객체에 대해 생성될 수 있고, 그러면 추가의 서브 객체 태그는 제 1 태그에 기초하여 생성될 수 있다. 각 서브 객체 태그는 상이한 서브 객체에 태깅하는데 사용될 수 있다. 서브 객체 태그는 계층 구조에서 서브 객체의 특정 위치를 나타내는 값일 수 있다. 예를 들어, 태그 T1은 서브 객체 2 및 3으로서 2 어레이를 포함하는 구조체와 함께 사용하기 위해 생성될 수 있다. 2 어레이 각각에 대한 상이한 서브 객체 태그는 T1로부터 생성되고 2 어레이 서브 객체에 태깅하는데 사용된다.
이제 본 명세서에서의 기술에 따른 실시예에서 상이한 스택 동작에 대해 스택 메모리와 관련하여 수행될 수 있는 처리에 대해 설명될 것이다. 스타트업 시, 스택 메모리는 프리-스택 프레임 태그(free-stack frame tag)를 사용하여 마킹되거나 태깅된 모든 메모리 셀을 가질 수 있다. 본 명세서의 다른 곳에서의 논의 및 기술과 일관하여, 이러한 태깅은 PUMP 규칙을 호출함으로써 수행될 수 있다. 초기에 스택 메모리 셀을 프리-스택 프레임 태그에 태깅하는 것은 전체 스택에 대해 한번에 수행될 수는 없지만, 그 대신 스택을 확장하는 커널 페이지 결함 핸들러에서 점진적으로 수행될 수 있음을 주목하여야 한다.
예컨대 컴파일러에 의해 새로운 스택 프레임을 할당하는 것과 관련하여, 새로 할당된 프레임에는 새로운 프레임 태그가 생성될 수 있다. 새로운 프레임을 가리키는 포인터는 새로운 프레임 태그로 태깅될 수 있다. 예를 들어, 실시예는 새로운 프레임 포인터를 생성하는 (예를 들어, (스택 포인터에 가산함으로써) 포인터 연산을 수행하는 가산 명령어와 같은) 명령어에 태깅할 수 있으며, 이 경우 명령어상의 태그는 정책 규칙을 트리거하여 새로운 프레임 태그를 생성한다. 규칙 및 태그 전파를 사용하면, 스택 포인터에 대해 특수 태그가 생성되어 스택 포인터에 태깅하는데 사용될 수 있다. 이어서, 각각의 프레임 포인터마다, 고유한 프레임 포인터 태그가 스택 포인터 특수 태그로부터 도출될 수 있고, 프레임 포인터는 자기의 고유한 프레임 포인터 태그로 태깅될 수 있다. 이러한 실시예에서, 프레임 포인터 태그는 스택 포인터의 태깅된 사본(예를 들어, 가산 또는 0)으로부터 생성될 수 있다.
새로운 스택 프레임이 예컨대 루틴 또는 절차의 새로운 호출을 위해 할당될 때, 새로 할당된 스택 프레임의 메모리 셀은, 예를 들어, 엄격한 객체 초기화(strict object initialization)라고 지칭되는 제 1 기술 또는 느린 객체 컬러화(lazy object coloring)라고 지칭될 수 있는 제 2 기술을 사용하여 태깅되거나 컬러화될 수 있다.
엄격한 객체 초기화의 제 1 기술을 사용하면, 새로 할당된 프레임의 프리 스택 프레임 셀은 모두 초기에 예컨대 프레임의 정적 객체에 기초하여 하나 이상의 컬러로 컬러화되거나 태깅된다. 이러한 초기 컬러화는 예를 들어, 연관된 호출에 대한 정보를 저장하기 위해 나중에 프레임을 사용하기 전에 새로 할당된 프레임의 초기화 처리의 일부로서 수행될 수 있다. 실시예는 프리 스택 프레임 셀의 컬러화 또는 태깅을 수행하는 규칙을 트리거하는 코드를 예컨대 프레임의 정적 객체에 기초하여 의도된 하나 이상의 컬러에 가산할 수 있다. 명령어상의 코드 태그는 연관된 메모리 셀 컬러화를 인가하고 정의하는데 사용될 수 있다. 프레임의 컬러화된 메모리 셀의 후속 스토어 또는 판독은 예컨대 메모리 안전 정책 규칙에 따라 프레임 메모리 셀 컬러에 기초하여 허용되거나 허용되지 않을 수 있다(예를 들면, 컬러 C1로 태깅된 메모리 셀의 경우, 규칙은 역시 동일한 컬러 C1의 태그를 갖는 포인터를 사용하여 컬러화된 메모리 셀 내용에 액세스하는 메모리 동작을 허용하지만, 포인터가 상이한 컬러 C2라면, 메모리 동작을 허용하지 않을 수 있다). 또한 명령어상의 코드 태그는 절차 내에서 메모리 동작을 수행할 수 있는 인가를 제공할 수 있다.
느린 객체 컬러화의 제 2 기술을 사용하면, 엄격한 객체 초기화 기술처럼 모든 스택 객체의 초기 컬러화는 없다. 오히려, 느린 객체 컬러화를 사용하면, 프리 스택 프레임으로서 태깅된 스택 메모리 위치로의 스토어는 그 스토어를 허용하고 기입기(writer)에 기초하여 메모리 위치의 컬러를 또한 변경하는 규칙을 트리거하는 결과를 가져온다. 프리 스택 프레임으로서 태깅된 스택 메모리 위치에 대한 판독은 초기화되지 않은 메모리 판독이며 정책이 초기화되지 않은 메모리 판독을 허용할지/허용하지 않을지에 따라 허용되거나/허용되지 않을 수 있다. 느린 객체 컬러화를 사용하면, 생성시 프레임의 모든 메모리 셀을 초기에 전체적으로 태깅하는 규칙을 호출하는 코드의 초기 블록이 실행되지 않는다. 오히려, 메모리 셀은 스토어 동작과 관련하여 호출되는 규칙에 의해 태깅된다.
적어도 하나의 실시예에서, 엄격한 객체 초기화 또는 느린 객체 컬러화를 사용할지 여부는 원하는 보호 레벨 및 방어 불가능한 취약성의 발생에 따라 달라질 수 있다.
스택/프레임 포인터로부터 데이터에 직접 액세스하는 루틴 또는 절차 내의 코드는 코드 태깅되어 그렇게 하도록 허용된다. 느린 객체 컬러화와 관련하여, 메모리 셀에 저장하게 되면 전술한 바와 같이 기입기에 기초하여 메모리 셀을 컬러화하게 된다. 예를 들어, 예(530)를 다시 참조하면, 프레임(531)을 갖는 루틴 foo의 스토어 명령어는 어레이(532) 내의 메모리 위치에 값을 기입할 수 있다. 실제로 현재 스택 보호 정책에 따라, 스토어 명령어가 foo에 대한 호출 프레임의 어레이(532) 내의 위치에 기입하기 위해, 스토어 명령어는 Red1이라는 태그를 갖고 있어야 할 수 있다. 정책의 제 1 규칙은 스토어 명령어에 대해 이러한 체크를 수행하도록 트리거될 수 있다. 따라서, 실시예는 컴파일러가 재 1 규칙을 트리거하여 스토어 명령어를 Red1로 태깅하는 코드 시퀀스를 생성하게 할 수 있다. (예를 들어, 전술한 것의 변형예로서, Red1과 같은 메모리 셀상의 태그는 명령어 스토어 또는 다른 명령어상의 태그와 관련이 있지만 동일하지 않을 수 있다. 예를 들어, "Red1code" CI 태그는 이 태그를 가진 명령어가 Red1 태깅 메모리 셀에 액세스할 수 있고 Red1 태깅된 메모리 셀을 생성할 수 있음을 나타낸다. 스토어 명령어가 현재 명령어일 때, 이 명령어가 Red1인지를 보장하기 위해 명령어 태그를 체크하는 전술한 제 1 규칙이 트리거될 수 있다. 출력으로서, 규칙은 어레이(532) 내의 메모리 위치를 Red1 태그로 태깅할 수 있다.
특정 개체를 가리키는 포인터를 생성하는 절차 내의 코드는 테인트에 태깅하거나 그 객체에 대한 포인터를 설정한다. 포인터는 후속 명령어에서 절차의 자체 사용에 대한 것일 수 있으며 및/또는 인수(argument)로서 다른 절차로 넘겨될 수 있다.
레지스터 값을 프레임에 저장하거나 프레임으로부터 레지스터 값을 복원하는 것은 프레임 인가에 기초할 수 있다. 레지스터 값을 저장하는 스택 프레임의 메모리 위치(들)는 스택 프레임에서 고유한 객체로서 취급될 수 있다. 명령어 태깅은 그러한 태깅된 스토어 및 로드 명령어에 대한 인가를 제공한다. 느린 객체 컬러화를 사용하면, 메모리 셀에 데이터를 저장하는 인가로 태깅된 스토어 명령어는 또한 기입기(예를 들어, 스토어 명령어를 포함하는 절차)에 기초하여 메모리 셀에 태깅하는 인가를 제공한다.
스택에 넘겨진 절차 인수는 호출자와 피호출자 둘 모두가 액세스할 수 있게 하는 태그로 마킹될 수 있다. 리턴 어드레스는 특수하게 태깅될 수 있음(예를 들어, 예컨대 도 46과 관련하여 본 명세서에서 설명된 동적 CFI 리턴 정책)을 주목하여야 한다. 따라서, (예를 들어, 예컨대 내포된(nested) 호출 또는 재귀 호출과 관련하여) 리턴 어드레스가 스택에 저장되면, 리턴 어드레스의 태깅으로 인해 스토어는 스택상에 리턴 어드레스를 오버라이팅하도록 허용되지 않을 것이다. 스택에서 도출된 포인터(stack-derived pointer)가 다른 절차에게로의 호출과 관련하여 다른 프레임에 넘겨질 때, 포인터를 사용하여 수행된 메모리 액세스는 본 명세서의 다른 곳에서 설명한대로 메모리 안전 정책의 규칙을 트리거하는 결과를 가져온다. 메모리 위치를 가리키는 포인터를 생성한 명령어는 특정 메모리 위치의 태그에 기초하여 태깅될 수 있다. 명령어 태그는 메모리 위치에 액세스하는 인가를 표시할 수 있다. 명령어는 메모리 위치에 액세스하는 인가를 표시하기 위해 포인터에 태깅하는 규칙을 트리거할 수 있다. 예를 들어, 규칙은 명령어와 동일한 태그 또는 명령어 태그에 기초한 변형을 포인터에 할당할 수 있다. 따라서, 일 양태에서, 포인터를 생성한 명령어는 또한 포인터를 통해 메모리 위치에 액세스하는 능력을 창출하고 인수로서 호출된 절차에 넘겨진 포인터를 통해 그 기능을 공유한다. 느린 객체 컬러화를 사용하면, 포인터가 프리 스택 프레임 셀에 태깅하는 인가를 제공하는 태그를 가져야 할 것이며, 이는 힙-메모리 안전 포인터에 대해 허용되지 않을 수 있다.
(예를 들어, 예컨대 호출된 루틴의 완료로 인해) 스택으로부터 프레임을 제거하는 결과를 가져오는 리턴 또는 다른 동작과 관련하여, 태깅된 코드는 프레임을 클리어할 수 있다. 이러한 코드상의 태그는 이 프레임과 연관된 모든 프레임 객체 태그를 프리 스택 프레임 셀 태그로 변경하는 인가를 제공한다.
본 명세서에서의 기술에 따라 컴퓨터 시스템의 실시예에서 실행되는 프로그램의 코드는 예외 처리를 수행하는 코드를 포함할 수 있다. 관련 기술분야에 공지된 바와 같이, 예외 처리는 예외 핸들러에 의해 수행되는 특수 처리를 요구하는 이례적인 또는 예외적인 조건의 발생을 나타내는 예외에 응답하여 수행되는 처리이다. 따라서 예외가 프로그램의 제 1 포인트에서 발생하면, 정상적인 프로그램 실행 흐름이 중단되어 제어가 예외 핸들러로 이전된다. 제어를 핸들러에 이전하기 전에, 현재의 실행 상태가 미리 결정된 위치에 저장될 수 있다. 예외가 핸들러에 의해 처리된 이후 프로그램 실행이 재개될 수 있으면, 프로그램의 실행이 재개될 수 있다(예를 들어, 그러면 제어는 프로그램의 제 1 포인트 다음으로 다시 이전될 수 있다). 예를 들어, 0으로 나누는 연산은 핸들러가 예외를 처리한 이후 프로그램 실행이 재개될 수 있는 예외를 초래할 수 있다. 예외 핸들러를 구현하는 것과 관련하여, 실시예는 setjump 및 longjump와 같은 라이브러리 루틴을 사용할 수 있다. 예를 들어, setjump 및 longjump는 각각 다음과 같이 정의되는 표준 C 라이브러리 루틴인 setjmp 및 longjmp일 수 있다.
여기서 setjmp는 로컬 jmp_buf 버퍼를 설정하고 이것을 점프를 위해 초기화한다. setjmp는 나중에 longjmp가 사용할 수 있도록 env 인수에 의 해 특정된 환경 버퍼에 프로그램의 호출 환경을 저장한다. 리턴이 직접 호출로부터 온 것이면, setjmp는 0을 리턴한다. 리턴이 call to longjmp로부터 온 것이면, setjmp는 0이 아닌 값을 리턴한다.
여기서 longjmp는 프로그램의 동일한 호출에서 setjmp 루틴의 호출에 의해 저장된 환경 버퍼 env의 컨텍스트를 복원한다. 내포된 신호 핸들러로부터 longjmp를 호출하는 것은 정의되지 않는다. value로 지정된 값은 longjmp로부터 setjmp로 넘겨진다. longjmp가 완료된 후, setjmp의 대응하는 호출이 방금 리턴된 것처럼 프로그램 실행이 계속된다. longjmp에 넘겨진 값이 0이면, setjmp는 마치 1을 리턴한 것처럼 동작할 것이며; 그렇지 않으면 값을 리턴한 것처럼 거동할 것이다.
따라서 setjmp는 프로그램의 현재 상태를 저장하는데 사용될 수 있다. 프로그램의 상태는 예를 들어, 메모리의 내용(즉, 코드, 글로벌, 힙 및 스택) 및 그 레지스터의 내용에 따라 달라진다. 레지스터의 내용은 스택 포인터, 프레임 포인터 및 프로그램 카운터를 포함한다. setjmp는 프로그램의 현재 상태를 저장하여 longmp가 프로그램 상태를 복원할 수 있도록 하며 그래서 프로그램 실행 상태를 setjmp가 호출되었을 때의 상태였던 대로 리턴한다. 달리 말하면, longjmp()는 리턴하지 않다. 오히려, longjmp가 호출되면, 실행은 (setjmp에 의해 저장된 대로) 이전에 저장된 프로그램 상태에 의해 나타내는 특정 포인트로 리턴하거나 재개한다. 따라서 표준 호출 또는 리턴 관행을 사용하지 않고 longjmp()는 신호 핸들러로부터 프로그램에 저장된 실행 포인트로 다시 제어를 이전하는데 사용될 수 있다.
예를 들어, 도 50이 참조된다. 예(560)에서, 루틴 main은 루틴 first(563)를 호출할 수 있고, 루틴 first(563)는 루틴 second(564)를 호출할 수 있다. 도시된 바와 같이, main(562)은 루틴 first를 호출하기 전에 포인트 X1에 있는 call to setjmp를 포함할 수 있다. 먼저 setjmp가 포인트 X1에서 호출되고, 0을 리턴한 다음 루틴 first가 호출된다. longjmp가 실행된 후, setjmp는 1을 리턴한다. 루틴 second(564)는 setjmp가 호출되었던 위치 X1에 있는 메인으로 제어를 이전시키게 하는 포인트 X2에 있는 call to longjmp를 포함한다. 이제 setjmp가 다시 호출되고 1을 리턴하므로, first가 호출되지 않고 제어는 NEXT로 진행된다.
스택 보호 정책과 관련하여, 이전에 settmp에 의해 저장된 포인트 X1로 실행을 재개하기 전에 스택을 클리어하는 것이 바람직할 수 있다. 예를 들어, 위의 호출 체인 main-first-second에 기초하여, 3 스택 프레임은 호출 스택에 존재할 수 있고 longjmp 호출과 setjmp 호출 사이의 호출 체인에서 호출과 연관된 스택 메모리를 클리어하는 처리가 수행될 수 있다. 특히, longjmp의 코드는 이 예에서 first(563) 및 second(564)에 대한 스택 프레임을 클리어하는 코드를 포함할 수 있다. 이제 스택 보호 정책에 따라 이러한 스택 클리어 동작을 수행하는 것과 관련하여 사용될 수 있는 기술이 설명될 것이다.
프로그램 상태를 스택 메모리에 저장하는 setjmp를 수행할 때의 스택 보호 정책과 관련하여, 실시예는 현재의 스택 포인터 메모리 셀을 식별된 태그 컴포넌트로 태깅하여, 후속 longjmp와 관련하여 스택이 setjmp 이래로 변경되지 않았음을 규칙이 체크할 수 있도록 한다. 데이터는 현재 프로그램 상태를 나타내는, setjmp 데이터 구조체인 jmpbuf에 저장될 수 있다. 저장된 데이터는 스택 포인터, 프로그램 카운터, 제 1 포인터((예를 들어, 현재 스택 포인터 메모리 셀을 가리키는) 구별된 태그 컴포넌트로 태깅된 메모리 위치를 가리키는 것이 허용되는 포인터로서 태깅됨) 및 제 2 포인터(longjmp 처리를 수행하는 인가를 제공하는 longjmp-clearing-authority-pointer로서 태깅됨)를 포함한다. 적어도 하나의 실시예에서, longjmp-clearing-authority-pointer는 이 절차에서 재귀적으로 호출될 수 있는 절차들의 세트에서 프레임과 연관된 태그를 클리어하는 인가만을 제공할 수 있다.
longjmp를 수행할 때 스택 보호 정책과 관련하여, 코드는 현재의 스택 포인터가 set jump 구조체(예를 들어, setjmp 데이터 구조체, jmpbuf)의 저장된 스택 포인터보다 깊은 스택 위치를 나타내는지를 체크할 수 있다. (set jump에 의해 저장된 것으로서) 저장된 스택 포인터를 포함하는 set jump 구조체의 메모리 셀이 (set jump 구조체의) 태깅된 제 1 포인터와 호환 가능한 태그를 갖는지 확인하는 규칙이 트리거될 수 있다. 현재 스택 포인터와 (set jump 구조체에서 set jump에 의해 이전에 저장된 것으로) 저장된 스택 포인터 사이의 모든 스택 메모리 위치를 클리어하는 코드가 실행될 수 있다. 이러한 코드는 스택 클리어링 인가를 제공하는 longjmp-clearing-authority-pointer(예를 들어, 클리어된 위치를 가리키는데 사용된 제 2 포인터)로서 태깅된 위에서 언급한 제 2 포인터를 사용하여 클리어를 수행할 수 있다. 규칙은 클리어링을 수행하는 코드에 의해 트리거될 수 있고, 이 경우 규칙은 제 2 포인터가 longjmp-clearing-authority-pointer로서 태깅되었는지를 체크한다. longjmp의 명령어는 호출된 규칙이 고유하게 태깅된 명령어로 하여금 longjmp-clearing-authority-pointer로서 태깅된 포인터를 사용할 수 있도록 고유하게 태깅된다. longjmp에 없는 다른 코드는 longjmp-clearing-authority-pointer로서 태깅된 포인터를 사용할 수 없다(예를 들어, 다른 코드는 longjmp-clearing-authority-pointer 사용을 허용하도록 태깅되지 않는다).
적어도 하나의 실시예에서, 명령어의 태깅은 컴파일러가 원하는 명령어 태깅 및/또는 메모리 위치 태깅을 수행하도록 규칙을 호출하는 명령어 시퀀스를 발생하게 함으로써 수행될 수 있다. 예를 들어, 스택 메모리 위치 태깅의 경우, 컴파일러는 스택 위치의 태그를 초기화하거나 재설정하는 규칙을 트리거하는 스토어 명령어를 갖는 명령어 시퀀스를 생성할 수 있다. 태깅 명령어의 경우, 컴파일러는 명령어에 대한 태그가 명령어에 의해 액세스된 태깅된 메모리 위치와 연관된 컬러에 기초할 수 있는, 명령어에 태깅하는 규칙을 트리거하는 스토어 명령어를 갖는 명령어 시퀀스를 생성할 수 있다. 연관된 스택 프레임을 갖는 호출로부터의 리턴과 관련하여, 스택으로부터 프레임을 클리어하는 코드가 추가될 수 있다. 엄격한 객체 초기화가 사용되고 호출에 응답하여 생성된 새로운 프레임이 생성될 때, 새로운 프레임의 객체를 적절히 태깅하거나 컬러화하는 코드가 추가될 수 있다.
이제 도 51 내지 도 53을 참조하여, 예를 들어, 악성 코드에 의해 행해지는 것과 같이, 스택에 행해질 수 있는 상이한 인가되지 않은 또는 의도되지 않은 수정(예를 들어, 스택 수정을 통한 공격을 지칭하는 "스택 공격") 또는 비 악의적인 코드에 의한 의도하지 않은 스택 수정(예를 들어, 우발적인 오버라이팅 또는 버퍼 오버 플로우)의 예가 설명될 것이다.
도 51 내지 도 52는 제 3 자 코드(예를 들어, 호출된 라이브러리 루틴)와 같은 코드 모듈에 의해 행해진 스택 수정과 관련하여 스택 공격을 방지하기 위해 취해질 수 있고 임의의 공격자 모델로서 특징지을 수 있는 조치를 도시한다. 따라서, (570 및 575)의 사례는 예를 들어, 승인 받지 않거나 의도하지 않은 스택 수정을 수행하는 코드를 포함하는 호출된 제 3 자 라이브러리 루틴의 결과로서, 발생할 수 있다. 또한, 스택 수정은 호출된 라이브러리 루틴의 코드에 의해 추가로 호출되는 또 다른 루틴에 의해 이루어질 수도 있다. (570 및 575)의 각 라인은 3 개의 정보 열을 포함한다. 각 라인(572a 내지 572h)에서, 열 1은 원하지 않는 런타임 실행 거동을 나타내는 것을 방지하는 아이템을 식별하고, 열 2는 열 1의 원하지 않는 거동을 회피하기 위해 취해질 수 있는 예방 조치를 식별하고, 열 3은 열 2의 예방 조치를 구현하거나 시행하는데 사용될 수 있는 하나 이상의 메커니즘을 식별한다. 일반적으로, 열 3에서, 특정 시스템에 따라 독립적으로 및 별도로 구현될 수 있는 대안의 메커니즘이 나열되어 있다. 예를 들어, 종래의 시스템은 제 1 메커니즘으로서 별도의 프로세스를 사용할 수 있는 반면, 제 2 시스템은 대안적으로 능력을 사용할 수 있고, 제 2 시스템은 선택적으로 특정 스택 위치의 컬러화 또는 태깅을 사용할 수 있다.
본 명세서의 다른 곳에서의 논의와 일관성 있게 추가로 설명하면, 호출이 이루어질 때 실행되는 프롤로그 코드(prolog code)와 같은 코드는 리턴 어드레스 및 레지스터를 스택에 기입한다. 프롤로그 코드는 스택 위치를 특수 태그로 태깅하여 코드가 스택 위치를 수정하거나 일반적으로 스택 위치에 액세스할 수 있는 것을 제한하는 규칙을 호출할 수 있다. 예를 들어, 프롤로그 코드는 리턴 어드레스, 레지스터 등을 스택 프레임의 메모리 셀에 저장하기 위해 메모리 기입/스토어를 수행할 수 있다. 프롤로그 코드의 이러한 기입/스토어 명령어는 메모리 위치를 특수한 것으로 마킹하고 코드가 메모리 셀을 수정할 수 있는 것을 제한하기 위해 스택 프레임의 메모리 셀을 특수 태그인 STACK FRAME TAG로 태깅하는 규칙을 호출할 수 있다. 프롤로그 코드의 기입/스토어 명령어는 이와 같은 태깅을 수행할 수 있는 명령어를 제한하는 PROLOG STACK TAG 태그로도 태깅될 수 있다. 다음은 스택 프레임의 메모리 셀을 특수 태그인 STACK FRAME TA로 태깅하여 메모리 위치를 특수하게 마킹하고 코드가 메모리 셀을 수정할 수 있는 것을 제한하는 프롤로그 코드의 기입/스토어 명령어에 의해 호출된 규칙에 의해 시행되는 로직의 예이다:
전술된 규칙 로직에서, 출력 태그는 스택 위치에 놓인 태그를 지칭한다.
유사한 방식으로, 리턴을 수행하면서 호출되는 에필로그 코드(epilogue code)와 같은 다른 코드는 스택 또는 그 일부를 클리어하는 것이 허용될 수 있다. 에필로그 코드는 EPILOG STACK TAG라는 특수 태그(예를 들어, CI 태그)로 태깅될 수 있으며, 특수 태그인 STACK FRAME TAG로 태깅된 포인터의 액세스를 통해 인가를 부여받을 수 있다. 에필로그 코드는 STACK FRAME TAG으로 특수하게 태깅된 포인터를 사용하여 기입/스토어 동작을 사용하여 전술한 스택 클리어 동작을 수행할 수 있다. 스택 클리어링을 수행하는 것을 추가로 제한하기 위해, 에필로그 코드는 위에서 언급된 대로 태깅될 수 있다. 이러한 실시예에서, 기입/스토어 명령어는 (STACK FRAME TAG으로 태깅된) 특수 태깅된 포인터를 사용하여 에필로그 코드에 의해서만 스택 클리어링이 수행될 수 있는 정책을 시행하기 위해 다음의 로직을 구현하는 규칙을 호출할 수 있다:
스택으로부터 리턴 어드레스 및 레지스터를 복원하도록 의도된 코드에는 스택의 이렇게 특수 태깅된 메모리 셀을 판독하는 인가가 부여될 수 있다. 이러한 인가는 예를 들어 다음과 같은 것: 코드가 스택의 특수 태깅된 메모리 셀에 액세스하는 것이 허용됨을 나타내는 코드에 태깅하는 것(CI 태그), 코드가 인가를 갖고 있음을 표시하기 위해 PC에 태깅하는 것, 또는 포인터가 특수 태깅된 메모리 셀을 가리키고 포인터상의 태그가 액세스 인가를 나타내는 코드에 의해 사용되는 포인터에 태깅하는 것 중 임의의 것에 의해 부여될 수 있다: 예를 들어, 판독/로드 명령어는 STACK FRAME TAG으로 태깅된 스택 메모리 셀을 판독하는 인가를 부여받을 수 있다. 일 실시예에서, 판독/로드 명령어는 (STACK FRAME TAG로 태깅된) 특수 태깅된 포인터를 사용하는 판독/로드 명령어만을 허용함으로써 스택 메모리 위치로부터 판독하는 인가를 부여받을 수 있다. (STACK FRAME POINTER로 태깅된) 특수하게 태깅된 포인터를 사용하는 판독/로드 명령어만을 허용하여 (STACK FRAME TAG로 태깅된) 특수 태깅된 스택 메모리 위치로부터 판독하는 규칙 로직은 다음과 같을 수 있다:
전술한 것의 변형예로서, 판독/로드 명령어는 판독/로드 명령어에 의해 사용되는 포인터를 특수 태그 STACK FRAME TAG로 태깅함으로써 인가를 부여받을 수 있다.
(STACK FRAME INSTRUCTION로 태깅된) 특수 태깅된 명령어를 사용하는 판독/로드 명령어만 허용하여 스택 메모리 위치로부터 판독하는 규칙 로직은 다음과 같을 수 있다:
메커니즘의 예는 아래에서 그리고 다른 곳에서 더 상세하게 설명된다.
요소(572a)는 호출 루틴(호출자)에게 절대로 리턴하지 않는 호출된 루틴(피 호출자)의 바람직하지 않은 런타임 거동을 식별한다. 이 거동을 방지하기 위해, 취해진 조치는 각 호출과 연관된 제한 시간을 갖는 것으로, 이 경우 호출된 루틴을 완료하는데 최대 양의 시간이 허용될 수 있다. 최대 양의 시간이 경과한 후, 호출된 루틴의 런타임 실행이 종료된다. 타임 아웃을 구현하는 메커니즘은 제 3 자 코드의 호출된 루틴이 타임 아웃을 시행하는 별도의 스레드로부터 이루어지게 하는 것, 또는 시간 또는 명령어 제한된 호출을 사용하여 호출된 루틴의 시간 양을 직접 제한하는 것을 포함할 수 있다.
요소(572b)는 호출된 루틴이 메모리와 같은 이용 가능한 자원을 소모할 수 있는 자원 고갈의 바람직하지 않은 런타임 거동을 식별한다. 이 거동을 방지하기 위해, 취한 조치는 호출된 루틴에서 사용 가능해진 자원을 제한하는 것일 수 있다. 타임 아웃을 구현하는 메커니즘은 제 3 자 코드의 호출된 루틴이 최대 자원 제한을 시행하는 별도의 스레드로부터 이루어지게 하는 것 또는 특수 명령어 제한된 호출을 사용하여 호출된 루틴의 자원의 양을 직접 제한하는 것을 포함할 수 있다.
요소(572c)는 예컨대 예상된 호출을 또 다른 루틴에 행함으로써 예기치 않은 인가를 행사하는 호출된 루틴의 원하지 않은 런타임 거동을 식별한다. 이 거동을 방지하기 위해, 취한 조치는 호출된 루틴의 인가를 허용 가능한 최소 인가로 제한하는 것일 수 있다. 이것을 구현하는 메커니즘은 PC를 피호출자 또는 호출된 루틴의 인가 및 제어 능력으로 태깅하는 것, 호출된 루틴에 액세스 가능한 파일 시스템 또는 다른 자원의 일부를 제한하는 것, 및 호출된 루틴이 행할 수 있는 것을 허용 가능한 시스템이 호출하는 것을 제한하는 것을 포함할 수 있다.
요소(572d)는 호출된 루틴에 의해 차후에 호출된 다른 루틴에 의해 레지스터에 남아 있는 아이템을 판독하는 호출된 루틴의 원하지 않은 런타임 거동을 식별한다(예를 들어, mycode는 라이브러리에서 P1을 호출하고 P1은 루틴 악의를 호출하고 P1은 악의에 의해 레지스터에 남아 있는 데이터를 판독할 수 있다). 이 거동을 방지하기 위해, 입력 없고(non-input) 리턴 없는(non-return) 레지스터를 클리어하는 조치가 취해질 수 있다. 이것을 구현하는 메커니즘은 명시적인 레지스터 클리어를 수행하는 것, 리턴 없고 입력 없는 레지스터를 비롯한 스택의 일부를 컬러화하여 이들이 호출된 루틴에서 판독될 수 없도록 하는 것, 및 별도의 프로세스가 호출된 루틴을 호출하게 하는 것을 포함할 수 있다.
요소(572e)는 호출된 루틴에 의해 차후에 호출된 다른 루틴에 의해 스택에 남아있는 아이템을 판독하는 호출된 루틴의 원하지 않은 런타임 거동을 식별한다(예를 들어, mycode는 라이브러리 내 P1을 호출하고 P1은 루틴 악의를 호출하고, P1은 악의에 의해 스택에 남아있는 데이터를 판독할 수 있다). 이러한 거동을 방지하기 위해, 호출된 스택을 액세스 불가능하게 만드는 조치가 취해질 수 있다(예를 들어, 악의와 같은 추가로 호출된 다른 루틴에 의해 사용되는 스택 영역은 P1과 같은 처음 호출된 루틴에 액세스 불가능하다). 이것을 구현하는 메커니즘은 (예를 들어, 처음 호출된 루틴 P1 및 추가로 호출된 루틴에 대해) 별도의 스택을 사용하는 것, 능력(예를 들어, PC에 태깅하거나, 특별한 스택 영역에 액세스하도록 허용된 특수 태깅된 포인터를 사용하여 스택 영역을 판독하도록 허용된 코드의 기능 또는 인가를 제한하는 것), 컬러화(예를 들어, 스택의 데이터 영역을 태깅하여 코드가 액세스할 수 있는 것을 제한하는 것), 및 별도의 프로세스가 호출된 루틴을 호출하게 하는 것을 포함할 수 있다.
요소(572f)는 스택 프리픽스(stack prefix) 내의 아이템을 고쳐 기입하는(write over) (예를 들어, 리턴 어드레스를 식별하는 리턴 어드레스 영역을 오버라이팅하는) 호출된 루틴의 원하지 않은 런타임 거동을 식별한다. 스택 프리픽스는 일부 이전 호출자에게 리턴하는데 필요한 정보를 포함하는 스택의 영역일 수 있다. 이러한 거동을 방지하기 위해, 취하는 조치는 스택 프리픽스가 호출된 루틴에 액세스할 수 없게 하거나 기입할 수 없게 하는 것이다. 이것을 구현하는 메커니즘은 호출된 루틴 및 호출된 루틴을 호출하는 사용자 코드가 별도의 스택을 사용하게 하는 것, 능력을 사용하는 것(예를 들어, 특수 태깅된 코드 또는 PC 태그 또는 특수 태깅된 포인터를 통해 인가가 제공된 코드를 통해 액세스할 수 있게 하는 것), 컬러화를 사용하는 것(예를 들어, 호출된 루틴이 액세스할 수 없도록 스택 프리픽스의 데이터 아이템을 특수 태그에 태깅하는 것), 및 별도의 프로세스가 호출된 루틴을 호출하게 하는 것을 포함할 수 있다.
요소(572g)는 스택 프리픽스에서 데이터를 판독한 호출된 루틴의 원하지 않은 런타임 거동을 식별한다. 이러한 거동을 방지하기 위해, 취한 조치는 (572f)에서 설명한 것과 유사한 메커니즘을 사용하여 스택 프리픽스를 호출된 루틴에 액세스할 수 없게 만드는 것이다.
요소(572h)는 예컨대 포인터가 스택 프리픽스에 저장되어 있는 리턴 어드레스로 포인터를 오버라이트함으로써 스택 프리픽스에서 제어 흐름을 리다이렉트하는 호출된 루틴의 원하지 않은 런타임 거동을 식별한다. 이러한 거동을 방지하기 위해, 스택 프리픽스에 저장된 리턴 어드레스를 보호하는 조치가 취해질 수 있다. 일 양태에서, 요소(572h)는 (572h)의 특정 인스턴스를 식별하므로 (572h)의 메커니즘은 (572f)의 메커니즘과 유사하다. 이를 구현하는 메커니즘은 호출된 루틴 및 호출된 루틴을 호출하는 사용자 코드가 별도의 스택을 사용하게 하는 것, 능력을 사용하는 것(예를 들어, 특수 태깅된 코드 또는 PC 태그 또는 액세스 인가에 의해 태깅되는 특수 태깅된 리턴 포인터를 통해 인가가 제공된 코드를 통해 액세스할 수 있게 하는 것), 컬러화를 사용하는 것(예를 들어, 호출된 루틴이 액세스할 수 없도록 리턴 어드레스를 포함하는 스택 프리픽스의 메모리 위치를 특수 태그로 태깅하는 것), 및 별도의 프로세스가 호출된 루틴을 호출하게 하는 것을 포함할 수 있다.
도 53은 임의의 입력 공격자 모델과 관련하여 스택 공격을 방지하기 위해 취할 수 있는 조치를 도시한다.
요소(581a)는 실행 루틴의 현재 프레임 내의 의도하지 않은 아이템을 고쳐 기입하는 코드를 실행하는 원하지 않은 런타임 거동을 식별한다. 이러한 거동을 방지하기 위해, 취한 조치는 객체 무결성을 유지하는 것일 수 있다. 이를 구현하는 메커니즘은 (예를 들어, 특수 태깅된 코드를 구비한 능력 또는 PC 태그를 통해서 또는 액세스 인가에 의해 태깅된 특수 태깅된 리턴 포인터를 통해 인가가 제공된 코드를 구비한 능력을 통해 액세스할 수 있게 하는) 객체에 의한 능력을 사용하는 것 또는 (예를 들어, 객체의 메모리 위치에 태깅하는) 객체에 의한 컬러를 사용하는 것을 포함할 수 있다.
요소(581b)는 실행 루틴의 현재 프레임에서 아이템을 판독하는 원하지 않은 런타임 거동을 식별한다. 이러한 거동을 방지하기 위해, 취한 조치는 객체 무결성을 유지하는 것일 수 있다. 이를 구현하는 메커니즘은 (예를 들어, 특수 태깅된 코드를 구비한 능력 또는 PC 태그를 통해 또는 액세스 인가에 의해 태깅된 특수 태깅된 리턴 포인터를 통해 인가가 제공된 코드를 구비한 능력을 통해 액세스할 수 있는) 객체에 의한 능력을 사용하는 것 또는 (예를 들어, 객체의 메모리 어드레스를 객체 특정 태그로 태깅하는) 객체 의한 컬러를 사용하는 것을 포함할 수 있다.
요소(581c)는 (예를 들어, 실행 코드를 호출한 다른 루틴의) 선행하는 프레임에서 의도하지 않은 아이템을 다시 기입하는 (현재 프레임을 갖는) 코드를 실행하는 원하지 않은 런타임 거동을 식별한다. 이러한 거동을 방지하기 위해, 취한 조치는 스택 프레임을 격리하거나 분리하는 것일 수 있다. 이를 구현하는 메커니즘은 (예를 들어, 특수 태깅된 코드를 구비한 능력 또는 PC 태그를 통해 또는 액세스 인가에 의해 태깅된 특수 태깅된 리턴 포인터를 통해 인가가 제공된 코드를 구비한 능력을 통해 액세스할 수 있는) 프레임에 의한 능력을 사용하는 것 또는 (예를 들어, 객체의 메모리 위치에 태깅하는) 프레임에 의한 컬러를 사용하는 것을 포함할 수 있다.
요소(581d)는 (예를 들어, 실행 코드를 호출한 다른 루틴의) 선행하는 프레임에서 아이템을 판독하는 (현재 프레임을 갖는) 코드를 실행하는 원하지 않은 런타임 거동을 식별한다. 이러한 거동을 방지하기 위해, 취한 조치는 스택 프레임을 격리하거나 분리하는 것일 수 있다. 이를 구현하는 메커니즘은 요소(581c)에서 설명한 것처럼 프레임별 능력 또는 프레임별 컬러를 사용하는 것을 포함할 수 있다.
요소(581e)는 현재 실행중인 코드에 의해 호출된 다른 루틴에 의해 스택의 남아있는 아이템을 판독하는 (현재 프레임을 갖는) 코드를 실행하는 원하지 않은 런타임 거동을 식별한다. 예방 조치는 호출된 루틴의 호출된 스택을 현재 실행중인 코드에 액세스할 수 없게 만드는 것이다. 이를 구현하는 메커니즘은 (572g)과 관련하여 설명한 것과 유사한 방식으로 별도의 프로세스, 별도의 스택, 능력 및 컬러화를 사용하는 것을 포함할 수 있다.
요소(581f)는 리턴 포인터(예를 들어, 실행 코드를 호출한 루틴 내의 리턴 어드레스를 포함하는 스택 내의 위치)를 수정하는 (현재 프레임을 갖는) 코드를 실행하는 원하지 않은 런타임 거동을 식별한다. 예방 조치는 리턴 포인터를 포함하여 스택 내의 리턴 포인터 또는 위치를 보호하는 것이다. 이를 구현하는 메커니즘은 (572g)와 관련하여 설명한 것과 유사한 방식으로 능력 및 컬러화를 사용하는 것을 포함할 수 있다.
본 명세서에서의 기술에 따른 실시예는 PUMP 규칙 메타데이터 처리 시스템을 다른 하이브리드 시스템의 일부로서 사용하여 새로운 규칙 세트를 학습하고 입증할 수 있다. 예를 들어, PUMP 규칙 메타데이터 처리 시스템은 허용된 제어 흐름을 (예를 들어, 로깅(logging)을 통해) 학습하고 이에 따라 실행 프로그램에 대한 규칙 및 허용된 유효한 제어 이전을 결정하는데 사용될 수 있다. 그런 다음 규칙 및 허용된 유효한 제어 이전은 실행된 프로그램을 위해 시행된 CFI 정책의 유효한 제어 이전의 규칙 및 그 세트로서 사용될 수 있다.
프로그램의 CFI 정책을 위한 학습 규칙 및 제어 이전을 추가로 설명하면, 제 1 훈련 또는 학습 단계가 수행될 수 있다. 이러한 제 1 단계에서, 프로그램은 태깅된 모든 제어 포인트(예를 들어, 소스 및 타깃의 분기 또는 이전) 및 제어 이전 명령어에 대한 규칙이 없는 CFI 정책의 훈련 버전을 이용하여 실행된다. 따라서 분기 또는 점프 명령어와 같은 제어 이전이 있을 때마다, 제어를 PUMP 규칙 메타데이터 시스템의 캐시 미스 핸들러에 이전시키게 하는 PUMP 규칙 캐시 미스가 존재한다. 캐시 미스 핸들러는 제어 이전에 관한 정보를 로그하는 처리를 수행할 수 있다. 로그된 정보는 예를 들어, 이전의 소스 위치 및 이전의 타깃 위치를 포함할 수 있다. 다른 정보는 또한 예를 들어, 이전이 이루어지는 (예를 들어, 소스 위치를 포함하는) 호출 절차 또는 루틴 및 제어가 이전되는 (예를 들어, 타깃 위치를 포함하는) 호출된 절차 또는 루틴을 포함할 수 있다. 보다 구체적으로, 학습 또는 훈련 단계에서, 특정한 제어 이전이 처음 발생하면, 캐시 미스 핸들러는 소스로부터 타깃으로 특정한 제어 이전을 위한 학습된 규칙 세트의 새로운 규칙을 계산한다. 동일한 소스로부터 동일한 타깃으로 제어의 후속 런타임 이전은 이렇게 계산된 규칙을 사용한다. 이러한 방식으로, 프로그램이 버그 없는 것으로 추정되고 프로그램이 실행되는 동안 (악의적 코드가 아닌) 비공격 프로그램 및 모든 제어 경로가 실행되면, 제어 이전들의 로그된 세트는 프로그램 실행의 종료에 설정된 학습된 규칙 세트에 의해 표시된 바와 같이, 이러한 특정 프로그램에 모든 유효한 또는 허용 가능한 제어 이전을 나타낸다. 따라서 학습된 규칙 세트는 프로그램에 대한 CFI 정책의 초기 또는 제 1 규칙 세트를 나타낼 수 있다.
프로그램에 대한 CFI 정책을 나타내는 학습된 규칙 세트를 입증하는 처리가 수행될 수 있다. 입증은 이러한 규칙 중 어느 것도 유효하지 않은 제어 이전을 허용하지 않도록 보장하는 것을 포함할 수 있다. 학습된 규칙 세트의 입증은 임의의 적절한 방식으로 수행될 수 있다. 예를 들어, 실시예는 각 규칙을 입증하는 분석 도구를 실행할 수 있다. 도구는 예를 들어, 이진 또는 객체 코드, 심볼 테이블 및 원본 소스 코드 등을 검사하여 각 규칙이 허용된 이전에 해당하는지를 입증한다. 추가로 설명하면, 입증은 모든 제어 포인트(예를 들어, 소스 및 타깃의 분기 또는 이전)가 가진 이진 코드가 태깅되어 있는지를 검사할 수 있다. 이러한 방식으로, 태깅된 이진 또는 소스 코드는 모든 잠재적인 소스 및 타깃 위치의 유효한 세트를 나타내며, 이에 따라 제어의 런타임 이전 시 실제로 사용될 수 있는 잠재적인 소스 및 타깃 세트를 제공한다. 로그된 제어의 임의의 런타임 이전은 소스 및 타깃 각각이 유효한 세트에 포함되어 있는 경우 소스로부터 타깃으로만 이루어져야 한다. 예를 들어, 태깅된 이진 또는 소스 코드는 위치 A1, A2, A3 및 A4를 포함할 수 있다. 제어의 임의의 로그된 이전은 A1, A2, A3 또는 A4의 소스 및 A1, A2, A3 또는 A4의 타깃을 포함하여야 한다. 제 1 규칙에 의해 표시되는 로그된 런타임 제어 이전이 A1로부터 B7까지이면, B7이 제어 이전의 타깃이 아니어야 하기 때문에 (예를 들어, B7은 A1, A2 A3 및 A4로 일관하여 태깅된 정적으로 결정된 가능한 제어 포인트들의 세트에 포함되지 않기 때문에) 제 1 규칙은 유효하지 않을 수 있다. 일 양태에서, 학습된 규칙 세트는 입증 처리의 결과로서 규칙 제거를 통해 더 감소될 수 있는 후보 규칙 세트로서 특징지을 수 있다.
입증된 프로그램에 대한 CFI 정책에 필요한 규칙의 초기 세트 또는 학습된 세트의 모든 규칙은 프로그램에 대해 시행되는 CFI 정책에 포함된 입증된 규칙 세트로서 사용될 수 있다.
도 54를 참조하면, 정책 규칙을 학습, 입증 및 사용하기 위한 본 명세서에서의 기술에 따른 실시예에 의해 수행될 수 있는 방금 설명된 처리를 요약하는 예가 도시된다. (602)에서, 프로그램은 초기에 어떠한 CFI 정책 규칙 없이 실행될 수 있으며, 그래서 각각의 새로운 제어의 이전이 규칙 캐시 미스를 야기하게 되고 캐시 미스 핸들러를 트리거하여 런타임시에 만나는 제어 이전에 관한 새로운 규칙을 생성하도록 한다. 새로운 규칙은 소스 및 타깃으로부터 제어 이전을 식별할 수 있고, 제 1 세트의 학습된 규칙(604)에 포함될 수 있다. 프로그램 실행의 종료시에, 제 1 세트의 학습된 규칙(604)은 런타임시 발생된 각각의 상이한 제어 이전에 대한 규칙을 포함한다. 그 다음 제 2 세트의 학습된 규칙은 각 규칙이 유효한 제어 이전을 나타내는 것을 보장하기 위해 (606)의 처리에서 입증될 수 있다. (606)의 처리는 자동화된 규칙 입증에 대해 전술한 바와 같은 도구를 사용할 수 있으며, 다른 처리를 또한 포함할 수도 있다. 예를 들어, (606)의 입증 처리는 제어 이전이 유효하다는 것을 추가 확인해 주기 위해 도구에 의해 입증되었던 규칙을 사용자에게 제시하는 것을 포함할 수 있다. 제 2 세트의 입증 규칙(608)은 규칙 입증 처리(606)의 결과로서 생성될 수 있다. 그 결과, 제 2 세트의 입증된 규칙(608)은 (610)에서 제 2 시점에서 프로그램을 실행할 때 시행되는 CFI 정책으로서 PUMP 시스템에 의해 사용될 수 있다.
따라서, 전술한 바와 같이, (602)에서 제 1 프로그램 실행은 프로그램에 대한 유효한 한 세트의 제어 이전을 결정하는데 사용될 수 있다. 그러나, 이러한 단일 프로그램 실행이 모든 제어 경로를 실행한다고 가정하는 것이 타당하지 않을 수 있으며, 따라서 (608)에서 식별된 제어 이전은 가능한 모든 유효한 제어 이전보다 적게 나타날 수 있다. 이 경우, 입증된 CFI 정책 규칙 세트를 사용하여 (610)과 관련하여 전술한 바와 같은 처리가 수행될 수 있다. 런타임 동안, (예를 들어, (608)에서 규칙을 갖지 않은 예기치 않은 제어 이전을 나타내는), 규칙 캐시 미스를 야기하는 제어 이전이 발생하면, 런타임시에 예를 들어, (예를 들어, 이진 코드에 태깅된 또는 소스 프로그램에 주석이 붙은 가능한 제어 포인트들의 세트를 사용하여) 전술한 바와 같은 제어 이전을 입증하는 추가적인 체크가 수행될 수 있다. 제어 이전이 유효하지 않은 것으로 결정되면, 결함 또는 예외가 트리거될 수 있다.
대안으로서, 제어 이전으로 인해 규칙 캐시 미스를 야기하고 그럼으로써 예기치 않은 런타임 제어 이전을 나타내게 되면, 캐시 미스 핸들러는 예기치 않은 이전 규칙을 나중의 검증을 위해 기록할 수 있고 또한 예기치 않은 제어 이전을 시행중인 추가 또는 상이한 정책으로 계속 이어지게 할 수 있다. 예를 들어, 제어 이전이 유효하지 않은 경우, 이전은 신뢰성 없는 것으로 간주될 수 있고, 그래서 정책은 유효하지 않은 제어 이전의 신뢰성 없는 특성으로 인해 더 높은 레벨의 보호를 반영하도록 수정될 수 있다. 예를 들어, 예기치 않은 이전은 제어를 라이브러리 루틴으로 이전할 수 있다. 라이브러리 루틴은 예기치 않은 이전 이전에 시행중인 것들보다 높은 레벨의 보호 및 더 적은 신뢰를 반영하는 정책을 사용하여 실행될 수 있다. 제어 이전이 입증된 경우, 제 1 스택 보호 정책은 예기치 않은 제어 이전에 앞선 제 1 시점에서 시행 중일 수 있고 제 2 스택 보호 정책은 예기치 않은 제어 이전의 이후에 시행될 수 있다. 제 1 스택 보호 정책은 정적 절차 인가를 시행할 수 있다. 제 1 보호 정책은 객체 보호 모델과 함께 본 명세서의 다른 곳에서 설명된 바와 같이 객체 레벨에서 어떠한 컬러화도 포함하지 않을 수 있다. 예기치 않은 제어 이전 이후, 시행중인 제 2 스택 보호 정책은 엄격한 객체 컬러화와 함께 본 명세서의 다른 곳에서 설명된 객체 보호 모델에 따라 스택 보호를 제공할 수 있다. 따라서 예기치 않은 제어 이전이 일어나면, 실행되는 코드는 더 엄격하고 미세한 레벨의 스택 보호의 세밀성을 제공하는 보다 제한적인 제 2 스택 보호 정책을 이용할 수 있다. 또한, 예기치 않은 제어 이전이 일단 발생하면 프로그램 실행은 우선 순위가 낮아진 채로 지속될 수 있다.
도 55 및 도 56을 참조하면, 위에서 설명된 프로그램에 대한 CFI 정책의 규칙과 같은, 유효한 규칙 세트를 사용하여 본 명세서에서의 기술에 따른 실시예에서 수행될 수 있는 처리 단계의 흐름도(620, 630)가 도시된다. 흐름도(620)는 실행 프로그램의 CFI 정책에서 규칙을 갖지 않은 예기치 않은 제어 이전과 관련하여 수행될 수 있는 제 1 세트의 처리 단계를 설명한다. 흐름도(631)는 실행 프로그램의 CFI 정책에서 규칙을 갖지 않은 예기치 않은 제어 이전과 관련하여 수행될 수 있는 제 2 세트의 처리 단계를 설명한다.
흐름도(620)를 참조하면, 단계(622)에서, 프로그램은 한 세트의 입증된 규칙을 사용하여 실행될 수 있다. 프로그램 실행 동안 단계(624)에서, 제어의 런타임 이전이 수행된다. 단계(626)에서, 이전이 예기치 못한 것을 나타내는 규칙 캐시 미스가 있는지가 결정된다. 특히, 제어의 런타임 이전에 대한 제 2 세트의 입증된 규칙에 규칙이 존재하면, 제어 이전이 예상되며, 이 경우 단계(626)는 아니오로 평가하고, 처리는 단계(628)로 이어지며 이 단계에서 제어 이전이 수행되고 프로그램은 계속 실행된다.
단계(626)가 예(예를 들어, 예기치 않은 제어 이전을 나타내는 캐시 미스)라고 평가하면, 처리는 예기치 않은 제어 이전에 대해 런타임 입증 처리가 수행되는 단계(632)로 이어진다. 특히, 미스 핸들러는 예기치 않은 이전을 입증하려고 시도하는 처리를 수행할 수 있다. 규칙 입증 처리의 예는 런타임 소스 및 타깃 위치가 태깅된 이진 코드, 원래의 소스 프로그램 및 심볼 테이블 등을 사용하여 결정될 수 있는 전술한 한 세트의 잠재적인 제어 이전 포인트들에 포함되어 있는지를 결정하는 것을 포함할 수 있다. 단계(634)에서, 단계(632)의 입증 처리는 예기치 않은 제어 이전이 유효한지를 결정한다. 단계(634)가 예라고 평가하면, 처리는 단계(636)로 이어지고 이 단계에서 새로운 규칙은 프로그램에 대한 CFI 정책으로서 사용되는 제 2 세트에 추가되고 프로그램의 처리는 계속된다. 단계(634)가 아니오로 평가하면, 프로그램 실행은, 예를 들어, 트랩을 유발함으로써 종료될 수 있다.
흐름도(631)를 참조하면, 단계(622, 624, 626 및 628)는 흐름도(620)와 관련하여 설명한 바와 같다. 단계(626)이 예라고 평가하면, 제어는 예기치 않은 제어 이전이 기록될 수 있는 단계(639)로 진행한다 (예를 들어, 예기치 않은 제어 이전의 후보 규칙이 기록된다). 단계(639)에서, 프로그램은 제어의 이전이 예기치 않은 때에도 실행을 계속될 수 있다. 그러나, 단계(639)에서, 프로그램 실행은 예를 들어, 위에서 언급한 바와 같이 하나 이상의 제한 정책 세트, 감소된 실행 우선 순위 등을 사용하여 계속된다.
전술한 바와 같이 위에서 설명된 처리는 테인트 추적과 같은 다른 정책과 관련하여 유사하게 수행될 수 있다. 예를 들어, 테인트 추적을 위해, 제 1 학습 또는 훈련 단계가 실행되어 캐시 미스 핸들러가 각각의 캐시 미스를 "로그"하게 함으로써 프로그램 실행을 통해 정책의 규칙을 학습할 수 있다. 본 명세서에서 설명된 바와 같이, 테인트 추적은 (예컨대, 본 명세서의 다른 곳에서 설명된 CI를 사용하여) 생성하거나 액세스하는 코드에 기초하여 데이터에 태깅하는 것을 포함할 수 있다. 코드 또는 소스에 기초하여 데이터를 테인트시키는 하나의 이유는 프로그램이 제대로 포함되어 있고 원하지 않거나 부적절한 데이터 액세스를 수행하지 않는 것을 확인하려는 것이다. 예를 들어, JPEG 디코더에 의해 오염된 데이터가 비밀번호 데이터베이스에 절대 유입되지 않도록 하거나 신용 카드 데이터, 사회 보장 번호 또는 기타 개인 정보가 특정 세트의 하나 이상의 제한된 애플리케이션들에 의해서만 액세스되도록 보장하는 규칙이 사용될 수 있다. 테인트 추적 정책을 결정할 때, 캐시 핸들러가 특정 데이터 흐름(예를 들어, 프로그램 루틴의 어떤 루틴이 어떤 데이터에 액세스하는지, 어떤 사용자 입력이 어떤 데이터베이스에 기입되는지 등)을 처음 보았을 때 캐시 핸들러 미스를 유발하고 규칙을 기록하는 테스트 데이터에 대해 테인트 추적 규칙을 실행하지 않고 학습 또는 훈련 단계를 위한 처리가 수행될 수 있다. CFI 정책에 대해 위에서 설명한 것과 유사한 방식으로, 제 1 학습 단계의 테스트 실행이 끝날 때, 동작 동안 프로그램을 보호하기 위해 적용되는 한 세트의 학습된 규칙이 있다. 학습된 규칙 세트의 입증 처리는 CFI 학습된 규칙 세트에 대해 위에서 언급한 도구 또는 다른 적합한 수단을 사용하여 수행될 수도 있다. 테인트 추적을 위한 그러한 입증 처리는 각각의 데이터 흐름 또는 액세스가 적절한지를 보장하는 것을 포함할 수 있다.
또한, 흐름도(620 및 631)와 관련하여 설명된 것과 유사한 방식으로, 입증된 규칙 세트는 캐시 미스 핸들러가 입증된 세트 내의 대응하는 규칙을 갖지 않는 임의의 데이터 액세스에 대한 처리를 다루는 PUMP 시스템과 함께 사용될 수 있다. 흐름도(620)의 처리와 유사하게, 그 다음에 캐시 미스 핸들러는 또한 데이터 액세스 또는 데이터 흐름에 대한 후보 규칙이 유효한지를 결정하는 런타임 입증 처리(예를 들면, 단계(632)와 유사함)를 수행하고 프로그램 실행이 계속되게(단계(634, 636)와 유사함) 하거나 계속되지 않게(예를 들어, 단계(638)와 유사함) 할 수 있다. 대안적으로, 흐름도(631)의 처리와 유사하게, 캐시 미스 핸들러는 (예를 들어, 런타임 동안이 아닌) 오프라인으로 입증될 수 있는 예상치 않은 데이터 액세스 또는 데이터 흐름에 대한 후보 규칙을 기록하고, 예를 들어 보다 제한적인 정책, 낮아진 우선 순위 등을 사용하여 프로그램 실행을 계속할 수 있다(예를 들어, 단계(639)와 유사함).
위의 예는 일반적으로 이진 학습 프로세스를 설명한다. 본 발명에서의 기술에 따른 실시예는 이벤트(예를 들어, 제어 이전 또는 데이터 액세스)를 허용할지에 관한 결정을 내릴 때 통계를 사용하는 것을 더 지원할 수 있다. 적어도 하나의 실시예에서, 카운터가 각 규칙에 추가되어 프로그램 실행 동안 각 규칙의 사용 횟수를 카운트할 수 있다. 규칙이 PUMP 캐시에서 퇴거될 때, 처리는 규칙 사용에 관한 추가 통계를 제공하는데 사용될 수 있는 글로벌 소프트웨어 계수(count)에 누적된 규칙 사용을 추가할 수 있다. 계수는 어떤 것을 제한된 횟수만큼 발생하게 하는데 사용될 수도 있다. 예를 들어, 소스로부터 타깃으로의 데이터 흐름을 추적하는 테인 트래킹 규칙과 관련하여, 소스와 타깃 간의 예기치 않은 데이터 흐름에 대해 제한된 문턱량의 데이터(예를 들어, 특정 프로그램에 의한 특정 데이터베이스로부터 판독된 X양의 데이터)가 허용될 수 있다. 일단 해당 문턱량이 일단 이전되면, 대응하는 후보 규칙이 성공적으로 입증될 때까지 소스와 타깃 사이에는 추가 데이터가 이전되지 않을 수 있다. 제한된 사용 사례가 문턱량을 가질 때, PUMP 시스템(예를 들어, 미스 핸들러)은 규칙이 없는 명령어가 약간 제한된 횟수로 발생할 수 있게 한다. 문턱값에 적용된 집계 또는 계수는 다른 방법으로 수행될 수 있다. 예를 들어, 예기치 않은 제어 이전을 고려해 본다. 집계되지 않았다면, 캐시 미스 핸들러는 규칙이 입증되지 않은 동일한 예기치 않은 제어 이전을 5 회 초과하여 발생할 수 없게 할 수 있다. 예컨대 프로그램에 대한 예기치 않은 모든 제어 이전 전체에 대해 집계되면, 프로그램은 최대 100회의 예기치 않은 제어 이전을 허용할 수 있다. 이것은 예를 들면, 예기치 않은 제어의 이전 또는 예기치 않은 데이터 액세스가 발생할 단일 인스턴스에 허용될 수 있는 사례에 대해 유용할 수 있다. 예를 들어, 특정 소스로부터의 데이터를 검사하는 단일 쿼리가 허용될 수 있다. 그러나, 데이터 소스(예를 들어, 특정 데이터베이스)에 대해 문턱 횟수 이상의 쿼리가 수행되면, 프로그램은 플래그(flaged)되거나 중지되어야 한다.
보다 일반적인 통계 사례는 정상적인 거동의 범위를 학습하는데 사용될 수 있다. 예를 들어, 정책의 상이한 규칙의 상대적 사용량(예를 들어, 각 규칙의 사용 비율)을 결정하기 위해 학습 단계에서 프로그램이 실행될 수 있다. 예를 들어, 런타임 제어 이전을 위해 호출된 각 규칙의 상대적 사용이 기록될 수 있다. 이상적으로, 그러한 실행은 많은 상이한 데이터 세트를 사용하는 프로그램에 대해 수행되어 평균적 또는 정상적 프로그램 거동으로 간주될 수 있는 것을 학습할 수 있다. 그런 다음 규칙 학습 및 입증은 (전술한 바와 같은) 입증된 제어 이전에 대한 규칙 세트 및 추가적으로는 각각의 입증된 규칙의 상대적 사용량을 나타내는 비율을 만들어 낼 수 있다. 입증된 규칙 및 연관된 사용 비율 둘 모두는 후속 처리 동안 시행된 정책 규칙으로 사용될 수 있다. 후속 프로그램 실행 동안 정책이 시행될 때, PUMP 시스템은 현재 규칙 사용량이 예상 비율과 일치하지 않은지를 체크할 수 있다. 실시예는 예를 들어, 규칙이 최대치를 초과하는 규칙을 호출하는 제어 이전이 플래그될 수 있는 규칙의 범위 또는 최대 예상된 사용을 포함할 수 있다. 예를 들어, 최대치를 초과하는 특정 제어 이전 규칙을 호출하는 프로그램은 추가 검사 또는 분석을 위해 플래그될 수 있다. 이러한 메커니즘을 사용하면, 네트워크 동작이 모니터링되는 방식과 유사하게 프로그램 런타임 거동이 모니터링되어 방화벽 규칙을 생성할 수 있다. 통계적 학습 알고리즘은 규칙 사용량 및 아마도 메인 메모리 트래픽 및 캐시 미스 레이트와 같은 다른 표준 런타임 특성을 포착하여 정상적인 사례 대 공격 거동을 학습하는데 사용될 수 있다. 전술한 바와 같은 제한적 사용 문턱치를 적용하는 실시예에서, 프로그램이 비정상적인 다른 런타임 거동을 보이거나 그렇지 않으면 신뢰성 없는 것으로 간주될 수 있다면, 사용 한도는 크게 감소되거나 그렇지 않으면 0으로 설정될 수 있다. 대안적으로, 프로그램이 정상적인 런타임 거동을 보이거나 그렇지 않으면 신뢰성 있는 것으로 간주될 수 있다면, 사용 한도는 신뢰성 없는 시나리오에 비해 훨씬 더 높게 설정되거나 증가될 수 있다.
위의 기술은 컴파일러가 임의의 추가 정보를 출력하지 않고, CFI 정책의 규칙에 반영된 유효한 제어 이전과 같은 정책의 유효한 규칙 세트를 결정하는데 사용될 수 있다. 따라서, 본 명세서에서의 기술에 따른 실시예는 각 정책의 두 개의 버전 - 하나는 학습 단계에 사용되고 다른 하나는 후속 시행에 사용됨 - 을 가질 수 있다. 학습 단계는 테인트 추적을 위한 허용 가능한 데이터 액세스 또는 흐름을 발견하고, CFI 정책에 대한 제어 이전을 발견하는 등의 자동 진단 모드로 사용될 수 있다.
이제 RISC-V 프로세서를 사용하는 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 아키텍처의 예가 설명될 것이다. 또한, 아래에서는 프로세서에 의해 사용되는 태깅되지 않은 데이터 소스와 태깅된 데이터 소스 사이에서 프로세서-기반의 중재된 데이터 이전(processor-based mediated data transfer)을 수행하는 것과 관련하여 사용될 수 있는 기술이 설명된다. 이러한 기술은 프로세서가 사용하기 위해 시스템에 가져올 수 있는 외부의 신뢰성 없는 데이터에 태깅하고 또한 태깅되지 않은 데이터를 만들기 위해 시스템 내에서 사용되는 태깅된 데이터로부터 태그를 제거하여 시스템의 외부에서 사용하기 위해 제공된다.
도 57을 참조하면, 태깅된 데이터와 태깅되지 않은 데이터를 중재하기 위한 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 컴포넌트의 예가 도시된다. 예(700)는 RISC-V CPU(702), PUMP(704), L1 데이터 캐시(706), L1 명령어 캐시(708), 태깅된 데이터 이전을 위해 시스템 내에서 내부적으로 사용되는 인터커넥트 패브릭(710), 부팅 ROM(712a), DRAM 제어기(ctrl)(712b) 및 태깅된 데이터를 저장하는 외부 DRAM(712c)을 포함한다. 또한, 하드웨어 컴포넌트인 부가 태그(714a) 및 밸리데이트 드롭 태그(validate drop tag)(714b), 프로세서(702)에 의해 사용하기 위해 태깅되지 않은 메모리(716)로부터 외부의 태깅되지 않은 데이터를 이전하고 태깅되지 않은 메모리(716)로 태깅되지 않은 데이터를 이전하기 위해 사용되는 인터커넥트 패브릭(715)이 포함된다. 태깅되지 않은 메모리(716) 이외의, 외부의 태깅되지 않은 데이터의 다른 소스(701)는 태깅되지 않은 패브릭(715)에 연결될 수 있다는 것을 유의하여야 한다. 예를 들어, 요소(701)는 플래시 메모리에 저장된 태깅되지 않은 데이터, 네트워크로부터 액세스 가능한 태깅되지 않은 데이터 등을 포함할 수 있다. DRAM 제어기(ctrl)(712b)는 DRAM(712c)으로부터 데이터를 판독하고 DRAM(712c)에 데이터를 기입하는데 사용되는 제어기이다. 부팅 ROM(712a)은 시스템을 부팅할 때 사용되는 부팅 코드를 포함할 수 있다.
예(700)는 별도의 태깅된 패브릭(710) 및 태깅되지 않은 패브릭을 도시하며, 이들 둘 사이에는 데이터를 이동하기 위한 프로세서(702)가 사용된다. 부가 태그(714a)는 입력으로서 태깅되지 않은 데이터를 받고 이 데이터가 (본 명세서에서 설명된 시스템 외부에서 사용될 수 있는) 공개적임을 표시하며 그리고 (소스가 알려지지 않을 수 있거나 그렇지 않으면 공지된 신뢰성 있는 소스로부터 온 것이 아니기 때문에) 신뢰성이 없음을 표시하는 태그로 데이터를 태깅한다. 적어도 하나의 실시예에서, 태깅되지 않은 메모리(716)의 태깅되지 않은 데이터는 (714a)에 의해 수신될 수 있다. (716)로부터 수신된 태깅되지 않은 데이터는 암호화될 수 있고 이에 따라 부가 태그(714a)는 수신된 암호화된 데이터에 신뢰성 없는 태그를 부가할 수 있다. 수신된 데이터는 공개-비밀 키 쌍을 사용하는 공개 키 암호화 또는 관련 기술분야에 공지된 다른 적합한 암호화 기술과 같은 비대칭 암호화를 사용하여 암호화될 수 있다. 수신된 데이터는 암호화된 형태로 저장될 수 있다. 관련 기술 분야에서 공지된 바와 같이, 소유자의 공개-개인 키 쌍에 있어서, 개인 키는 소유자에게만 공개되지만 공개 키는 공개되어 다른 사람들에 의해 사용된다. 제 3자는 소유자의 공개 키를 사용하여 소유자에게 보내는 정보를 암호화할 수 있다. 그러면 소유자는 (다른 사람과 공유하지 않는) 자신의 개인 키를 사용하여 수신된 암호화된 정보를 해독할 수 있다. 유사한 방식으로, 소유자는 자신의 개인 키를 사용하여 정보를 암호화할 수 있고, 암호화된 정보는 소유자의 공개 키를 사용하여 암호화된 정보를 해독하는 제 3 자에게 전송된다.
밸리데이트 드롭 태그(714b)는 태깅된 암호화된 데이터를 수신하여 태그를 제거함으로써 태깅되지 않은 메모리(716)로 내보내지는 태깅되지 않은 암호화된 데이터를 만들어 낼 수 있다. 메모리(716)에 저장된 이렇게 태깅되지 않은 암호화된 데이터는 예를 들어, 태그를 사용하지 않는 그리고 본 명세서에서 설명된 PUMP를 사용하여 수행하는 것으로서 연관된 메타데이터 규칙 처리를 사용하지 않는 다른 시스템 및 프로세서에서 사용될 수 있다.
적어도 하나의 실시예에서, (714a)에서 수신된 태깅되지 않은 데이터는 앞에서 언급한 바와 같이 암호화될 수 있고 또한 데이터의 무결성을 제공하도록 서명될 수 있다. 또한, 서명은 수신된 데이터 아이템을 입증하는데 사용되어 (예를 들어, 서명한 원래의 송신자가 송신한 이래로 수정되지 않았으며, 데이터가 그 데이터에 서명하는 송신자가 보냈던 것임을 보장하는) 인증 및 데이터 무결성을 보장할 수 있다. 예를 들어, 소유자는 해시 값 또는 "다이제스트(digest)"를 생성하기 위해 메시지를 해싱한 다음 다이제스트를 소유자의 개인 키로 암호화하여 디지털 서명을 생성할 수 있다. 소유자는 메시지 및 서명을 제 3 자에게 송신할 수 있다. 제 3자는 서명을 사용하여 수신된 데이터를 입증할 수 있다. 먼저, 제 3자는 소유자의 공개 키를 사용하여 메시지를 해독할 수 있다. 서명은 해독된 메시지의 해시 또는 다이제스트를 계산하고, 소유자의/서명자의 공개 키로 서명을 해독하여 예상된 다이제스트 또는 해시를 획득하고, 계산된 다이제스트를 해독된 예상된 다이제스트 또는 해시와 비교함으로써 검증될 수 있다. 매칭하는 다이제스트는 소유자가 서명했던 메시지가 수정되지 않았음을 확인한다.
동작시, 로드 명령어와 같은 명령어는 태깅되지 않은 메모리(716)에 저장된 데이터를 참조할 수 있으며, 이 데이터는 이후 명령어 실행에 사용하기 위해 데이터 캐시(706)로 전달된다. 이러한 로드 명령어에 대해, 데이터는 (716)로부터 (715)을 통해 (신뢰성 없는 것으로 및 공개적인 것으로 태깅된) 태깅된 데이터를 출력하는 (714a)에 의한 처리를 위해 전달될 수 있다. (714a)에 의해 출력된 태깅된 데이터는 처리를 위해 L1 데이터 캐시(706)에 저장된다. 유사한 방식으로, 스토어 명령어는 데이터 캐시(706)로부터의 데이터를 태깅되지 않은 메모리(716) 내의 위치에 저장할 수 있다. 이러한 스토어 명령어에 대해, 데이터는 (706)으로부터 (710)을 통해 태깅되지 않은 데이터를 출력하는 밸리데이트 드롭 태그(714b)로 전달될 수 있다.
코드는 프로세서(702) 상에서 실행되어 (716)으로부터 태깅되지 않은 데이터를 시스템으로 가져와서 예를 들어 DRAM(712c) 상에 저장할 수 있다. 태깅되지 않은 데이터를 가져오는 코드의 로직은 다음과 같이 나타낼 수 있다:
1. 부가 태그(714a)에 의해 출력된 태깅된 데이터는 신뢰성 없는 버퍼에 (공개적, 신뢰성 없는 것으로 태깅되어)에 저장될 수 있다.
2. 신뢰성 없는 버퍼에 저장된 태깅된 데이터를 해독하고 디코드 버퍼에 저장한다. 따라서 디코드 버퍼는 공개적, 신뢰성 없는 것으로 태깅된 해독된 데이터를 포함하고 있다.
3. 디코드 버퍼가 유효하고 훼손되지 않은 데이터를 포함함을 보장하는 입증 처리를 수행한다. 이러한 입증 처리는 본 명세서의 다른 곳에서 설명되고 관련 기술분야에 공지된 바와 같이 디지털 서명을 사용할 수 있다.
4. 디코드 버퍼가 입증 데이터를 포함하고 있으면, 신뢰성 있는 코드의 제 2 부분이 실행되어 공개적, 신뢰성 없는 것으로 태깅된 디코드 버퍼의 데이터를 신뢰성 있는 것으로 태깅된 데이터로 변환할 수 있다. 신뢰성 있는 코드 부분은 실행될 때, 디코드 버퍼의 데이터를 신뢰성 있는, 공개적인 것으로 다시 태깅하는 규칙을 호출하는 하나 이상의 명령어를 포함할 수 있다. 신뢰성 있는, 공개적인 것으로 지금 태깅되어진 다시 태깅된 데이터는 외부 DRAM(712c)에 위치한 신뢰성 있는 버퍼에 저장될 수 있다.
신뢰성 있는 코드는 실행될 때 참조된 메모리 위치를 다시 태깅하는 규칙을 호출할 수 있는 인가(authority)를 부여하는 특수한 명령어 태그로 태깅된 메모리 명령어를 포함할 수 있다. 예를 들어, 신뢰성 있는 코드는 (신뢰성 없는 버퍼에) 공개적, 신뢰성 없는 것으로 태깅된 데이터를 목적지 메모리 위치(신뢰성 있는 버퍼)에 공개적, 신뢰성 있음의 새로운 태그로 저장하는 특수 태그 스토어 명령어를 포함할 수 있다. 전술한 신뢰의 스토어 명령어는 예를 들어 로더에 의해 특수하게 태깅될 수 있다.
다음과 같이 데이터를 공개적, 신뢰성 없음으로부터 공개적, 신뢰성 있음으로 다시 태깅하는 신뢰 코드의 로직을 나타낼 수 있다.
여기서 N은 신뢰성 없는 버퍼의 길이이고 temp는 재태깅을 수행하는데 사용되는 임시 버퍼이다. 제 1 명령어인 temp = *untrusted buffer [i] 는 태깅되지 않은 메모리(716)로부터 신뢰성 없는 버퍼의 제 1 요소를 임시 버퍼에 로드하는 로드 명령어를 발생할 수 있다. 제2 명령어인 trusted buffer [i] = temp는 임시 버퍼에서 공개적, 신뢰성 없음으로부터 태깅된 데이터를 신뢰성 있는 버퍼 [i]에 공개적, 신뢰성 있음이라는 새로운 태그로 저장하는 스토어 명령어일 수 있다. 따라서, 제 2 명령어는 인가가 데이터를 신뢰성 없음으로부터 신뢰성 있음으로 다시 태깅하도록 하기 위해 위에서 언급한 바와 같이 특수 태깅된 명령어이다.
유사한 방식으로, (712c)의 태깅된 데이터가 태깅되지 않은 메모리(716)(또는 임의의 태깅되지 않은 메모리 소스(701))로 내보내지거나 저장될 때, 코드는 데이터 아이템을 암호화하여 서명을 생성하는 프로세서(702)에 의해 실행되며, 암호화된 데이터 아이템 및 서명은 (714b)로 발송될 수 있고, 이곳에서 태가 제거된 다음(715)를 통해 전송되어 (716)에 저장된다.
예(700)의 변형예로서, 메모리(716 및 712c)는 단일화될 수 있고 또한 인터커넥트 패브릭(710 및 715)도 단일화될 수 있다. 그러한 실시예에서, 태깅되지 않은 메모리 소스(701)가 액세스하도록 허용된 어드레스 범위는 제한될 수 있다. 예를 들어, 도 58의 예(720)가 참조된다. 예(720)는 (700)에서와 같은 번호를 가진 것들과 유사한 컴포넌트를 포함하며, 컴포넌트(714a 내지 714b, 715 및 716)가 제거되고 메모리(712c)가 신뢰성 없는, 공개적으로 태깅된 데이터를 저장하는데 사용되는 메모리(712c)의 영역을 나타내는 부분 U(722)을 포함한다는 차이점이 있다. 신뢰성 없는 DMA 및 I/O 서브시스템과 같은 태깅되지 않은 메모리 소스(701)는 메모리(722)의 하위 16 또는 256MB를 사용하는 것으로 제한될 수 있다. 일 실시예에서, U(722)에 저장된 데이터는 명시적으로 태깅될 수 없고, 오히려 이렇게 제한된 범위 내의 어드레스를 갖는 U에 저장된 모든 데이터가 공개적 및 신뢰성 없음으로 암시적으로 태깅되어 취급될 수 있다. 변형예로서, 실시예는 신뢰성 없는 공개적 데이터를 나타내는 영구 태그로 부분 U(722)에 미리 태깅할 수 있으며 전술한 연관된 영구 메타데이터 태그는 수정될 수 없다. 규칙은 프로세서가 다른 데이터를 영역 U(722)에 저장하는 것을 방지할 수 있다. 예를 들어, (701)에 포함된 DMA에 의해 수행되는 신뢰성 없는 DMA 동작은 영역 U(722)에 기입하는 것으로 제한될 수 있다.
언포트된(unported) I/O 처리 코드를 실행해야 하는 실시예는 컴포넌트의 신뢰성 없는 측의 전용 I/O 프로세서상에서 실행될 수 있다. 예를 들어, 도 59의 예(730)가 참조된다. 예(730)는 (700)에서와 같은 번호를 가진 것과 유사한 컴포넌트를 포함하며, 컴포넌트(732, 732a 및 732b)가 추가되는 차이점이 있다. 요소(732)는 PUMP 및 메타데이터 규칙 처리없이 실행되는 추가의 RISC-V 프로세서이다. 요소(732a)는 제 2 프로세서(732)에 대한 데이터 캐시를 나타내고 요소(732b)는 제 2 프로세서(732)에 대한 명령어 캐시를 나타낸다. 데이터 캐시(732)는 태깅되지 않은 인터커넥트 패브릭(715)에 연결될 수 있다.
본 명세서의 다른 곳에서 보다 상세하게 설명되는 바와 같이, 별도의 I/O PUMP가 태깅되지 않은 데이터 소스(예를 들어, 701, 716) 및 프로세서(702)에 의해 사용되는 태깅된 메모리(712c) 사이를 중재하는 또 다른 대안으로서 사용될 수 있다.
도 60을 참조하면, 태깅되지 않은 데이터 소스(예를 들어, 701, 716)와 프로세서(702)에 의해 사용되는 태깅된 메모리(712c) 사이를 중재하기 위해 본 명세서에서의 기술과 관련하여 사용되는 시스템에 포함될 수 있는 컴포넌트의 다른 실시예가 도시된다. 예(740)은 예(700)와 유사한 컴포넌트를 포함하며, 컴포넌트(714a 내지 714b)가 제거되고 인턴(intern)(742) 및 엑스턴(extern)(744)으로 대체된다는 차이점이 있다. 이 실시예에서, 인턴(742) 및 엑스턴(744)은 위에 설명된 처리를 수행하는 하드웨어 컴포넌트일 수 있다. 특히, 인턴(742)은 수신된 태깅되지 않은 데이터를 처리하고 신뢰성 있는, 공개적임으로 태깅된 입증된 데이터 아이템을 출력하는 하드웨어를 포함할 수 있다. 신뢰성 있는, 공개적임으로 태깅된 데이터 아이템은 명령어의 실행과 관련하여 프로세서(702)에 의해 사용되는 데이터 캐시(706)에 저장하기 위해 패브릭(710)에 전달될 수 있다. 인턴(742)은 태깅되지 않은 암호화된 데이터의 입증 처리를 수행하는 하드웨어를 포함할 수 있으며, 성공적인 입증을 가정하면, 수신된 태깅되지 않은 데이터를 신뢰성 있는, 공개적임으로 추가 태깅할 수 있다. 엑스턴(744)는 태깅된 암호화되지 않은 데이터를 처리하고 서명된 암호화된 데이터 아이템을 출력하는 하드웨어를 포함할 수 있다. 서명된 암호화된 데이터 아이템이 본 명세서에서 설명된 대로 메타데이터 규칙 처리를 수행하지 않는 다른 프로세서에서 사용될 것이라면 엑스턴은 암호화하기 전에 태그를 제거할 수 있다.
가장 간단한 사례에서, 인턴(742) 및 엑스턴(744)의 하드웨어는 단일의 공개-개인 키 세트를 호스팅할 수 있고, 서명 및 암호화 역시 단일 키 세트를 사용하여 수행된다. 키 세트는 (741 및 744)에 의해 사용된 하드웨어에서 인코딩될 수 있다. 또 다른 변형예에서, 인턴(742) 및 엑스턴(744)의 하드웨어는 다수의 공개-개인 키 세트를 호스팅할 수 있고, 서명 및 암호화는 또한 복수의 키 세트(각 세트는 다른 공개-개인 키 쌍을 포함함) 중 하나를 사용하여 수행된다. 다중 키 세트는 (742 및 744)에 의해 사용되는 하드웨어에서 인코딩될 수 있다. 입력되는 태깅되지 않은 데이터와 함께 포함된 클리어 데이터는 인턴 유닛(742)에게 어떤 키 세트를 사용할지를 알려준다. 따라서, 인턴(742)은 다수의 키 세트를 포함하는 하드웨어 데이터 스토어(예를 들어, 연상 메모리(associative memory))에서 룩업을 수행하여 원하는 키 세트를 선택할 수 있다. 다수의 키 세트 각각은 다른 태그와 연관될 수 있고, 그러므로, 클리어 데이터에 의해 표시된 특정 키 세트는 또한 태깅된 데이터가 포함할 특정 태그를 지시한다. 이러한 방식으로, (742)에 의해 출력된 태깅된 데이터 아이템의 태그는 데이터 아이템이 공개적임을 나타내고 또한 데이터 아이템이 다수의 키 세트 중 특정 키 세트를 사용하여 암호화/암호 해독된 것임을 나타낸다. 다수의 키 세트를 갖는 실시예에서, 엑스턴(744)은 태그를 검사하여 다중 키 세트 중 어느 특정 키가 데이터 아이템을 암호화하고 서명하는 것과 관련하여 사용되는지를 결정할 수 있다. 따라서, 인턴 유닛(742) 처리는 수신된 태깅되지 않은 데이터를 검증하고 태깅을 수행하는 격리된 하드웨어 컴포넌트를 제공함으로써, 위에서 언급한 신뢰 코드 부분과 같은 코드의 일부분이 데이터에 태깅하는 능력을 가질 필요가 없게 한다.
도 1 및 도 24를 다시 참조하면, 스테이지 5에서 PUMP(10)로의 입력은 본 명세서의 다른 부분에서 설명된 바와 같이 태그를 포함한다. 명령어가 명령어의 오퍼랜드로서 메모리 위치를 포함하는 경우, 메모리 입력 및 연관된 태그인 MR 태그(본 명세서에서 때로는 Mtag라고도 지칭함)를 획득하는 것은 여분의 파이프라인 지연(pipeline stall)을 유발하며, 이에 따라 스테이지 5에서 PUMP(10)는 MR 태그를 포함한 모든 입력을 가질 때까지 진행할 수 없다. 메모리로부터 판독된 실제 MR 태그 값을 검색하기를 기다리기보다, R 태그인 명령어의 결과에 대한 태그 값(예를 들어, 만일 있다면, 목적지 레지스터 또는 메모리 위치)을 결정하기 위해 사용될 수 있는 예상 또는 예측된 MR 태그를 결정하는 처리가 본 명세서에서의 기술에 따라 수행될 수 있다. 이러한 실시예에서, 최종 체크는 예측된 MR 태그가 명령어의 오퍼랜드에 대해 메모리로부터 검색된 액션 MR 태그와 매칭하는지를 결정하는 스테이지 6, 라이트백 또는 커밋 스테이지(예를 들어, 도 1의 요소(22) 및 도 24의 마지막 스테이지 6을 참고할 것)에서 수행될 수 있다. 오퍼랜드로서 메모리 위치를 갖는 명령어에 대한 Rtag를 결정하기 위해 예측된 MR 태그의 전술한 선택 및 사용은 Rtag 예측 가속기 최적화(prediction accelerator optimization)라고 지칭될 수 있다.
도 61을 참조하면, Rtag 예측 가속기 최적화에 대한 본 명세서에서의 기술에 따른 실시예의 컴포넌트를 설명하는 예(800)가 도시된다. 예(800)는 Rtag 예측 가속기 최적화를 수행하기 위한 부가적인 특징을 갖는 본 명세서의 다른 곳)(예를 들어, 도 1 및 도 24)에서 설명된 바와 같이 스테이지 5에서 PUMP(10)에 대응하는 PUMP(802를 포함한다. PUMP(802)는 본 명세서의 다른 곳에서 설명된 바와 같이 MR 태그(804a)뿐만 아니라 다른 PUMP 입력(804)을 입력으로서 포함한다. PUMP(802)는 또한 다른 입력, 즉 PUMP(802)가 정상 처리 모드(MR 태그 예측 처리가 수행되지 않는 비-예측 모드)에서 실행되는지 또는 그와 달리 (MR 태그 예측 처리가 수행되는) 예측 모드에서 실행되는지를 나타내는 예측 선택기 모드(804b)를 포함한다. 적어도 하나의 실시예에서, 예측 모드 선택기(804b)는 예측된 MR 태그 값이 결정되지 않는 PUMP에 대한 정상 처리 모드를 나타내는 0일 수도 있거나, 아니면 예측된 MR 태그 값이 결정되는 PUMP에 대한 예측 모드를 나타내는 1일 수도 있다. 예측 모드 선택기가 1일 때, PUMP(802)는 MR 태그(804a) 입력이 마스킹되거나 무시될 수 있는 예측 모드에서 실행할 수 있고, PUMP(802)는 예측된 MR 태그(805c)를 출력으로서 생성한다. 예측 모드 선택기가 0일 때, PUMP(802)는 본 명세서의 다른 곳에서 설명된 바와 같은 정상 처리 모드에서 실행할 수 있고, 이 모드에서 MR 태그(804a)는 PUMP(802)로의 입력이고 출력(805c)은 발생되지 않는다.
예(800)에 도시된 바와 같이, 스테이지 5에서 PUMP(802)의 추가 출력은 R tag(805a) 및 PC new tag(805b)를 포함한다. 예측된 MR 태그를 사용할 때, 예측된 MR 태그에 대한 규칙이 결정될 수 있고, 이 경우 규칙은 R 태그에 대해 연관된 태그를 지정한다. 예측 모드에서 동작할 때, 예측된 MR 태그(805c)는 파이프라인의 스테이지 6(808)로의 추가 입력이다. 요소(808)는 본 명세서의 다른 곳에서 설명된 바와 같이 커밋 또는 라이트백 스테이지(예컨대, 도 1 및 도 24)를 나타낼 수 있다. 따라서, 요소(808a)는 일반적으로 본 명세서의 다른 곳에서 설명된 바와 같이 (805a 내지 805c) 이외의 다른 스테이지 6 입력을 나타낼 수 있다.
스테이지 6(808)에서, 추가 처리(808b)는 PUMP(802)가 예측 모드에서 동작할 때 수행될 수 있다. 요소(808b)는 예측된 MR 태그를 명령어의 오퍼랜드에 대해 메모리로부터 획득된 액션 MR 태그와 비교하는 체크가 단계 6(808)에서 수행될 수 있음을 나타낸다. 달리 말하면, (808b)는 예측된 MR 태그가 메모리로부터 획득된 MR 태그와 매칭하는지를 결정함으로써 PUMP(802)가 MR 태그 값을 정확하게 예측했는지를 평가한다. 예측된 MR 태그가 메모리로부터 획득된 MR 태그와 매칭하지 않으면, 잘못된 규칙이 트리거되어 PUMP(802)에 의해 잘못 예측된 MR 태그로 R 태그(805a)를 결정하는데 사용된다. 올바른 규칙은 이제 (실제 MR 태그에 따라서) 선택되어야 하고 수정된 R 태그를 결정하는데 사용되어야 한다. 따라서, 예측된 MR 태그가 MR 태그와 매칭하지 않으면, 규칙 캐시 미스가 결정되고 캐시 미스 처리가 수행된다. 본 명세서의 다른 부분의 설명과 일관하여, 캐시 미스 처리는 MR 태그를 사용하여 올바른 규칙을 선택하고 평가하는 처리를 포함할 수 있다.
로드/판독 및 스토어/기입 명령어는 예측된 MR 태그의 사용으로부터 이익을 얻는 오퍼랜드로서 메모리 위치를 포함할 수 있는 실시예에서 명령어의 예이다. PUMP로의 다른 입력(804)은 MR 태그(804a) 외에 다른 또는 나머지 입력 태그의 세트를 포함한다. 예를 들어, 도 23과 관련하여 도시된 일 실시예는 5 입력 태그 - PC tag, CI tag, OP1 tag, OP2 tag 및 MR tag - 및 2 출력 태그 - PC new 및 R tag - 를 가질 수 있다. 따라서 (MR 태그를 제외한) 나머지 입력 태그 세트는 PC tag, CI tag, OP1 tag, OP2 tag의 4 태그를 포함한다. 예측된 MR 태그 또는 명령어를 결정하는 것은 명령어의 (예를 들어, PC tag, CI tag, OP1 tag, OP2 tag에 대한) 4 태그와 매칭하는 태그 값을 갖는 하나 이상의 규칙 세트를 결정하는 것을 포함할 수 있다. 경우에 따라, 하나의 규칙만이 4 입력 태그에 대해 매칭하는 태그 값을 포함할 수 있다. 이 경우, 단일 매칭 규칙은 예측된 MR 태그(805c)로서 사용될 수 있는 MR 태그에 값을 또한 특정한다. 또한, 규칙은 4 입력 태그 및 예측된 MR 태그를 사용하여 평가되어 R 태그(805a)를 추가로 결정할 수 있다.
예를 들어, 전형적인 로드 및 스토어 동작이 있는 메모리 안전 정책을 고려해 본다. 로드 동작은 포인터를 사용하여 소스 메모리 위치로부터 데이터를 로드할 수 있고, 제 1 규칙은 소스 메모리 위치상의 태그 또는 컬러가 포인터의 태그 또는 컬러와 매칭해야 함을 나타낸다. 스토어 동작은 포인터를 사용하여 타깃 메모리 위치에 데이터를 저장할 수 있고, 제 2 규칙은 타깃 메모리 위치상의 태그 또는 컬러가 포인터의 태그 또는 컬러와 매칭하여야 함을 나타낸다. 로드 명령어의 경우, 제 1 규칙은 로드 명령어의 PC tag, CI tag, OP1 tag 및 OP2 tag에 대한 4 입력 태그와 매칭하는 태그 값을 갖는 유일한 규칙일 수 있다. 제 1 규칙의 MR 태그는 예측된 MR 태그(805c)로서 사용될 수 있다. 또한, 제 1 규칙의 R 태그는 4 입력 태그 세트 및 예측된 MR 태그를 사용하여 결정될 수 있다. 유사한 방식으로, 스토어 명령어의 경우, 제 2 규칙은 스토어 명령어의 PC tag, CI tag, OP1 tag 및 OP2 tag에 대한 4 입력 태그와 매칭하는 태그 값을 갖는 유일한 규칙일 수 있다. 제 2 규칙의 MR 태그는 예측된 MR 태그(805c)로서 사용될 수 있다. 또한, 제 2 규칙의 R 태그는 4 입력 태그 세트 및 예측된 MR 태그를 사용하여 결정될 수 있다.
다른 사례에서, 명령어의 PC tag, CI tag, OP1 tag 및 OP2 tag에 대한 입력 태그와 매칭하는 태그를 갖는 정책의 규칙 세트는 예측된 MR 태그(805c)로서 사용될 수 있는 다른 허용 가능한 후보 또는 후보 MR 태그를 식별하는 각각의 매칭 규칙을 갖는 다수의 매칭 규칙을 포함할 수 있다. 실시예는 다수의 허용 가능한 MR 태그 중 하나를 예측된 MR 태그로서 사용하기 위해 선택하는 임의의 적절한 기술을 사용할 수 있다. 예를 들어, 실시예는 가장 일반적이거나 발생할 가능성이 있는 허용 가능한 MR 태그 세트 중의 MR 태그를 선택할 수 있다. 발생 가능성이 가장 높은 MR 태그는 이전의 관측 또는 규칙 프로파일링에 기초할 수 있다. 대안으로서, 실시예는 예측된 MR 태그를 이전 또는 가장 최근의 MR 태그로 설정할 수 있다. 최악의 경우, 예측된 MR 태그가 일단 수신된 실제 MR 태그와 매칭하지 않으면, 본 명세서에 설명된 바와 같이 캐시 미스 처리가 수행되어 실제 MR 태그를 명령어의 다른 입력 태그와 함께 사용하여 올바른 규칙을 결정할 수 있다.
적어도 하나의 실시예에서, PUMP가 예측 모드에서 동작할 때 사용되는 메모리 동작을 위한 규칙의 클래스가 생성될 수 있다. 규칙 클래스는 "메모리 태그 예측(predict memory tag)" 규칙의 클래스라고 지칭될 수 있다. "메모리 태그 예측" 규칙의 경우, MR 태그(804a)는 PUMP(802)로의 입력으로서 사용되지 않으며, 이에 따라서 PUMP에 의해 수행되는 다양한 룩업과 관련하여 사용되지 않는다. 예를 들어, "메모리 태그 예측" 규칙에 대한 care/don't care 비트 벡터는 MR 태그를 don't care로서 취급할 수 있다. 또한, "메모리 태그 예측" 규칙은 MR 태그를 입력으로 생략하고, 그 대신 예측된 MR 태그를 출력으로 지정할 수 있다. 전술한 바와 같이, PC tag, CI tag, OP1 tag 및 OP2 tag에 대한 입력 태그의 특정 세트와 매칭하는 다수의 매칭하는 정상 규칙이 있다면, 매칭하는 규칙의 세트에 대응하는 단일 "메모리 태그 예측" 규칙은 예측된 MR 태그를 가장 일반적이거나 예상되는 MR 태그인 출력으로 특정할 수 있다. 일 실시예에서, 매칭하는 규칙의 세트에 대응하는 단일 "메모리 태그 예측" 규칙은 예측된 MR 태그로서, PUMP(802)에 의해 수신된 마지막 또는 이전 MR 태그를 특정할 수 있다.
정책 로직은 "메모리 태그 예측" 규칙을 삽입할지 또는 사용할지를 결정할 수 있다. 실시예는 각 정책의 2 버전을 유지할 수 있는데, 제 1 버전은 예측 모드에서 동작할 때 사용하기 위한 정책 "메모리 태그 예측" 규칙을 포함하고 제 2 버전은 정상 처리 모드 또는 비-예측 모드에서 동작할 때 사용하기 위한 정상 또는 비-예측 정책 규칙을 포함한다. "메모리 태그 예측" 규칙을 사용할 때 주어진 명령어에 대해 스테이지 6의 (808b)에서 수행된 체크가 실패하면, 캐시 미스 처리는 정상 규칙 세트(예를 들어, 전술한 제 2 버전의 규칙)를 사용하여 명령어에 대한 매칭 규칙을 결정하는 처리를 수행할 수 있다.
RISC-V 프로세서 및 아키텍처를 사용하는 실시예에서, 예측 모드 선택기(804b)는 대응하는 PUMP CSR을 가질 수 있다. RISC-V 아키텍처를 사용하는 실시예에서 CSR의 사용은 본 명세서의 다른 부분에서 보다 상세하게 설명된다.
도 62를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 수행될 수 있는 처리 단계의 흐름도가 도시된다. 흐름도(840)는 예(800)와 관련하여 전술한 바와 같은 처리를 요약한다. 위에서 언급한 바와 같이, 예(800)에 도시된 PUMP(802)는 프로세서 파이프라인의 스테이지 6에 입력을 제공하는 스테이지 5에서의 PUMP를 나타낸다. 적어도 하나의 실시예에서, 흐름도(840)의 단계(842, 844, 846, 848 및 852)는 전술한 바와 같이 PUMP 내에서 구현된 스테이지 5에서 수행된 처리 단계 및 사용된 특정 정책 규칙을 나타낼 수 있고, 단계(854, 856 및 858)는 전술한 스테이지 6에서 수행될 수 있다.
단계(842)에서, PUMP가 "메모리 태그 예측" 규칙을 사용하는 예측 모드에서 동작하고 있음을 표시하는 예측 모드가 온/인에이블되어 있는지에 대해 결정이 내려진다. 단계(842)가 아니오라고 평가되면, 제어는 PUMP가 정상적인 규칙을 사용하는 정상 또는 비-예측 모드에서 동작하는 단계(846)로 진행한다. 단계(842)가 예라고 평가되면, 제어는 단계(844)로 진행하여, 현재 명령어가 메모리 입력 동작 명령어인지에 관해 결정이 이루어진다. 단계(842)가 아니오라고 평가되면, 제어는 단계(846)으로 진행한다. 단계(844)가 예라고 평가되면, 제어는 PUMP가 "예측된 메모리 태그" 규칙을 사용하는 예측 모드에서 동작하는 단계(848)로 진행한다. 단계(848)에서, 명령어에 대해 매칭하는 "예측된 메모리 태그" 규칙이 결정될 수 있다. 단계(852)에서, 현재 명령어에 대한 R 태그가 단계(848)로부터 매칭하는 "예측된 메모리 태그" 규칙을 사용하여 결정될 수 있다. 단계(854)에서, 예측된 MR 태그가 실제 MR 태그와 매칭하는지에 대해 결정이 이루어진다. 단계(854)가 아니로라고 평가되면, 제어는 단계(856)으로 진행하여 규칙 미스 핸들러를 호출함으로써 규칙 캐시 미스 처리를 수행한다. 단계(856)가 예라고 평가되면, 제어는 단계(858)로 진행하여 예측된 MR 태그를 포함하는 규칙이 있는 것으로 결정될 때, R 태그가 R 태그 PUMP 출력으로서 사용된다.
예(800)의 변형예로서, 정상적인 비-예측 모드에서 실행되는 PUMP(802) 및 예측 모드에서 실행되는 제 2 PUMP(822)를 포함하는 실시예의 컴포넌트를 도시하는 도 63이 참조된다. 이 예에서, 예측 모드에서 동작하는 PUMP(822)는 또한 예측 모드 선택기(822b)가 항상 ON(예를 들어, 1)인 MR 태그 예측 PUMP라고도 지칭될 수 있다. 유사하게, PUMP(802)의 경우, 예측 모드 선택기(804b)는 또한 OFF(예를 들어, 0)일 수 있다. MR 태그 예측 PUMP(822)는 "메모리 태그 예측" 규칙만을 사용할 수 있고 PUMP(802)는 정상 버전 또는 비-예측 버전의 정책 규칙만을 사용할 수 있다. 이러한 실시예에서, PUMP(802 및 822)는 스테이지 5에서 병렬로 동작할 수 있다. 요소(828)는 스테이지 5 및 6 처리 및 MR 태그 예측 PUMP(822)와 연관된 컴포넌트를 나타낼 수 있다. 요소(829)는 스테이지 5 및 6의 처리 및 정상 모드에서 동작하는 PUMP(802)와 연관된 컴포넌트를 나타낼 수 있다. (829)에서, PUMP(802) 출력은 예(800)와 관련한 바와 같고, 예측된 MR 태그(805c)가 더 이상 PUMP(802)에 의해 출력되지 않는다는 차이가 있다. 또한, 스테이지 6(808)은 체크(808b)를 수행하지 않는다. 요소(828)는 예(800)와 유사한 방식으로 처리를 수행하는 컴포넌트를 포함할 수 있고, MR 태그 예측 PUMP(822)가 위에서 언급한 바와 같이 "메모리 태그 예측" 규칙만을 사용한다는 차이가 있다.
스테이지 6(808)은 MR 태그 예측 PUMP(822)로부터 PUMP 출력 Rtag(805a) 및 PCnewtag(805b)를 받고 PUMP(802)로부터 Rtag(805d) 및 PCnew tag(805e)를 출력하도록 수정된다. 또한, 스테이지 6에서, Rtag(805a 및 805d) 사이에서 선택이 이루어지고 또한 ((808a)로 나타낸 바와 같이) 예측된 MR 태그가 실제 MR 태그와 매칭하는지에 기초하여 PCnew tag(805c 및 805e) 사이에서 선택이 이루어진다. 예측된 MRtag와 실제 MRtag 사이에서 매칭이 있으면(예를 들어, (808a)가 1 또는 참(true)으로 평가되면), 예측된 PUMP(822)로부터의 태그(예를 들어, Rtag(805a 및 PCnew tag(805b))가 사용되고, 예측되지 않은 PUMP(822)로부터의 태그(예를 들어, Rtag(805d) 및 PCnew tag(805e))는 폐기된다. 예측된 MRtag와 실제 MRtag가 매칭하지 않으면(예를 들어, (808a)가 0 또는 거짓(false)으로 평가되면), 예측된 PUMP(822)로부터의 태그(805a 내지 805c)는 폐기되고, 예측되지 않은 PUMP(802)로부터의 태그(805d 내지 805e)는 사용된다. 예측되지 않은 PUMP(802)는 예측된 PUMP(822)의 출력(805a 내지 805c)보다 늦은 그의 출력(805d 내지 805e)을 제공하며, 그래서 PCnewtag 및 MRtag에 관한 스테이지 5로부터의 PUMP 출력이 스테이지 6로의 입력으로서 처리하는데 필요할 때는 전술한 스테이지 6 입력을 대기하는 스테이지 6에 정지가 도입된다. 예측되지 않은 PUMP(802)는 이것이 선택될 때 PUMP 규칙 캐시 미스를 경험할 수도 있는데, 이 경우, 이는 본 개시내용의 다른 곳에서 설명된 바와 같은 전형적인 규칙 캐시 미스처럼 처리된다.
스테이지 6(808)을 참조하면, 요소(850 및 852)는 멀티플렉서를 나타낸다. 요소(808a)는 예측된 MRtag가 MRtag와 매칭하는지의 논리적 결과에 기초하여 (850 및 852) 각각으로부터의 입력을 선택하는데 사용되는 선택기를 나타낼 수 있다. 전술한 두 개의 태그 값이 매칭하면, Rtag(805a)는 스테이지 6의 최종 Rtag 출력을 나타내는 선택된 Rtag(850a)로서 제공되는 (850)으로의 입력으로서 선택되고; 그렇지 않고, 전술한 두 개의 태그 값이 매칭하지 않으면, Rtag(805d)는 선택된 Rtag(850a)로서 제공된 (850)으로의 입력으로서 선택된다. 또한, 전술한 두 개의 태그 값이 매칭하면, PCnew tag(805b)는 스테이지 6의 최종 PCnew tag 출력을 나타내는 선택된 PCnew tag(852a)로서 제공된 (852)로의 입력으로서 선택되고; 그렇지 않고, 전술한 두 개의 태그 값이 매칭하지 않으면, PCnew tag(805e)는 선택된 PCnew tag(852a)로서 제공되는 (852)로의 입력으로서 선택된다.
이제 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 할당된 메모리의 컬러화(coloring allocated memory)를 사용하는 기술이 설명될 것이다.
사용자 프로그램, 예컨대 C 프로그래밍 언어로 코딩된 사용자 프로그램에는 메모리 할당(memory allocation) 및 할당 취소(deallocation)와 관련하여 사용되는 루틴을 부르는 호출이 포함될 수 있다. 예를 들어, malloc 및 free는 C 표준 라이브러리에서의 루틴이며 사용자 프로그램의 실행 파일에 링크될 수 있다. 따라서 malloc 및 free는 malloc과 free를 호출할 수 있는 다른 사용자 코드와 함께 사용자 프로세스 어드레스 공간에서 루틴으로 실행된다. malloc은 코드를 실행함으로써 사용되는 메모리 블록을 할당하는 동적 메모리 할당을 위해 호출된다. 적어도 하나의 실시예에서, malloc은 할당될 메모리 블록의 크기를 나타내는 호출에 특정된 입력을 가질 수 있으며, 이에 따라 malloc은 할당된 메모리 블록을 가리키는 포인터를 리턴한다. 프로그램은 malloc에 의해 리턴된 포인터를 사용하여 할당된 메모리 블록에 액세스한다. 적어도 하나의 실시예에서, free는 malloc이 이전에 할당한 메모리를 프리로 만들어주거나 할당 해제하기 위해 호출된다. malloc을 사용하여 할당된 메모리 블록이 더 이상 필요하지 않을 때, (malloc에 의해 리턴된) 포인터는 입력 인수로서 free에 넘겨질 수 있고, 그러므로 free는 (포인터에 의해 표시된 어드레스로서 위치된) 메모리를 할당 해제하여 다른 목적에 사용될 수 있도록 한다. 본 명세서에서의 기술에 따른 실시예에서 프로세서상에서 실행하는 사용자 코드는 메모리 할당 및 할당 해제를 유사하게 수행하는 malloc 및 free 또는 다른 루틴 또는 함수를 부르는 그러한 호출을 수행할 수 있다. 동적 메모리 할당을 수행하는 malloc 및 free와 같은 루틴은 할당된 메모리에 관한 메모리 관리 메타데이터를 사용할 수 있다. 다음 단락에서, 메모리 관리를 위해 사용되는 그러한 메타데이터는 malloc 메타데이터라고 지칭될 수 있으며, 구별되고 게다가 태그 및 포인터 태그가 가리키는 다른 메타데이터를 비롯한 본 명세서에서 설명된 태그 기반 메타데이터이다(예를 들어, 태그 기반 메타데이터는 실행중인 사용자 코드에 액세스할 수 없으며, 예(1000)와 관련하여 본 명세서의 다른 곳에서 설명된 것과 같은 메타데이터 프로세서 또는 서브시스템에 의해 처리된다). malloc 메타데이터는 예를 들어, 할당된 메모리 블록의 크기와 같은 할당된 메모리 블록에 관한 정보 및 후속하여 할당된 메모리 블록에 대한 malloc 메타데이터 부분을 가리키는 포인터를 포함할 수 있다.
도 64를 참조하면, 예컨대 malloc과 관련하여 메모리 할당을 도시하는 예가 도시된다. 예(1100)에서, 프로그램은 요청된 크기의 메모리의 제 1 블록을 할당하기 위해 malloc을 부르는 제1 호출을 수행한다. 이에 응답하여, malloc은 요청된 크기의 메모리 블록(1102b)을 할당하고 메모리 블록(1102b)에 대한 시작 어드레스를 나타내는 포인터 P1을 리턴할 수 있다. 그 다음, 사용자 프로그램은 포인터(P1) 또는 P1으로부터의 오프셋에 기초한 다른 어드레스를 사용하여 할당된 메모리 블록(1102b)에 데이터를 저장하고 그로부터 데이터를 판독할 수 있다. 또한 동적 메모리 관리를 위해, malloc은 할당된 각 메모리 블록에 대한 자체의 malloc 메타데이터의 스토어(1102a)를 할당할 수도 있다. 요소(1102a)는 할당된 메모리 블록(1102b)에 대한 malloc 메타데이터를 저장하기 위해 malloc에 의해 할당되고 사용되는 메모리 부분을 나타낸다. 유사한 방식으로, 사용자 프로그램은 이어서 malloc을 부르는 제 2 호출을 수행하여 제 2 메모리 블록을 할당할 수 있다. 요소(1104a)는 이러한 제 2 호출에 응답하여 malloc에 의해 할당된 메모리 부분을 나타내며, (1104a)는 malloc 메타데이터를 저장하기 위해 사용된다. 요소(1104b)는 제 2 메모리 블록을 나타내며, 여기서 P2는 제 2 메모리 블록에 액세스하기 위해 사용자 프로그램에 리턴된 포인터이다. 유사한 방식으로, 사용자 프로그램은 이어서 malloc을 부르는 제 3 호출을 수행하여 제 3 메모리 블록을 할당할 수 있다. 요소(1106a)는 이러한 제 3 호출에 응답하여 malloc에 의해 할당된 메모리 부분을 나타내며, (1106a)는 malloc 메타데이터를 저장하기 위해 사용된다. 요소(1106b)는 할당된 제 3 메모리 블록을 나타내며, 여기서 P2는 제 3 메모리 블록을 액세스하기 위해 사용자 프로그램에 리턴된 포인터이다.
(1102b)와 같은 할당된 메모리 블록(1102b)이 실행중인 코드에 의해 더 이상 필요하지 않게 된 이후, 코드는 메모리 블록(1102b)을 프리로 만들어 주기 위해 call to free을 수행하여 그러한 메모리 블록(1102b)이 할당 해제되고 다른 목적으로 사용될 수 있도록 한다. 이러한 call to free을 할 때, 포인터(P1)가 리턴될 수 있다. 유사한 방식으로, 메모리 블록(1104b 내지 1104c)이 더 이상 필요하지 않을 때, call to free는 각각 포인터(P2 및 P3)를 특정하도록 만들어질 수 있다.
malloc 메타데이터를 보유하는 메모리 부분(1102a)의 어드레스가 실행중인 코드의 어드레스 공간에 매핑되기 때문에, malloc에 의해 실행중인 사용자 코드에 리턴된 P1과 같은 포인터를 통해, 사용자 코드는 실수로 또는 의도적으로 malloc 메타데이터에 액세스할 수 있다. 예를 들어, 사용자 코드는 다른 포인터 P4에 메모리 부분(1102a)의 어드레스를 할당(예를 들어, P4 = P1-2)한 다음 포인터 P4에 의해 식별된 메모리 위치를 판독하거나 그 메모리 위치에 기입할 수 있다. 따라서, 사용자 코드는 예를 들어, (1102a)에 저장된 malloc 메타데이터를 오버라이트하고 (1102a)에 저장된 malloc 메타데이터를 판독할 수 있다. 이러한 방식으로, P4에 의해 식별된 어드레스의 메모리 위치에 기입을 수행하는 것은 malloc 메타데이터 부분(1102a)을 훼손시킬 수 있다. 보다 일반적으로, 전술한 것은 malloc 메타데이터 부분(1102a, 1104a 및 1106a) 중 임의의 부분과 관련하여 사용자 코드에 의해 수행될 수 있다.
call to free와 관련하여, 사용자 코드는 malloc을 사용하여 이전에 할당한 할당된 메모리 블록의 시작 어드레스에 대응하는 포인터를 지정할 수 있다. 예를 들어, 사용자 코드는 P1, P2 또는 P3가 아닌 인수로서 전술한 포인터 P4를 지정하는 call to free을 수행할 수 있다. 예를 들어, malloc이 call to malloc과 관련하여 각 malloc 메타데이터 부분(1102a 내지 1102c)에 대해 X 바이트 블록(예를 들어, X는 0이 아닌 정수)을 할당한다고 가정한다. 루틴 free는 제 1 어드레스(P4-X)로부터 제 2 어드레스(P4-1)까지의 메모리 위치가 각각 (1102a)와 같은 malloc 메타데이터 부분에 걸친 시작 및 종료 어드레스를 나타내는 것으로 가정하여 처리를 수행할 수 있다. 이 경우, free에 의해 수행되는 처리는 예를 들어 예기치 않은 런타임 성능 및/또는 동적 메모리 관리 에러를 초래하는 훼손된 malloc 메타데이터 부분(1102a)을 사용하는 것일 수 있다.
실시예는 malloc 메타데이터 부분(1102a, 1104a 및 1106a)을 보호하는 본 명세서에 설명된 기술을 사용하여 사용자 코드와 같은 다른 실행중인 코드에 의해 수행되는 오버라이트를 통한 훼손을 회피할 수 있다. 이러한 기술은 코드 및/또는 데이터를 특정 컬러 또는 태그로 태깅하고 본 명세서의 다른 곳에서 설명된 바와 같이 원하는 액세스 및 동작만을 허용하는 규칙을 시행할 수 있다.
도 65를 참조하면, 적어도 하나의 실시예에서, malloc 및 free에 의해 사용되는 메모리 부분은 본 명세서에서 설명된 바와 같이 메타데이터 처리에 의해 사용되는 제 1 태그로 컬러화되거나 태깅될 수 있고, (malloc에 의해 할당된 바와 같이) 사용자 코드에 의해 사용되는 다른 메모리 부분은 본 명세서에서 설명된 바와 같이 메타데이터 처리에 사용되는 상이한 제 2 태그로 컬러화되거나 태깅될 수 있다. 예(1100)에서 (malloc 메타데이터를 포함하는) malloc 및 free 에 의해 사용되는 데이터 부분은 적색으로 표시되거나 태깅될 수 있고, 사용자 데이터 부분(사용자 코드에서 사용하기 위해 malloc에 의해 할당된 메모리 블록)은 파란색으로 표시되거나 태깅될 수 있다. 실시예는 malloc 및 free에 의해 사용되는 메모리 위치를 컬러화 또는 태깅할 때 사용하기 위해 독점적으로 예약된 적어도 하나의 태그 또는 컬러를 가질 수 있다. 이러한 예에서, 적색은 malloc 및 free에 의해 사용되는 메모리 위치에 태깅하는데 사용되는 예약된 컬러이다. 본 명세서의 다른 곳에서 설명된 바와 같이, 실시예는 또한 실행중인 사용자 코드에 대해 하나 이상의 컬러 또는 태그를 예약할 수 있다. 적어도 하나의 실시예에서, 사용자 프로그램에 의해 사용하기 위해 할당된 모든 메모리는 동일한 컬러로 태깅될 수 있다. 변형예로서, 실시예는 각각의 call to malloc에 대해 상이한 태그를 사용할 수 있고, 이에 따라 할당된 각각의 별도의 메모리 블록에 대해 상이한 컬러를 사용할 수 있다. 이러한 예(1110)에서, 설명을 단순화하기 위해, 단일 컬러 청색만이 사용자 프로그램을 위해 malloc에 의해 할당된 모든 메모리 블록을 태깅하는데 사용된다.
요소(1111)는 대응하는 메모리 위치(1113)에 대해 특정된 태그를 나타낼 수 있다. 요소(1112a, 1114a 및 1116a)는 각각 malloc 메타데이터 부분(1102a, 1104a 및 1106a)에 대한 태그를 나타낸다. 요소(1112b, 1114b 및 1116b)는 각각 위에서 설명한 바와 같이 malloc에 대해 이루어진 호출을 통해 사용자 코드에 의해 사용하기 위해 malloc 에 의해 할당된 메모리 블록(1102b, 1104b 및 1106b)에 대한 태그를 나타낸다.
요소(1112a, 1114a 및 1116a)는 각각 (1102a, 1104a 및 1106a)에 있는 각각의 메모리 위치가 적색으로 태깅된 것임을 표시한다. 요소(1112b, 1114b 및 1116b)는 각각 (1102b, 1104b 및 1106b)의 각각의 메모리 위치가 청색으로 태깅된 것임을 표시한다.
일반적으로, 실시예는 (1111)으로 나타낸 태그를 갖는 (1113)의 메모리 블록을 컬러화하고, 또한 메모리 안전 정책을 시행하는 규칙을 트리거하는 것과 관련하여 명령어 태깅, 컬러화된 포인터 또는 전술한 것들의 조합을 사용할 수 있고, 이에 따라 malloc 및 free 만이 malloc 메타데이터 영역(1102a, 1104a 및 1106a)에 액세스할 수 있고 사용자 코드는 액세스할 수 없다.
제 1 실시예에서, malloc 및 free의 코드는 예컨대 로더에 의해 특수한 명령어 태그(예를 들어, CI 태그)로 태깅(예를 들어, 명령어 태깅)될 수 있다. malloc 및 free 둘 모두는 동일한 고유하거나 특수한 명령어 태그로 태깅될 수 있거나(예를 들어, malloc 및 free는 tmem이라는 동일한 CI 태그로 태깅됨), 자체의 고유하거나 특수한 명령어 태그로 태깅될 수 있다(예를 들어, malloc 코드는 tmalloc으로 태깅되고 free 코드는 tfree 태그로 태깅됨). malloc의 코드는, 실행될 때, 예(110)에서와 같이 컬러화를 수행하는 규칙을 트리거하는 스토어 명령어를 포함할 수 있다. free의 코드는, 실행될 때, 예컨대 블록 또는 malloc 메타데이터 부분의 각 메모리 셀을 프리 메모리임을 나타내는 F 태그로 다시 태깅함으로써 malloc 메타데이터 부분(예를 들어, 1102a, 1104a 및 1106a) 또는 이전에 malloced 메모리 블록(예를 들어, 1102b, 1104b 및 1106b)을 다시 초기화하거나 할당 해제하는 규칙을 트리거하는 스토어 명령어를 포함할 수 있다. 또한, 제 1 실시예에서, 메모리 안전 정책은 로드 및 스토어 명령어와 같은 특정 명령어의 실행에 의해 트리거되는 규칙을 포함할 수 있으며, 이에 따라 규칙은 위에서 언급한 특수 명령어 태그(들)로 태깅된 명령어가 오로지 1) malloc 메타데이터 부분(1102a, 1104a 및 1106a)에 액세스할 수 있게 하며 그리고 2) 예(110)에서와 같이 메모리 블록 컬러화를 수행할 수 있게 한다. 이러한 규칙은 일반적으로 CI 태그를 체크하여 (1102a, 1104a 및 1106a) 중 임의의 메타데이터 부분의 메모리 셀을 컬러화하거나 그 메모리 셀에 액세스하는 각각의 명령어가 malloc 또는 free를 나타내는 특수 명령어 태그를 갖는 것을 보장한다.
제 2 실시예에서, 특수 명령어 태그를 사용하기보다, 실시예는 로드 및 스토어 명령어와 같은 특정 명령어의 실행에 의해 트리거되는 메모리 안전 정책의 규칙을 갖는 컬러화된 포인터를 사용할 수 있다. 로더는 적색으로 컬러화된 malloc 메타데이터 부분(1102a, 1104a 및 1106a)을 참조하는 malloc 및 free의 포인터에 태깅할 수 있다. malloc의 코드는, 실행될 때, 예(110)에서와 같이 컬러화를 수행하는 규칙을 트리거하는 스토어 명령어를 포함할 수 있다. free의 코드는 실행될 때, 예컨대 메모리 셀을 프리 메모리임을 나타내는 태그 F로 다시 태깅함으로써 malloc 메타데이터 부분(예를 들어, 1102a, 1104a 및 1106a) 또는 이전에 할당된 메모리 블록(예를 들어, 1102b, 1104b 및 1106b)을 다시 초기화하거나 할당 해제하는 규칙을 트리거하는 스토어 명령어를 포함할 수 있다. 메모리 안전 정책은 로드 및 스토어 명령어와 같은 특정 명령어의 실행에 의해 트리거되는 규칙을 포함할 수 있으며, 이에 따라 규칙은 적색으로 컬러화된 포인터를 사용하는 메모리 셀을 참조하는 명령어로 malloc 메타데이터 부분(1102a, 1104a 및 1106a)에 액세스하는 것만을 허용한다. 이러한 규칙은 일반적으로 MR 태그를 체크하여 (1102a, 1104a 및 1106a) 중 임의의 메타데이터 부분의 메모리 셀에 액세스하는 메모리 명령어가 메모리 셀의 제 2 컬러와 매칭하는 제 1 컬러를 갖는 포인터를 사용하는 것을 보장한다.
제 3 실시예에서, 위에서 설명된 바와 같이 특수 명령어 태그 및 컬러화된 포인터 둘 모두는 조합되어 이용될 수 있다. 다음은 그러한 제 3 실시예에서 사용될 수 있는 명령어 및 규칙의 예이다. 본 명세서에서의 다른 논의와 일관하여, 다음의 예는 목적지 레지스터 또는 현재 명령어의 결과가 저장되는 메모리 위치에 태깅하는데 사용되는, PC(프로그램 카운터), CI(현재 명령어), OP1(현재 명령어의 오퍼랜드 1), OP2(현재 명령어의 오퍼랜드 2), MR(만일 있다면, 현재 명령어에서 참조되는 메모리 위치)에 대해 메타데이터 처리를 위한 5 입력 태그 및 PCnew(다음 명령어의 다음 PC에 대한 새로운 PC 태그) 및 R(현재 명령어의 결과에 대한 태그) 명령어에 대해 두 개의 전파되거나 발생된 태그에 기초한 규칙을 사용한다. 또한 "-"는 태그에 대해 don't care임을 나타낸다. 이러한 실시예에서, 로더는 malloc의 명령어를 특수 태그 tmalloc으로 태깅할 수 있고 free의 명령어를 특수 태그 tfiree로 태깅할 수 있다. 아래에서 언급되는 트리거된 규칙을 사용하여 컬러화된 포인터가 생성될 수 있다.
malloc과 관련하여, malloc의 코드 부분을 실행함으로써 트리거되는 메타데이터 규칙 처리는 malloc의 코드 부분의 스토어 명령어의 결과로서 호출된 제 1 규칙을 통해 (1102b)와 같은 새로 할당된 메모리 블록을 가리키는 포인터에 대한 태그를 생성할 수 있다. 예를 들어, malloc C 코드는 "P1 = next free"일 수 있고, 여기서 next free는 (1113)에서 다음의 프리 메모리 위치를 가리키는 포인터이며, 스토어 명령어는 "move R1, R2"일 수 있고, 여기서 레지스터 R1은 next free의 어드레스를 포함하는 소스 레지스터이며, 레지스터 R2는 포인터 P1 인 목적지 레지스터이다. 레지스터 R1은 (OP1 태그를 가진) OP1일 수 있고, 레지스터 R2는 (발동된 규칙(fired rule)의 결과로서 전파되거나 생성된 R 태그를 갖는) 결과 또는 목적지 레지스터일 수 있다. malloc의 코드 부분은 역시 특수 태그인 tmalloc으로 태깅된 명령어로서, 명령어가 malloc 코드에 포함되어 있음을 나타내는, 예컨대 전술한 move 명령어와 같은 명령어를 포함할 수 있다. 적어도 하나의 실시예에서, 로더는 malloc의 명령어를 특수 코드 태그인 tmalloc으로 태깅할 수 있다. 제 1 규칙은 할당된 메모리 블록(1102b)을 가리키는 포인터 P1를 태그 청색으로 태깅할 수 있다. malloc에서 상기 move 명령어의 결과로서 트리거되는 제 1 규칙은 다음과 같을 수 있다:
위의 규칙은 오로지 CI 태그가 tmalloc일 때 발동하고 그래서 malloc의 태깅된 move 명령어에 대해서 발동한다. malloc에 의해 사용된 포인터가 P1이라고 가정하면, 위의 mv 규칙 1A는 레지스터 R2에 저장된 태그 P1을 태그 또는 컬러 청색으로 태깅하여, 이것이 청색 메모리 위치(예를 들어, 청색 태그로 태깅된 메모리 위치)를 가리키는 포인터임을 나타낸다.
청색으로 태깅된 포인터 P1는 할당된 메모리 블록(1102b)에 0 또는 각 워드에 대한 몇몇 다른 초기 값을 할당된 메모리 블록(1102b)에 기입하라는 malloc의 또 다른 제 2 스토어 명령어와 함께 사용될 수 있다. 예를 들어 "*P1=0"이 "Store R3, (R2)"을 발생하는 malloc C 코드에 포함될 수 있는데, 여기서 R3은 제로(0)를 포함하는 소스 레지스터 오퍼랜드 OP1이고, R2는 어드레스 P1을 포함하는 OP2 레지스터이다. 이와 같은 스토어 명령어에서, "(R2)"는 오퍼랜드 MR이고 또한 스토어 명령어의 타깃 또는 목적지인 메모리 위치를 나타낸다. 또한, malloc의 위의 스토어 명령어는 또한 tmalloc으로도 태깅될 수 있고 다음과 같이 제 2 특수 스토어 규칙을 트리거하는 결과를 가져올 수 있다:
태깅된 포인터 P1를 malloc을 호출한 사용자 코드에 리턴하기 전에,
위의 스토어 규칙 2A는 오로지 CI 태그가 tmalloc 일 때, (P1를 나타내는) R2 내의 포인터 또는 어드레스가 청색으로 태깅될 때, 및 P1이 가리키는 메모리 위치 MR이 F 태그를 가질 때만 발동한다. 전술한 메모리 위치 *P1은 메모리 위치를 청색으로 컬러화하기 전에 "F"로 태깅된 것으로 가정한다. 이 예에서, F는 프리 메모리 위치를 나타낸다. 결과로 생성된 메모리 위치에 대한 MR 태그는 메모리 위치에 대한 청색 태그를 나타낸다.
따라서 malloc은 할당되는 메모리 블록의 각 메모리 위치에 대해 위에서 언급한 제 2 규칙을 트리거하는 결과를 가져오는 코드를 포함할 수 있다.
malloc은 malloc 메타데이터 부분(1102a, 1104a 및 1106a)을 초기화하는데 사용하기 위해 아래에 설명된 추가 규칙을 트리거하는 코드(예를 들어, 상기 무브(mv) 규칙 1A 및 스토어 규칙 2A와 유사함)를 또한 포함할 수 있다. 예를 들어, malloc C 코드는 "(P1 - 2) = MD 영역"일 수 있고, 여기서 MD 영역은 malloc 메타데이터 영역(1102a)을 가리키는 포인터이고 무브 명령어는 "move R7, R8"일 수 있고, 여기서 레지스터 R7은 어드레스 "P1 - 2"를 포함하는 소스 레지스터이며, 레지스터 R8은 포인터 MD 영역인 목적지 레지스터이다. 위의 무브 명령어에 의해 트리거되는 규칙은 다음과 같을 수 있다:
MD 영역 포인터를 적색으로 태깅하는,
malloc은 malloc 메타데이터 부분(1102a, 1104a 및 1104c)에 대해 각각 태그(1112a, 1114a, 1116a)를 저장하는 것과 같이 malloc 메타데이터 부분의 각 메모리 위치에 태깅하는 아래에 언급된 (위의 스토어 2A 규칙과 유사한) 저장 규칙 2B를 트리거하는 코드를 또한 포함할 수 있다. 예를 들어, 크기가 malloced 메모리 블록(1102b)의 크기를 나타내는 정수이고 "*(P1-2)=size"가 "Store R6, (R7)"을 초래하는 malloc C 코드에 포함되어 있는 것으로 가정하며, 여기서 R6은 크기 값을 포함하는 소스 레지스터 오퍼랜드 OP1이고, R7은 어드레스 P1을 포함하는 OP2 레지스터이다. 이러한 스토어 명령어에서, "(R7-2)"는 오퍼랜드 MR이고, 또한 스토어 명령어의 타깃 또는 목적지인 MR(1102a) 내의 메모리 위치를 나타낸다. 스토어 규칙 2B는 다음과 같을 수 있고:
이는 스토어 명령어가 태깅된 tmalloc이면, 어드레스 P1을 포함하는 R7 레지스터가 적색으로 태깅되면, 그리고 MR 오퍼랜드가 F로서 태깅되면, 스토어를 수행하는 것이다. 실시예는 위에서 언급한 스토어 2B 규칙의 변형예인 위에서 언급한 스토어 규칙 2D (store 2D)를 또한 포함할 수 있고, 이에 따라 스토어 2D 규칙은 메타데이터 값의 업데이트가 바람직한 경우에 사용될 수 있다.
나중 시점에서, 예컨대 청색으로 컬러화된 블록(1102b)을 프리로 만들거나 또는 할당 해제할 때, free는 이전에 할당된 메모리 블록(예를 들어, 사용자 코드 사용을 위해 할당된 메모리 블록)의 메모리 위치를 다시 태깅하기 위해 아래에서 언급되는 스토어 규칙 3을 트리거하게 하는 "*P=0"과 같은 코드를 포함할 수 있다. 로더는 free 명령어를 tfree로 컬러화하거나 태깅할 수 있다. 루틴 free는 "Store R4, (R1)"을 초래하는 C 코드 문장 "*P=0"을 포함할 수 있는데, 여기서 R4는 제로를 포함하는 소스 레지스터 오퍼랜드 OP1이고, R1은 초기화될 메모리 위치의 어드레스를 포함하는 OP2 레지스터이며, "(R1)"은 메모리 위치를 가리키는 어드레스를 포함하는 R1을 갖는 메모리 오퍼랜드 MR를 나타낸다. 스토어 규칙 3은 다음과 같을 수 있다:
따라서 free는 할당 해제되는 메모리 블록의 각 메모리 위치에 대해 위에서 언급한 제 3 규칙을 트리거하게 하는 코드를 포함할 수 있고, 여기서 메모리 블록은 (예를 들어, malloc 메타데이터 이외의 데이터를 저장하기 위해 사용된) 사용자 코드에 의한 사용을 위해 malloc을 사용하여 이전에 할당된다. 스토어 규칙 3은 CI tag = t가 free이고 메모리 위치와 이를 가리키는 포인터 둘 모두가 동일한 컬러인 청색인지를 보장하기 위해 체크한다.
"청색"의 MR 태그는 일반적으로 할당된 사용자 메모리 블록을 컬러화하기 위해 malloc에 의해 이전에 사용된 임의의 컬러일 수 있다는 것을 유의하여야 한다.
free의 코드는 (1112a)와 같이 malloc 메타데이터 부분의 각 메모리 위치를 다시 태깅하는 것과 관련하여 아래에 설명된 move(mv) 규칙 1C 및 스토어 규칙 4를 트리거하는 코드를 또한 포함할 수 있다. free의 코드는 위의 move(mv) 규칙 1B와 유사한 아래에서 언급되는 move(mv) 규칙 1C를 트리거하는 코드를 포함할 수 있다. move(mv) 규칙 1C는 다음과 같을 수 있고:
이는 이는 스토어 규칙 4를 사용하여 다시 태깅하는 것과 관련하여 free에 의해 사용하기 위해 적색 포인터를 태깅하는 것일 수 있다.
아래의 스토어 규칙 4(위의 스토어 규칙 3과 유사함)는 메타데이터 부분의 각 메모리 부분을 다시 태깅하기 위해, 예컨대 메타데이터 부분(1102a, 1104a 및 1106a)에 대해 각각 다시 태깅(1112a, 1114a, 1116a)하기 위해 트리거될 수 있다. 스토어 규칙 4는 다음과 같을 수 있고:
이는 스토어 명령어가 태깅된 tfree이면, 그리고 및 MR 오퍼랜드가 적색으로 태깅된 포인터를 사용하면, 스토어를 수행한다. 메모리 위치는 "F"로 태깅되어 이제 이것이 free라고 표시한다.
제 4 실시예에서, PC 태깅은 malloc 메타데이터 부분(1102a, 1104a 및 1106a)으로부터 데이터를 판독하고 malloc 메타데이터 부분(1102a, 1104a 및 1106a)에 데이터를 기입하며 또한 다른 코드가 전술한 메타데이터 부분에 액세스하는 것을 배제하는데 충분한 권한, 액세스 또는 인가를 malloc 및 free에게 제공하도록 malloc 및 free을 준비시키는데 사용될 수 있다. PC 태깅은 예를 들어, 상이한 PC 태그 값을 사용하여 프로세스별로 상이한 권한, 액세스 또는 인가를 제공하는 예(430)과 관련하여, 본 명세서의 다른 곳에서 설명된다. 유사한 방식으로, 특수하거나 고유한 PC 태그 값은 malloc 메타데이터 부분(1102a, 1104a 및 1106a)과 관련하여 로드 및 스토어 동작을 수행하는 인가를 malloc 및 free에게 제공하기 위해 사용될 수 있다. 더 자세히 설명하면, malloc은 tmalloc으로 태깅된 명령어를 포함할 수 있다(예를 들어, 명령어가 실행될 때 CI tag=tmalloc). malloc은 또한 실행될 때, malloc 메타데이터 부분(1102a, 1104a 및 1106a)에 액세스하는 권한 또는 인가를 나타내는 출력으로서 특정 PC 태그를 전파하거나 생성하는 규칙의 적용을 트리거하는 코드를 포함할 수 있다. malloc은 다음과 같은 제 1 명령어 INS1을 포함할 수 있다:
여기서 R2는 영역(1102a)의 어드레스 P6과 같은 malloc 메타데이터 부분의 어드레스이고, (R2)는 적색으로 컬러화된 (1102a) 내의 어드레스 P6을 갖는 메모리 위치를 나타낸다. 전술한 명령어 INS1은 실행될 때, X1와 같은 태그 값을 갖는 PCnew를 생성할 수 있고, 여기서 X1은 (1102a)에 액세스하는데 필요한 권한을 나타낸다. 이 경우, 위의 제 1 명령어 INS1에 대해 트리거된 규칙은 다음과 같을 수 있고:
이는 R2를 적색으로 컬러화하고, 또한 PC를 X1로 설정하여 R2에 저장된 어드레스(예를 들어, 어드레스 P6)를 갖는 메모리 위치로의 판독/기입 액세스를 표시한다. 이어서, malloc은 레지스터 R3로부터의 값(예를 들어, OP1)을 어드레스 P6(P6은 R2에 저장됨)을 갖는 메모리 위치에 저장하는 "store R3, (R2)"라는 제 2 명령어 INS2를 포함할 수 있다. 위의 제 2 명령어 INS2에 대해 트리거된 규칙은 다음과 같을 수 있다:
여기서 PCnew는 클리어되거나 malloc 메타데이터 부분(1102a)에 액세스하는 권한을 표시하지 않는 디폴트 PC 태그인 PCdefault로 리셋된다. 따라서, 이와 같은 특정 예에서, 제 1 ADD 명령어는 (1102a)에 대한 판독/기입 액세스 권한 또는 인가를 malloc에게 허여하는 규칙을 트리거한다. 기입을 수행하는 위의 제 2 malloc 명령어가 실행된 후, 전파된 PC 태그는 (1102a)에 대한 판독/기입 액세스를 위한 권한 또는 인가를 malloc으로부터 제거한다. 변형예로서, 실시예는 X1의 PCnew 태그를 생성함으로써 (1102a)에 대한 판독/기입 액세스를 malloc에게 허여하는 규칙을 트리거하는 명령어를 포함하는 프롤로그를 갖는 malloc의 버전을 포함할 수 있다(예를 들어, 프롤로그는 위에서 언급한 규칙을 트리거하는 Add 명령어 INS1을 포함한다). 리턴하기 전 malloc의 종료시, 실행될 때, PCdefault의 PCnew 태그를 생성함으로써 malloc의 판독/기입 액세스를 제거하는 규칙을 트리거하는 명령어를 포함하는 에필로그가 실행될 수 있다(예를 들어, 에필로그는 위에서 언급한 규칙을 트리거하는 스토어 명령어 INS2를 포함한다).
유사한 방식으로, free는 (1102a)로의 액세스를 free에게 제공하기 위해 PCnew 태그 값을 생성하거나 전파하는 규칙을 호출하는 명령어를 포함할 수 있다. 적용된 규칙은 특정한 프로세스에 기초하여 원하는 액세스, 권한 또는 인가를 나타내는 출력으로서 특정 PC 태그를 전파하거나 생성할 수 있고, 이에 따라 특정 허용된 권한, 액세스 또는 인가가 상이한 PC 태그 값에 의해 표현될 수 있다.
전술한 바는 모든 malloced 메모리 블록에 대해 단일 컬러 청색 및 모든 malloc 메타데이터 부분에 대한 단일 컬러 적색을 예시하고 있음을 주목하여야 한다. 보다 일반적으로, 본 명세서의 다른 곳에서 설명된 바와 같이, malloc은 힙 메모리의 다른 부분을 컬러화하는데 필요할 수 있는 새로운 컬러를 무한대로 생성할 수 있는 인가를 제공받을 수 있다. 본 명세서의 다른 곳에서 논의된 바와 같이, 예를 들어, malloc는 초기에 미리 결정된 하나 이상의 컬러 세트 또는 태그를 제공 받을 수 있고, 이어서 초기의 미리 결정된 세트로부터 필요한 태그를 생성할 수 있다. 예를 들어, malloc의 초기의 미리 결정된 세트는 황색 또는 Y 및 적색 또는 R을 포함할 수 있다. 실행중인 프로세스의 경우, 각 call to malloc에 대해 새로운 Y-기반 태그(예를 들어, Y1, Y2, Y3, . . . )를 생성하여 사용자 코드에 의해 사용되는 (예를 들어, malloc 메타데이터 저장소 이외의) 새로운 메모리 블록을 할당할 수 있다. 따라서, 상이한 Y-기반 태그는 각각의 할당된 메모리 블록(1102b, 1104b 및 1106b)을 컬러화하는데 사용될 수 있다(예를 들어, (1102b)는 Y1로 컬러화되고, (1104b)는 Y2로 컬러화되고, (1106b)는Y3로 컬러화된다). malloc은 각 call to malloc에 대해 생성된 각각의 상이한 malloc 메타데이터 부분에 대해 새로운 R-기반 태그(예를 들어, R1, R2, R3,...)를 생성할 수 있다. 따라서, R-기반 태그는 malloc 메타데이터 부분(1102a, 1104a, 1106a)을 각각 상이한 R-기반 태그로 컬러화하는데 사용될 수 있다(예를 들어, (1102a)는 R1로 컬러화되고, (1104a)는 R2로 컬러화되고, (1106a)는R3로 컬러화된다). malloc에 의해 사용되는 현재 또는 마지막 R-기반 태그 및 현재 또는 마지막 Y-기반 태그는 malloc 명령어를 실행할 때 트리거되는 규칙을 통해 상태 정보로서 저장될 수 있다. 예를 들어, malloc은 마지막 Y-기반 태그 Y9를 제 1 메모리 위치의 태그로 저장하는 규칙을 트리거하는 명령어를 포함할 수 있다. Y9는 Rtag로서 생성될 수 있다. 후속 명령어는 저장된 마지막 Y-기반 태그인 Y9로 태깅된 동일한 제 1 메모리 위치를 다시 참조할 수 있으며, 이 경우 후속 명령어는 1) 마지막 Y-기반 태그 Y9에 기초하여 새로운 태그 Y10을 생성하고, 및 2) 태그로서 태그 Y10을 제 1 메모리 위치에 저장하는 규칙을 트리거한다. Y10은 Rtag로서 생성될 수 있다. 후속 명령어에 의해 트리거된 규칙은 Rtag를 예를 들어, MRtag +1로 결정할 것을 지시할 수 있으며, 여기서 MRtag는 후속 명령어에 대해 Y9이다.
이제 하드웨어 가속화된 미스 처리를 사용하는 메타데이터 처리와 관련하여 최적화로서 사용될 수 있는 기술이 설명될 것이다. 일반적으로, 본 명세서의 실시예에서 사용되는 일부 정책은 빈번한 규칙 캐시 미스를 유발할 수 있고 그러한 정책을 위한 캐시 미스 핸들러는 실행하는데 많은 사이클을 가질 수 있다. 일부 정책에서, 다양한 규칙 입력 간의 관계가 결과 또는 성과를 논리적으로 결정한다는 점에서 약간은 단순할 수 있고 그래서 전용 하드웨어를 사용하여 신속하게 하드와이어드되고 해결될 수 있다.
결과적으로, 하드웨어(HW) 규칙 캐시 미스 핸들러를 사용하여 구현된 이러한 정책은 이러한 하드웨어 가속을 사용하지 않는 다른 것보다 훨씬 짧은 양의 시간 내에 해결될 수 있다. 이러한 실시예에서, 하나 이상의 선택된 정책을 위한 캐시 미스 핸들러와 같은 정책 컴포넌트는 전용 하드웨어로 구현될 수 있다. 따라서, 본 명세서에서의 기술에 따른 실시예는 소프트웨어 규칙 캐시 미스 핸들러를 사용하여 소프트웨어 정의된 정책 컴포넌트 단독으로, 또는 소프트웨어 정의된 정책 컴포넌트와 함께 그러한 하드웨어 지원 정책을 사용할 수 있다.
하나의 예로, 메모리 안전 컬러화를 사용하는 메모리 안전 정책을 고려해 본다. 예컨대 본 명세서의 다른 곳에서 설명된 메모리 안전 정책과 관련하여, 메모리 셀 및 포인터는 컬러화될 수 있고, 이에 따라 로드 및 스토어 동작과 관련하여 호출되는 규칙은 포인터 컬러가 메모리 셀의 컬러와 매칭하는 메모리 참조만을 허용할 수 있다. 예를 들어, 로드 명령어에 대해 트리거되는 규칙은 (예를 들어, 레지스터가 OP1과 같은 오퍼랜드인 레지스터 태그의) 포인터 컬러가 메모리 셀 컬러(예를 들어, Mtag와 같은 메모리 위치 태그)와 동일한 정책을 시행하는데 사용될 수 있다. 메모리 안전 정책은 이와 같이 동일한 컬러 관계를 많은 컬러에 대해 간단하게 담아주는 많은 상이한 구체적인 규칙으로 PUMP 규칙 캐시를 채워줌으로써 용량에 도전할 수 있어서, 용량 미스 레이트를 높인다. 규칙 캐시를 프리로드하지 않는 본 명세서에 설명된 일부 실시예에서, 이들 규칙을 하나 하나 모두 삽입하기 위해 강제 규칙 캐시 미스가 요구된다. 메모리 안전 정책 규칙은 일반적으로 실행중인 사용자 코드와 관련하여 통상 트리거될 수 있기 때문에, 소프트웨어 규칙 캐시 미스 핸들러가 아닌 HW 규칙 캐시 미스 핸들러를 사용하여 메모리 안전 정책 규칙이 지원될 수 있다.
이러한 실시예에서, HW 규칙 캐시 미스 핸들러는 규칙 캐시 미스가 발생할 때 캐시에 삽입된 새로운 규칙을 생성하거나 계산할 수 있다. 예를 들어, 메모리 안전을 위한 미스 핸들러는 로드 명령어에 대해 OP1tag를 Mtag와 비교하는 HW 규칙 캐시 미스 핸들러로서 하드웨어를 사용하여 구현될 수 있다. OP1tag가 Mtag와 동일하면, HW 규칙 캐시 미스 핸들러는 Rtag가 Mtag에 할당된 새로운 규칙을 생성할 수 있다. 예를 들어 포인터 PTR이 적색이고 PTR이 가리키는 메모리 셀이 적색이면, 규칙을 호출하는 명령어가 허용되고 결과 태그 Rtag는 적색이어야 한다. 규칙 캐시에 삽입될 새로운 규칙으로서 전술한 것을 발생하기 위해, HW 캐시 미스 핸들러는 먼저 OP1tag를 Mtag와 비교할 수 있다. 이들이 매칭하지 않으면, 규칙 위반이 있었으며 명령어는 허용되지 않는다(예를 들어, 프로세서로 하여금 실행을 중지하게 한다). HW 규칙 캐시 미스 핸들러가 OP1tag가 Mtag와 동일하다고 결정하면, HW 규칙 캐시 미스 핸들러는 opcode=로드, OP1tag=적색, Mtag=적색 및 Rtag=적색(규칙의 모든 다른 태그 입력 및 출력은 don't care일 수 있음)를 포함하는 새로운 규칙을 하드웨어의 출력으로서 생성할 수 있고, 그 다음에 생성된 규칙은 규칙 캐시에 삽입할 수 있다.
도 66을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 하드웨어로 구현된 캐시 미스 핸들러를 도시하는 예가 도시된다. 예(1300)는 룩업을 수행하여 입력(1302a)과 매칭하는 규칙이 캐시 내에 있는지를 결정하기 위해 PUMP 규칙 캐시(1302)(예를 들어, 도 22)에 입력되는 입력(1302a)을 도시하는 (1301)을 포함한다. 매칭하면, 출력(1302b)은 캐시에 저장된 규칙에 기초하여 결정된다. 본 명세서의 다른 곳에서의 논의와 일관하여, 입력(1302a)은 opcode 및 입력 태그 - PCtag, CItag, OP1tag, OP2tag, Mtag - 를 포함할 수 있다. 출력(1302b)은 PCnew tag 및 Rtag와 같은 규칙의 출력 태그를 포함할 수 있다. 캐시 미스 핸들러를 소프트웨어로 구현하는 본 명세서에서의 기술에 따른 실시예와 관련하여, 규칙 캐시 미스의 발생시, 소프트웨어 캐시 미스 핸들러가 호출될 수 있고, 이에 의해 미스 핸들러의 코드가 실행되어 현재 규칙 캐시 미스를 야기하는 입력(1302a)에 대한 새로운 규칙을 계산할 수 있다. 캐시 미스 핸들러는 먼저 입력이 허용 가능한 규칙과 일치하는지를 (예를 들어, 메모리 안전 로드 규칙의 경우, OP1tag이 Mtag과 동일한지를) 결정하고, 일치한다면, 특정 입력(1302a)에 대한 출력을 계산하며(예를 들어, Rtag를 Mtag으로 결정하며), 그럼으로써 입력(1302a)에 대한 규칙을 생성한다. (입력(1302a)과 미스 핸들러의 계산된 출력의 조합에 기초한) 새로운 규칙은 규칙 캐시에 삽입된다. 본 명세서의 다른 곳에서 논의된 바와 일관하여, 새로운 규칙은 opcode, 입력 태그 - PCtag, CItag, OP1tag, OP2tag, Mtag - 및 출력 태그 - PCnewtag, Rtag - 를 포함할 수 있다.
요소(1303)는 소프트웨어 규칙 캐시 미스 핸들러가 아닌 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 HW 규칙 캐시 미스 핸들러(1304)를 도시한다. 이러한 실시예에서, HW 규칙 캐시 미스 핸들러(1304)는 예를 들어, 게이트 레벨 로직 및 다른 하드웨어 컴포넌트를 포함하는 전용 하드웨어를 사용하여 구현될 수 있다. 이러한 실시예에서, HW 미스 핸들러(1304)는 PUMP 규칙 캐시(1302)와 동일한 입력(1302a)을 취할 수 있고 그의 하드웨어를 사용하여 PUMP 규칙 캐시에 출력될 동일한 출력(1302b)을 생성할 수 있다. 결과적으로, 위에서 언급한 바와 같이 opcode, 입력 태그 및 출력 태그를 조합함으로써 새로운 규칙이 형성될 수 있다. 그 다음에 새로운 규칙은 PUMP 규칙 캐시(예를 들어, 도 22)에 저장될 수 있다.
적어도 하나의 실시예에서, 메모리 안전 정책에 대한 HW 규칙 캐시 미스 핸들러는 규칙을 캐시 내로 로드하기 위해, 간단히 Mtag로부터 Rtag로 복사하고 즉시 PUMP 규칙 삽입을 수행할 수 있는 (예를 들어 게이트 레벨 로직을 사용하여) 전술한 바와 같이 하드웨어로 구현될 수 있다. 이렇게 간단한 경우에는 메모리를 참조할 필요가 없고 메모리의 모든 데이터 구조체 동작을 수행할 필요가 없다.
또한, 적어도 하나의 실시예에서, 메모리 안전은 메모리 셀의 태그를 한 쌍의 태그: (1) 메모리-셀 컬러 태그, (2) 메모리 셀 내의 포인터상의 포인터 컬러 태그로서 구현할 수 있다. 메모리-안전 가속은 Mtag 및 OP2tag를 스토어상의 새로운 Rtag내에 조합하고 Mtag 쌍으로부터 포인터-태그를 추출하여 로드에 대한 Rtag에 배치하는 전용 캐시를 포함할 수 있다. 이러한 캐시에 대한 미스에는 보다 간단한 전용 소프트웨어 핸들러가 사용될 수 있다. 전술한 바는 메모리 안전과 같은 단일 (비-복합) 정책에 관해 설명되었지만, 동일한 일반적인 기술이 UCP상의 복합 정책의 컴포넌트에도 적용될 수 있다.
실시예는 또한 공통으로 참조될 것으로 예상되는 규칙과 같은 규칙의 제한된 공통 서브세트에 대해 HW 규칙 캐시 미스 핸들러를 사용하여 하드웨어 가속을 수행할 수도 있다. 예를 들어, 메모리 안전에서, 산술 동안 로드/스토어 및 전파에 대한 규칙은 가장 표준적이고 양식화된 것이다. 초기에 메모리 영역을 컬러화하고 메모리 영역을 프리로 다시 돌려놓기 위한 다른 드문 규칙이 존재한다. 이러한 드문 규칙은 하드웨어 지원으로 구현되기 보다는 본 명세서에서 설명된 전형적인 규칙 미스 핸들러를 사용하게 할 수 있다.
적어도 하나의 실시예에서, HW 규칙 캐시 미스 핸들러는 매핑 기능을 게이트-레벨 로직으로서 직접 구현할 수 있다. 예를 들어, 이러한 게이트 레벨 로직 회로는 메모리 안전 정책의 스토어 명령 규칙에 대해 Mtag를 Rtag에 매핑하는 것과 같은 규칙을 위해 입력 태그를 출력 태그에 매핑할 수 있다. 다른 예로서, CFI(제어 흐름 무결성) 정책에 대한 HW 규칙 캐시 미스 핸들러는 게이트 레벨 로직을 사용하여 제어 흐름 타깃 또는 목적지의 태그를 허용된 호출자 세트(예를 들어, 태깅된 특정 제어 흐름 타깃 또는 목적지로 제어를 이전하도록 허용된 소스 위치 또는 어드레스)를 가리키는 포인터가 되게 하여, CFI HW 규칙 캐시 미스 핸들러가 매칭을 위해 그 세트를 통해 판독하게 할 수 있다. 또 다른 예로서, 스택 보호 정책은 하나가 다른 하나로부터 도출되는 하드웨어를 허용하는 방식으로 스택-프레임-코드 태그 및 연관된 스택-프레임-메모리-셀 태그를 인코딩할 수 있고(예를 들어, 이들은 단지 몇 비트만 상이할 수 있고, 이것은 스택-프레임-코드 태그 포인터 및 스택-프레임-메모리-셀 태그 포인터를 함께 할당함으로써 태그가 포인터였던 경우에도 배열될 수도 있음); 그 결과, 스택 보호 정책을 시행하는 HW 규칙 캐시 미스 핸들러는 (스택 포인터로부터 태그를 생성하는 경우에) 생성할 태그를 결정할 수 있거나 (판독 또는 기입의 경우에) 그러한 코드 내에서 메모리 참조를 요구할 수 있을 것이다.
HW 규칙 캐시 미스 핸들러를 사용하여 PUMP 규칙 캐시에 삽입되는 새로운 규칙을 계산하거나 결정하기 위한 변형예로서, 실시예는 하나 이상의 규칙이 완전히 구체화되고 하드웨어로 시행되고 그래서 PUMP 규칙 캐시에 저장되지 않는 는 그러한 하나 이상의 정책 규칙의 로직을 실제로 하드와이어할 수 있다. 예를 들어, 정책에 대해 HW 규칙 캐시 미스 핸들러 및 PUMP 규칙 캐시를 사용하는 대신, 실시예는 정책의 규칙(예컨대, 게이트 레벨 로직 및 회로와 같은 하드웨어에 구현된 정책의 규칙)을 시행하고 인코딩하는 하드웨어를 사용할 수 있다. PUMP 규칙 캐시 및 HW 특정 규칙 둘 모두를 사용하는 그러한 실시예에서, PUMP 규칙 캐시 및 HW 특정 규칙 모두의 규칙 룩업이 수행될 수 있다. 이 경우, PUMP 규칙 캐시 또는 HW 특정 규칙의 특정 입력을 위한 규칙을 찾지 않음에 따라 미스 핸들러(예를 들어, HW 규칙 캐시 미스 핸들러 또는 소프트웨어 미스 핸들러)가 호출되어 새로운 규칙을 결정/계산할 수 있다.
복합 정책은 추가적인 도전과 기회를 제시한다. 본 명세서의 다른 곳에서의 논의와 일관하여, 복합 정책은 명령어에 대해 동시에 시행되는 다중 정책을 포함한다. 과제는 복합 정책이 여러 상이한 정책 컴포넌트를 해결해야 한다는 것이다. 복합 정책의 전체적인 해결 순서는 복합 정책의 모든 상이한 정책 컴포넌트에 대해 데이터 캐시, (복합 정책의 정책 컴포넌트 당 UCP 캐시 당) UCP 캐시 및 CTAG 캐시를 이용한 HW 규칙 캐시 미스 핸들러를 사용하여 하드웨어에 의해 지원받을 수 있다는 것이 기회이다. 이전의 경험으로부터, 공통의 과제는 (예를 들어, malloc을 사용하여) 메모리를 새로 할당하고, 그래서 새로운 메모리를 컬러로 태깅하는 경우에, 강제적 규칙 캐시 미스가 야기되는 것이다. 이러한 경우, 메모리 안전 정책 컴포넌트에는 새로운 규칙이 필요하지만 다른 컴포넌트에는 이들의 규칙이 이미 UCP 캐시에 있을 가능성이 있다. 최상위 레벨 복합 정책 및 메모리 안전 컬러 매칭을 위한 HW 규칙 캐시 미스 핸들러를 통한 하드웨어 가속을 사용하면, 메모리 규칙 해결책은 소프트웨어 기반 미스 핸들러 코드를 실행하는 규칙을 해결하는데 수백 내지 수천 개의 사이클이 필요한 대신, 하드웨어에서 실행되고 캐시(예를 들어, 데이터 캐시, UCP 캐시 및 CTAG 캐시)와 상의하는 작은 유한 상태 머신으로 성취될 수 있다.
적어도 하나의 실시예에서, UCP 캐시는 컴포넌트 정책에 의해 분해될 수 있고, 다시 CTAG 캐시 내로 피드백될 태그 결과의 복합 세트를 생성하는 모든 것이 병렬로 해결될 수 있다. 모든 정책이 UCP 캐시에 의해 또는 메모리 안전을 위한 규칙과 같은 간단한 하드웨어 규칙에 의해 해결될 수 있다면, UCP 캐시를 룩업하는 총 시간은 정책 수에 비례하기 보다는 단일 정책의 총 시간일 것이다. 이것은 컴포넌트 정책의 수가 고정되어 제공된 하드웨어와 매칭된다면 완벽하게 작동한다. 그럼에도 불구하고, 약간의 변형은 이용 가능한 고정된 수의 UCP 캐시 전반에 컴포넌트 정책을 단순히 배포하는 것이므로, 순차적 UCP 캐시 해결책의 수는 컴포넌트 태그의 수 대 물리적 UCP 캐시의 수의 비에 불과하다.
도 67을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 사용될 수 있는 복합 정책과 관련하여 HW 규칙 캐시 미스 핸들러의 사용을 도시하는 예(1310)가 도시된다. 이러한 특정 예에서, 3 정책은 복합 정책을 포함하며, 이에 따라 모든 3 정책이 동일한 명령어에 대해 동시에 시행되지만, 보다 일반적으로 복합 정책은 임의의 수의 정책을 포함하며 3으로 제한되지는 않는다. 요소(1314a 내지 1314c)는 복합 정책을 포함하는 3 정책에 대한 HW 규칙 캐시 미스 핸들러이다. 입력(1312)은 특정 정책에 대한 규칙 출력(1316a 내지 1316c)을 각각 결정하거나 계산하는 HW 규칙 캐시 미스 핸들러(1314a 내지 1314c) 각각에 제공될 수 있다(예를 들어, HW 규칙 캐시 미스 핸들러(1314a)는 정책 A에 대한 Rtag 및 PCnew tag를 포함하는 출력(1316b)을 결정하고; HW 규칙 캐시 미스 핸들러(1314b)는 정책 B에 대한 Rtag 및 PCnew tag를 포함하는 출력(1316b)을 결정한다). 결과적으로, 출력(1316a 내지 1316c)은 3 정책에 대한 합성 Rtag 및 PCnew tag를 나타내는 단일 복합 결과(1318)으로 조합될 수 있다. 복합 결과(1318)를 결정하기 위해 출력(1316a 내지 1316c)을 조합하는 것은 또한 하드웨어 또는 소프트웨어를 사용하여 구현될 수 있다. 새로운 규칙은 캐시 내에 삽입되고 이 캐시에서 새로운 규칙은 복합 결과(1318)(예를 들어, Rtag 및 PCnew tag에 대한 복합 값)과 함께 규칙 미스 처리를 트리거하는 특정 명령어에 대한 입력(예를 들어, opcode 및 입력 태그)을 포함할 수 있다.
또한, 예(1310)에 도시되지는 않았지만, 실시예는 본 명세서에서의 기술에 따른 실시예에서 UCP 캐시 및 CTAG 캐시를 HW 규칙 캐시 미스 핸들러(1314a 내지 1314c)와 조합하여 사용할 수 있다. (예를 들어, 도 21, 도 23 및 도 24와 관련하여) 본 명세서의 다른 곳에서 설명된 바와 같이, 정책 A, B 및 C 각각은 가장 최근의 정책 결과 태그를 캐싱하는 자체의 UCP 캐시를 가질 수 있다(예를 들어, 정책 A에 대한 UCP 캐시는 명령어의 opcode 및 입력 태그의 조합에 기초하여 미스 핸들러(1314a)에 의해 최근에 계산된 결과 태그 - PCnewtag 및 Rtag 결과)를 저장한다. (예를 들어, 도 21, 도 23 및 도 24와 관련하여) 본 명세서의 다른 곳에서 설명된 바와 같이, CTAG 캐시는 정책 A, B 및 C와 같은 다수의 복합 정책으로부터 출력될 수 있는 개별 Rtag 값들의 특정 조합에 대한 Rtag의 복합 결과를 저장할 수 있다. CTAG 캐시는 또한 정책 A, B 및 C와 같은 다수의 복합 정책으로부터 출력될 수 있는 개별 PCnew tag 값들의 특정 조합에 대한 PCnewtag의 복합 결과를 저장할 수 있다. 따라서, 출력(1316a 내지 1316c)으로부터 복합 결과(1318)를 생성하는 하드웨어는 CTAG 캐시로부터의 정보를 이용하여 복합 결과(1318)를 결정할 수 있다. 또한, HW 규칙 캐시 미스 핸들러(1314a 내지 1314c)는 또한 정책 A, B 및 C에 대해 UCP 캐시로부터의 정보를 입력으로서 가질 수도 있다.
예(310)에서와 같이, 복합 정책의 모든 3 정책에 대한 HW 규칙 캐시 미스 핸들러를 갖는 것의 대안으로서, 실시예는 하나 이상의, 그러나 복합 정책을 포함하는 그러한 정책 전부보다는 적은 정책에 대해 HW 규칙 캐시 미스 핸들러를 구현하도록 선택적으로 선택할 수 있다. 이러한 실시예에서, 규칙 캐시 미스 핸들러의 일부분은 하드웨어로 구현될 수 있고, 복합 정책의 규칙 캐시 미스 핸들러의 나머지 부분은 본 명세서의 다른 곳에서 설명된 바와 같이 소프트웨어로 구현될 수 있다.
본 명세서에 설명된 바와 같은 일부 정책은 예컨대, 예를 들어, 메모리 안전 정책과 관련하여 새로운 태그를 할당할 수 있다는 것을 유의하여야 한다. 적어도 하나의 실시예에서, 새로운 태그를 할당할 수 있는 메모리 안전과 같은 정책에 대한 HW 규칙 캐시 미스 핸들러는 HW 기반 핸들러가 사용할 수 있는 새로운 태그 값의 FIFO 기반 캐시(예를 들어, 새로 할당된 태그 값이 생성됨에 따라 사용될 수 있는 태그의 캐시)를 구비할 수 있다. 할당된 태그가 어드레스를 나타내는 포인터이면, 캐시는 태그 값 대신 어드레스 또는 포인터를 포함한다. 이러한 방식으로, HW 규칙 캐시 미스 핸들러는 FIFO 기반 캐시로부터 최상위 엔트리를 판독함으로써 간단하게 할당을 수행할 수 있다. 주기적으로, 소프트웨어 핸들러는 FIFO 기반 캐시를 할당에 이용 가능한 새로운 태그로 다시 채우기 위해 메타데이터 처리 도메인에서 실행될 수 있다.
메타데이터 처리 도메인과 사용자 코드 또는 실행 도메인의 "정상적인" 코드 처리 사이에 완전하고 엄격한 분리가 존재하는 실시예가 본 명세서에서 설명된다. 변형예로서, 실시예는 보다 완화된 접근법을 취할 수 있고 사용자 코드 또는 실행 도메인에 의한 정보의 메타데이터 처리 도메인에 대한 수정 또는 기입을 여전히 허용하지 않지만, 메타데이터 도메인에 의해 정보/값을 사용자 코드 또는 실행 도메인으로 리턴될 수 있게 하는 전술한 엄격한 격리 모델을 확장할 수 있다.
이제 메타데이터 처리 도메인이 정상적 코드 처리 또는 실행 도메인에서 실행되는 코드에 의해 사용되거나 참조될 수 있는 값을 리턴하는 전술한 보다 완화된 접근법을 이용할 수 있는 적어도 하나의 실시예에 포함될 수 있는 기술이 설명될 것이다(예를 들어, 메타데이터 처리는 정상 또는 사용자 코드 실행 도메인으로의 입력되는 값을 리턴한다). 예를 들어, 본 명세서의 다른 곳에서 설명된 바와 같이, 실시예는 malloc 및 free 루틴을 사용할 수 있는데, 이러한 루틴은 malloc 및 free의 코드가, 실행될 때, malloc 메타데이터에 액세스하는 처리를 수행하는 기능, 새로운 컬러 태그를 생성하는 기능, 사용자 데이터 영역을 이러한 새로운 컬러 태그로 태깅하는 기능 등을 malloc 및 free에게 허용하는 규칙을 트리거하도록 하는데 필요한 고유한 기능을 제공하는 명령어 태그로 태깅된 코드를 갖는다. 전술한 바는 사용자 코드와 같은 다른 코드를 제외하고 malloc 및 free에 고유하게 할당되는 그러한 권한 또는 기능을 제공하는 것이다. 이제 malloc 및 free가 자신의 처리를 수행하고, 로더에 의해 malloc 및 free 코드를 특수 코드 태그(들)로 특수하게 태깅하여 이러한 코드를 특수 실행 권한을 갖는 malloc 및 free에 속하는 것으로 고유하게 식별하는 코드 태깅이 이용되는 실시예를 고려해 본다. 이러한 실시예에서, call to free를 만드는 사용자 코드는 예를 들어, 손상되었거나 그렇지 않으면 지금 할당 해제되고 있는 이전에 할당된 저장 영역의 시작점을 가리키지 않는 포인터 PTR1을 제공하는 사례일 수 있다. PTR1은 free에 의하면, malloc에 의해 이전에 할당된 사용자 데이터 영역의 제 1 위치를 가리키는 것으로 추정할 수 있다. free는, 예를 들어, malloc 메타데이터가 할당된 사용자 데이터 영역에 대해 미리 결정된 위치에 저장되는, 예컨대, 도 64 및 도 65와 관련하여 설명된 메모리 힙의 사용자 데이터 영역 및 연관된 메모리 위치에 대해 미리 결정된 구조를 추정할 수 있다.
이제, PUMP가 값을 코드 실행 도메인에 리턴하게 하는 실시예에서 사용될 수 있는 기술이 설명될 것이다.
도 68의 예(1200)를 참조하면, 아래에서 논의되는 포인터 PTR1 및 PTR2라는 주석을 더 붙인 도 65의 예(1110)와 관련하여 설명된 요소(1111 및 1113)가 도시된다. 사용자 코드가 메모리 블록(1102b)을 할당 해제하려는 의도로 PTR1을 가진 free를 호출한다고 가정한다. P1는 free에 의해 예상되는 포인터 또는 어드레스를 나타낼 수 있다. 그러나, 이 예에서 PTR1은 일반적으로 P1 이외의 다른 어드레스를 나타내는 손상되거나 올바르지 않은 어드레스를 나타낼 수 있다(예를 들어, PTR1은 메모리(1102b) 내의 위치를 식별할 수 있거나 또는 힙을 가리키지도 않는 어드레스를 나타낼 수 있다). PTR1이 손상되었거나 그렇지 않으면 정확한 메모리 위치 P1을 가리키지는 않지만, free는 PTR1을 사용하는 처리를 수행하여 PTR1에 대한 상대적인 어드레스 지정을 사용하는 malloc 메타데이터에 액세스할 수 있는데, PTR1에서 malloc 메타데이터가 그의 미리 정의된 구조, 포맷 또는 레이아웃으로 존재한다고 가정된다. 예를 들어, free에 의해 사용된 malloc 메타데이터 영역은 도 64 및 도 65에서와 같이 할당된 사용자 데이터 부분 바로 이전에 위치하는 것으로 추정될 수 있다. 이러한 경우, free의 코드는 특정 메모리 블록을 할당 해제하기 위해 자신이 처리하는데 사용하는 malloc 메타데이터가 미리 결정된 레이아웃에 기초하여 PTR1 이전의 특정 오프셋 OFF1에 위치한다고 결정한다. 예를 들어, 도 68을 참조하면, free는 사용자 코드에 의해 PTR1이 call to free에 제공될 수 있는 PTR1=P1이라고 추정할 수 있다. free는 할당 해제될 메모리 블록(1102b)에 대응하는 malloc 메타데이터(1102a)가 어드레스 PTR2=PTR1-OFF1을 갖는 메모리 위치에서 시작해야 한다는 미리 정의된 데이터 레이아웃에 기초한 전술한 바와 같은 상대적 어드레스 지정을 사용할 수 있다. 이 예에서, PTR1은 P1과 동일하지 않고, PTR1은 어드레스 계산 PTR2=PTR1-OFF1이 사용자 할당된 메모리 블록(1102b)에서도 또한 존재하도록 실제로 할당된 메모리 블록(1102b)의 어딘가를 가리킨다(PTR2는 free에 의해 사용된 연관된 malloc 메타데이터의 예상된 시작점을 나타내고 있다).
free 호출에 관한 사용자 코드에 의해 제공된 PTR1이 예상된 위치 P1를 가리키지 않고 그래서 PTR2가 free에 의해 사용된 malloc 메타데이터의 추정된 시작점을 나타내는 그러한 경우에, free의 코드는 (PUMP에 의해 발견된 규칙 위반 또는 free의 실행 중 다른 코드 실행 오류 조건에 기인할 수 있는) 위반, 인터럽트 또는 트랩을 유발하는 malloc 메타데이터와 같은 데이터를 사용하여 메모리 블록(1102b)에 저장된 데이터에 부정확하게 액세스할 수 있다. 따라서 사용자 프로세스 공간 또는 도메인에서 실행되는 코드의 실행은 사용자 코드로부터 PTR1을 사용하여 call to free 에서 호출된 것처럼 루틴 free를 실행하는 동안 전술한 위반으로 인해 중단될 수 있다. 루틴 free가 사용자 코드의 중단을 일으키게 하기 보다는, free의 코드가 PUMP로 쿼리하게 하거나, 보다 일반적으로는 메타데이터 처리가 값을 리턴하게 하는 것이 바람직할 수 있다. 리턴 값은, 예를 들어 (free 코드에 의해 malloc 메타데이터에 액세스하는데 사용되는) PTR2와 연관된 컬러가 실제로 유효하거나 예상되는 malloc 메타데이터 영역을 가리키는지를 나타내는 부울(Boolean)일 수 있다. 그러한 리턴된 PUMP 값 또는 메타데이터 처리 값을 사용하면 free는 어드레스 PTR2의 메모리 위치와 연관된 컬러가 적색과 같은 유효한 malloc 메타데이터 컬러를 나타내는지에 기초하여 상이한 조건부 처리를 수행할 수 있게 된다. 루틴 free는 PTR2가 PTR2의 컬러를 통해 결정된 것처럼 유효하지 않은 malloc 메타데이터 영역을 식별하면, 일부 복구 또는 다른 조치를 수행할 수 있다. 이러한 조치는 규칙 위반, 트랩, 인터럽트 또는 기타 실행 오류로 인해 사용자 코드를 중단시키는 것보다 바람직할 수 있다.
RISC-V 명령 세트를 사용하는 적어도 하나의 실시예에서, 메타데이터 처리 값의 리턴을 구현하기 위해, 다음과 같이 새로운 명령 gmd(get-metadata-info)가 RISC-V 명령 세트에 추가될 수 있다:
여기서 R1은 PUMP 또는 메타데이터 처리에서 리턴된 결과 값을 포함하고;
R2는 어드레스 PTR2를 갖는 메모리 위치의 컬러로 태깅된 어드레스 PTR2를 포함하며;
R3은 유효한 malloc 메타데이터 영역에 대해 예상대로 유효한 컬러로 태깅된다.
따라서, R2 및 R3은 입력 또는 소스 오퍼랜드인 레지스터일 수 있고, R1은 결과 또는 출력을 포함하는 레지스터일 수 있다. 이러한 특정 예에서, R3tag는 유효한 malloc 메타데이터 영역의 컬러를 나타내는 적색일 수 있고 R2tag는 청색일 수 있다. 새로운 명령어에 의해 호출된 규칙은 이 예에서 R2tag=R3tag인지를 나타내는 부울로서 리턴 값을 출력할 수 있는데, 여기서 전술한 부울 결과는 사용자 실행 코드의 어드레스 공간에 포함된 free에 액세스 가능한 레지스터 R1에 저장된 메타데이터 규칙 처리에 의해 출력된 리턴 값(예를 들어, PUMP 출력)일 수 있다. 본 명세서의 다른 곳에서의 논의와 일관하여 R1은 결과 태그로서 Rtag로 태깅될 수 있다는 것을 알아야 한다.
다음은 위에서 설명한 바와 같이 PTR1, PTR2 및 OFF1과 함께 C-유사 의사 코드(C-like pseudo code) 서술을 사용하여 free 코드에 의해 수행될 수 있는 로직 처리를 설명한다:
위의 로직 처리에서, IS_RED는 PTR2가 컬러 RED인지를 알기 위해 체크할 수 있다.
위에서 언급된 else 블록의 코드에 의해 수행된 복구 처리는, 예를 들어, PTR2로부터 역방향 또는 순방향으로 검색함으로써 유효한 malloc 메타데이터 영역의 시작점을 찾도록 시도할 수 있다. 위에서 언급된 else 블록의 코드는 사용자 코드를 더 많이 정의된 예측된 방식으로, 예컨대 유효하지 않게 컬러화된 포인터 PTR2임을 나타내는 런타임 에러 메시지/조건으로 종료하게 할 수 있다.
새로운 명령어 Get metadata info R1, R2, R3은 예를 들어 위에서 언급된 로직 처리를 수행하기 위해 C에 기입된 free 루틴의 코드를 컴파일하고 링크한 결과로서 발생된 명령어에 포함될 수 있다. 실시예는 어떤 특정 코드 부분이 이러한 새로운 명령어를 실행하게 허용될 수 있는 것을 제어하거나 제한하기를 원할 수 있다. PUMP 규칙은 이러한 새로운 명령어가 어떤 루틴에 의해 실행되게 허용될 수 있는 때를 중재하거나 제한하는데 사용될 수 있다. 예를 들어, free 또는 malloc 코드는 새로운 Get metadata info 명령어를 실행하도록 허용될 수 있지만 사용자 코드는 허용되지 않을 수 있다. 임의의 적절한 기술 중 일부가 본 명세서에서 설명된 임의의 적합한 기술은 루틴 free에게 PUMP 값을 리턴하는 새로운 명령어를 실행하는데 필요한 권한 또는 인가를 제공하기 위해 사용될 수 있다. 예를 들어, free의 코드는 free가 새로운 명령어를 실행하도록 허용됨을 나타내는 특수 명령어 태그로 태깅될 수 있다. 예를 들어, 로더는 free 코드에 출현하는 새로운 명령어에 특수 태그 NI로 태깅할 수 있다. 규칙은 코드가 새로운 명령어를 호출하도록 허용될 수 있는 것을 NI의 명령어 태그(CI 태그)를 가진 코드에게 중재하거나 제한하는데 사용될 수 있다.
도 69를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 메타데이터 규칙 처리의 입력 및 출력을 도시하는 예(1210)가 도시된다. 요소(1212)는 일반적으로 본 명세서에서 설명된 바와 같은 메타데이터 처리를 나타낼 수 있다. 메타데이터 처리로의 입력(1212a)은 예를 들어, 본 명세서에서 설명된 바와 같이 다양한 태그 및 opcode 정보를 포함할 수 있다. 메타데이터 처리(1212)에 의해 발생된 출력(1214)은 본 명세서의 다른 곳에서 설명된 바와 같이 Rtag(1214a) 및 PCtag(1214b)를 포함할 수 있다. 또한, 메타데이터 처리는 리턴 값(1214c)인 새로운 출력을 발생할 수 있다. 리턴 값(1214c)은 사용자 프로세스 공간/코드 실행에 액세스 가능한 레지스터들의 세트에 있는 새로운 명령어를 가진, 위에서 표시된 R1과 같은 레지스터에 위치될 수 있다. 본 명세서의 다른 곳에서의 설명과 일관하여, (1214a 및 1214b)는 결과(예를 들어, 결과 레지스터 또는 메모리 위치) 및 PC 상에 각각 배치되는 태그를 나타내며, 따라서 (1214a 내지 1214b)는 사용자 프로세스 공간/코드 실행에 액세스 가능하지 않다. 메타데이터 처리가 리턴 값(1214c)을 리턴하는지는 특정 명령어 또는 opcode에 조건부일 수 있음을 유의하여야 한다. 예를 들어, 본 명세서의 다른 곳에서 설명된 바와 같이, 메타데이터 처리 출력은 리턴 값(1214c)의 출력을 인에이블/디스에이블하게 하는 멀티플렉서를 사용하는 opcode에 기초하여 도 27 내지 도 33과 관련하여 설명된 바와 같이 필터링될 수 있다. 이 예에서 값(1214c)은 opcode가 새로운 명령어의 값일 때 R2tag=R3tag인지의 로직 결과를 나타낸다. 그렇지 않고, opcode가 새로운 명령 opcode를 나타내지 않는다면, 디폴트 값이 리턴 값(1214c)으로서 메타데이터 처리에 의해 조건부로 리턴될 수 있다.
도 70을 참조하면, 메타데이터 처리에 의해 값을 사용자 실행 도메인으로 리턴할 때, 예컨대 위에서 설명한 바와 같이 free의 코드 내에 포함된 새로운 명령어를 실행할 때, 본 명세서에서의 기술에 따른 실시예에서 수행될 수 있는 컴포넌트 및 처리를 도시하는 예(1220)가 도시된다. 간략한 도시를 위해, 예(1220)는 이러한 새로운 리턴 값에 대한 목적지 또는 결과 레지스터 R1 및 연관된 결과 레지스터에 대해서만 사용되는 메타데이터 처리의 로직 및 컴포넌트를 도시한다. 요소(1222a)는 일반적으로 메타데이터 처리를 위해 본 명세서의 다른 곳에서 설명된 바와 같이 PUMP 입력(예를 들어, 이 예에서는 R2tag 및 R3tag, opcode와 같은 태그)을 나타낼 수 있다. PUMP(1222)는 새로운 명령어에 대해 코드 태그가 NI인지를 체크하는 규칙을 포함할 수 있고, R2tag=R3tag인지를 나타내는 로직 결과(예를 들어, 이 예에서는 제 1 입력 소스 오퍼랜드 R2를 나타내는 OP1 및 제 2 입력 소스 오퍼랜드 R3을 나타내는 OP2)를 출력한다. 규칙은 전술한 로직 결과(1221a)를 출력하게 된다. 요소(1225)는 멀티플렉서(1225) 대용의 선택기(1225a)로서 사용되는 연산 코드를 갖는 멀티플렉서를 나타낼 수 있다. 현재 명령어의 opcode가 새로운 명령 Get metadata info에 대한 특정 opcode를 나타낼 때, (1225a)는 리턴 값(1214c)으로서 출력되게 (1221a)를 선택한다. 그렇지 않고, opcode가 새로운 명령어의 opcode가 아니면, (1225a)는 리턴 값(1214c)으로서 디폴트 리턴 값(1222a)을 선택하게 된다. 리턴 값(1214c)은 목적지 레지스터 RD(1228)에 저장된 PUMP 출력이다(예를 들어, (1214c)는 D1(1228b)에 저장되어 사용자 프로세스 어드레스 공간에서 실행되는 코드에 액세스 가능한 레지스터 RD에 저장된 내용을 나타낸다). RD(1228)가 결과 레지스터이기 때문에, 규칙은 또한 RD를 Rtag로 태깅하게 될 수 있다(예를 들어, Rtag는 태그 부분 T1(1228a)에 저장되며, 여기서 T1은 RD 레지스터의 태그 워드이다). 적어도 하나의 실시예에서, Rtag는 RD가 새로운 명령어의 출력을 포함하고 있음을 나타내는 특수 태그 SPEC1일 수 있다. 규칙으로의 태그 입력이 (PCtag, CItag, OP1tag, OP2tag, MR tag)이고 규칙 출력이 (PCtag, Rtag) 및 새로운 리턴 값(1214c)을 나타내는 NEWOUT인 제 3 출력인 본 명세서의 다른 곳에서 설명된 상징적 로직에 기초하여, 규칙은 다음과 같이 표현될 수 있다:
보다 일반적으로, 새로운 명령어의 전술한 사용은 본 명세서에서의 기술에 따른 실시예에서, 호출된 메타데이터 처리 규칙을 통해 허용 가능한 새로운 명령어의 그러한 발생을 나타내기 위해 (예를 들어, NI로) 특수하게 태깅될 수 있는 임의의 적절하고 바람직한 값인 값을 리턴하는데 사용될 수 있다.
대안적인 실시예는 새로운 명령어를 추가하는 것을 피할 수 있다. 이것은 이러한 거동을 제어하기 위해 기존 명령어를 코드 태깅하고 이 경우에는 출력 값을 선택하도록 care 비트를 설정함으로써 이루어질 수 있다. 다른 대안은 PUMP의 출력이기도 한 value-output-care 비트를 추가하여 값 출력이 RD 값 결과로 흘러가야 하는 경우를 규칙이 결정할 수 있도록 하는 것일 수 있다. 이러한 두 번째 사례는 opcode가 태깅되지 않을 때는 정상적으로 거동할 수 있게 하고 적절한 코드 태그가 주어졌을 때만 이와 같은 특수한 거동을 발휘할 수 있게 한다.
이제 특정 명령어 시퀀스가 시퀀스의 제 1 명령어로부터 마지막 명령어까지의 특정 순서대로 단일 유닛으로서 또는 완전한 시퀀스로서 원자적으로 수행되는 것을 보장하기 위해 사용될 수 있는 기술이 설명될 것이다. 또한, 이러한 기술은 시퀀스의 제 1 명령어 이외의 명령어의 시퀀스에 제어가 이전되지 않으며 시퀀스의 마지막 특정된 명령어를 통하지 않고 시퀀스를 이전하거나 종료하지 않게 하는 것을 보증한다. 예를 들어, 도 71의 간단한 명령어 시퀀스를 고려해 본다.
예(1400)에서, 2 명령어(1402 및 1404)의 시퀀스가 도시된다. 제 1 명령어(1402)는 메모리 위치(메모리 위치의 어드레스는 R2에 저장되어 있음) 로부터 내용을 판독하거나 또는 R1에 로드한다. 제2 명령어는 동일한 메모리 위치(메모리 위치는 R2에 저장된 어드레스를 갖고 있음)에 제로(0)를 기입하거나 저장한다. 이러한 명령어 시퀀스는 메모리 위치(R2에서 특정된 어드레스를 갖고 있음)로부터 판독된 값이 단 한 번만 사용되는 것을 보장하기 위해 제공될 수 있으며, 이에 따라 이전의 값은 그 값이 메모리로부터 판독된 직후에 메모리 위치로부터 소거되거나 영 출력(zeroed out)된다. 따라서, 메모리 위치의 영 출력은 시퀀스의 제 2 명령어(1404)에 의해 수행되고, 메모리 위치로부터 값을 판독하는 제 1 명령어(1402) 이후에 시퀀스 내의 다음 명령어로서 수행되어야 한다.
RISC 아키텍처를 사용하는 본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 규칙은 (1400)의 명령어 시퀀스의 데이터 아이템의 전술한 선형성 및 원자성(atomicity)을 시행하기 위해 사용될 수 있다. 이러한 실시예에서, PC 태그(PCnew tag)는 시퀀스 내의 예상되는 다음 명령어의 시퀀스의 상태를 전달하도록 업데이트될 수 있다. 적어도 하나의 실시예에서, 하나의 해결책은 명령어(1402)를 CI로 태깅하여 이 명령어를 선형 판독 명령어(linear read instruction)로서 나타내는 것이다. 또한, R2에 저장된 어드레스를 갖는 메모리 위치를 나타내는 (R2)는 고유 메타데이터 id X1(예를 들어, X1는 이러한 선형 변수를 모든 다른 선형 변수로부터 고유하게 식별한다)을 갖는 선형 변수로서 입력되고 태깅될 수 있다. 제 1 규칙은 제 1 명령어(1402)의 결과로서 트리거될 수 있다. 제 1 규칙은 선형 판독치로서 태깅된 명령어만이 선형 변수로부터 판독되도록 허용된 것임을 표시할 수 있다. 또한, 결과적인 PCnew 태그는 실행된 다음 명령어가 선형 변수 X1을 클리어해야 함을 나타내는 clear-linear-variable-Xl-next일 수 있다. 제2 규칙은 제2 명령어(1404)를 실행하는 결과로서 트리거될 수 있고, 제2 명령어에서 오퍼랜드의 값, (메모리 위치에 기입된) 제로는 메모리 위치를 초기화 또는 클리어하는데 사용되는 특수 값을 나타내는 특수 EMPTY 태그로 태깅된다. 또한, 메모리 위치는 선형 변수 X1가 직전의 명령어(1402)로부터 특정 태깅된 선형 변수를 나타내도록 하는 것이 요구된다. (1402) 다음의 제2 명령어가 EMPTY 값을 선형 변수 X1로 기입하는 것 이외의 어떤 것을 행하면, 트랩이 발생된다. 따라서, (1400)에서 제 2 규칙은 명령어 시퀀스의 원하는 연속적 및 원자성을 시행한다.
보다 구체적으로, 제 1 명령어(1402)가 R2에 저장된 어드레스를 갖는 메모리 위치로부터 내용을 R1으로 로드하는 로드 명령어라고 가정한다. 로드 명령어는 다음과 같을 수 있다:
또한, 제 2 명령어(1404)가 R2에 저장된 어드레스를 갖는 메모리 위치로 제로(0)를 이동시키는 무브 명령어라고 가정한다. 무브 명령어는 다음과 같을 수 있다:
본 명세서의 다른 곳에서 언급된 규약에 따르면, 규칙은 opcode, 입력 태그 - PCtag, CItag, OP1tag, OP2tag, Mtag - 및 출력 태그 - PCtag, Rtag)로 정의될 수 있다. 전술한 규칙 규약에 기초하여, 제 1 로드 명령어에 대해, OP1은 R1이고, OP2는 R2이며, (R2)는 Mtag로서 태깅된 메모리 위치이다. 제 1로드 명령어에 의해 트리거되는 제 1 규칙은 다음과 같을 수 있다:
전술한 규칙 규약에 기초하여, 제 2 스토어 명령어의 경우, OP1은 0이고, OP2는 R2이고, (R2)는 Mtag로서 태깅된 메모리 위치이다. 제 2 무브 명령어에 의해 트리거된 제 2 규칙은 다음과 같을 수 있다:
이 예는 태그와 규칙을 사용하여 특정 명령어 시퀀스의 분할성(indivisibility)을 보장하는 방법을 보여준다. 관련 기술분야에서 통상의 기술자라면, 데이터가 특정 명령어 시퀀스의 일부로서 특정 방식으로만 액세스될 수 있도록 시행하는 것이 바람직한 다른 많은 시나리오에 이와 같은 일반적인 기술이 적용될 수 있다는 것을 쉽게 알 수 있다. 관련 기술분야에서 통상의 기술자는 이 기술이 명령어 시퀀스의 엄격한 시행이 요구되는 어떠한 사례에도 채택될 수 있음을 또한 쉽게 알 수 있다. 위에서 언급한 바와 같이, 일반적인 기술은 시퀀스 내 명령어 N으로부터의 새로운 PC(예를 들어, PCnew tag)를 이어져 있는 시퀀스(glued sequence) 내의 다음 명령어 N+1에 의해 트리거되는 규칙에 있는 PC 태그로서 체크되는 특수 태그로 태깅되는 것을 포함한다.
이제 RISC-V 아키텍처에 기초하여 본 명세서의 기술에 따른 실시예에서 시스템을 부팅 또는 시동하는 동작의 일부로서 수행될 수 있는 기술이 설명될 것이다. 다음 단락은 예컨대 CSR이 메타데이터 처리 도메인과 관련하여 사용될 수 있는 예(900)와 관련하여 본 명세서의 다른 곳에서 설명된 다양한 CSR을 언급할 수 있다.
본 명세서의 다른 곳에서 설명된 바와 같이, 부트스트랩 태그는 하드와이어드되거나 특정 ROM 위치에 저장된 값일 수 있다. 시스템의 부팅의 일부로서, 상이한 CSR, 메모리 등을 초기화하는 것을 포함하는 초기화를 일반적으로 수행하는 부트스트래핑 코드의 세그먼트가 실행될 수 있다. 초기화의 일부로서, 이러한 처리는 또한 초기에 메모리 위치를 초기 부트스트랩 태그로부터 도출된 디폴트 태그 값으로 태깅한다. 적어도 하나의 실시예에서, boottag CSR(예를 들어, 예(900)에서와 같은 sboottag CSR)과 같은 CSR은 시스템의 모든 다른 태그가 도출되는 초기의 "시드(seed)" 태그로서 사용되는 특수 boottrap 태그로 초기화될 수 있다. 로더와 같은 다른 코드 엔티티는 자체의 명령어를 특수하게 태깅되게 하여(예를 들어, CI 태그는 특수 명령어 태그로 설정됨), 특수 명령어 태그를 갖지 않는 다른 코드가 동작하도록 허용되지 않는 동작을 수행하는 특정 권한 또는 인가를 갖는 것으로 로더를 지정할 수 있다. 전술한 바는 트리거된 규칙이 원하는 태그 동작을 수행하도록 하기 위해 CI 태그가 특수 태그임을 보장하기 위해 CI 태그를 검사하는 로더의 코드에 의해 트리거되는 규칙을 사용하여 시행될 수 있다. 따라서, 예를 들어, 로더의 명령어에 태깅하는데 사용되는 특수한 CI 태그는 스타트업 프로세스의 일부로서 코드를 실행함으로써 트리거되는 특수한 규칙의 결과로서 부트스트랩 태그로부터 발생되거나 도출될 수 있다. 일반적으로, 코드 또는 저장된 명령어의 일부분이 태깅되면, 규칙은 그렇게 태깅된 코드의 실행에 의해 트리거되어 더 많은 원하는 태그를 발생하고 또한 그렇게 발생된 태그를 코드 및 데이터에 배치할 수 있다. 전술한 양상 및 다른 양상은 보다 상세하게 설명된다.
시스템의 스타트업 또는 부팅시, 예컨대 tagmode CSR(예를 들어, 예(900)의 (901r))에 저장된 태그 모드는 초기에 오프일 수 있다(예를 들어, 예(910)의 (911a)). 부트스트랩 ROM 프로그램은 먼저 default tag CSR(예를 들어, 예(900)의 (901c))를 특수 디폴트 태그 값으로 직접 설정하는 것으로 실행될 수 있다. 이어서, 부트스트랩 프로그램은 tagmode CSR을 메타데이터 처리 도메인이 디폴트 태그 CSR에 저장된 디폴트 태그를 모든 결과에 기입할 수 있는 모드로 설정할 수 있다. 달리 말하면, defaulttag 태그 모드(예를 들어, 예(900)의 (911b))에 있는 동안, PUMP 출력 Rtag는 항상 디폴트 태그 값이다.
이어서, 메모리 위치가 초기화되고 디폴트 태그로 태깅된 후, 모든 다른 후속 태그를 더 발생하거나 도출하기 위해 사용될 초기 태그 세트를 발생하는 처리가 수행될 수 있다(예를 들어, 초기 세트는 무한한 방식으로 하나 이상의 태그 발생을 도출하는데 추가로 사용될 수 있다). 이러한 처리는 초기 태그 세트를 생성하는 규칙을 트리거하는 명령어 시퀀스 또는 코드 세그먼트를 실행하는 것을 포함할 수 있다. 이 경우, 태그 모드는 코드 세그먼트의 실행 동안 PUMP를 연계시키는 적절한 태그 모드 레벨로 설정될 수 있다. 예를 들어, 부팅 코드가 하이퍼바이저 모드에서 실행 중이면, (911e)에 의해 나타낸 바와 같이 x110으로 설정되거나 (911f)에 의해 나타낸 바와 같이 x111로 설정되어, 코드 세그먼트의 실행 동안 PUMP를 연계시키며, 이에 의해 규칙은 코드 세그먼트 명령어의 결과로서 트리거되고 시행된다.
위에서 언급한 코드 세그먼트를 실행하기 전에, 코드 세그먼트를 검증하거나 입증하는 처리가 수행될 수 있음에 유의하여야 한다. 예를 들어, 적어도 하나의 실시예에서, 위에서 언급한 코드 세그먼트는 실행에 앞서, 코드 세그먼트가 변경되거나 수정되지 않았음을 보장하기 위해 (예를 들어, 예컨대 디지털 서명을 사용하여) 암호 해독 및 검증되거나 입증되는, 암호화된 형태로 저장될 수 있다.
추가로 설명하면, 부트스트랩 프로그램은 PUMP가 연계되는 동안 실행되는 위에서 언급한 코드 세그먼트 4 명령어에 포함되어 초기 태그 세트를 생성할 수 있다:
위의 명령어 1에서, R1은 범용 레지스터이다. 명령어 1은 boottag CSR을 판독하여 boottag CSR에 저장된 값과 boottag CSR에 저장된 태그 둘 모두를 R1로 전달한다. boottag CSR은 프로세서 리셋 동안 또는 자기의 태그를 비롯한 CSR의 권한 있는 모드 기입에 의해 특정 태그를 보유하도록 설정되었다. boottag CSR로부터 판독하면 또한 boottag CSR을 클리어할 수 있으므로 부팅 동안 초기 검색 이후에는 검색되는 것이 가능하지 않다.
"
" 형태의 위의 명령어 2 내지 4를 형성하는 각각의 가산 명령어에서, Rn은 Add의 결과를 저장할 타깃 또는 결과 레지스터를 나타내며, Ry는 또한 레지스터 또는 소스 오퍼랜드를 나타낸다. 전술한 코드 세그먼트의 명령어 2는 제 1 태그로부터 제 2 태그를 발생하고 제 2 태그를 R2가 가리키는 메모리 위치에 배치하는 제 2 규칙을 트리거할 수 있다. 전술한 코드 세그먼트의 명령어 3은 제 2 태그로부터 제 3 태그를 더 발생하고 제 3 태그를 R3가 가리키는 메모리 위치에 배치하는 제 3 규칙을 트리거할 수 있다. 전술한 코드 세그먼트의 명령어 4는 제 3 태그로부터 제 4 태그를 더 발생하고 제 4 태그를 R4가 가리키는 메모리 위치에 배치하는 제 4 규칙을 트리거할 수 있다. 이러한 방식으로, 전술한 코드 세그먼트는 태그 값으로서 레지스터에 저장된 4 태그의 초기 세트를 발생하는데 사용될 수 있다. 전술한 일반적인 기술은 임의의 원하는 수의 초기 세트의 태그를 발생하는 유사한 방식으로 더 확장될 수 있다.
일반적으로, 적어도 하나의 실시예에서 초기 태그 세트를 발생할 때, 초기 세트 내의 특정 태그의 수는 미리 정의된 수일 수 있다. 각 특수 태그는 명령어를 실행할 때 트리거되는 상이한 고유 규칙의 결과로서 발생될 수 있다. 위의 코드 세그먼트와 같은 각 명령어는 캐시 미스를 초래할 수 있고 그래서 캐시 미스 핸들러가 실행되어 특정 명령어에 대한 규칙 출력의 일부로서 Rtag를 계산할 수 있으며, 여기서 Rtag는 초기 세트의 태그 중 하나이다. 위의 코드 세그먼트의 명령어와 유사한 방식으로, 상이한 코드 시퀀스가 상이한 시점에 실행되어 초기 세트의 태그 중 하나를 사용하여 다른 태그를 추가로 발생할 수 있다. 따라서, 초기 세트 내의 각 태그는 다른 태그 시퀀스를 추가로 발생하는데 사용되는 태그 발생기(tag generator)를 나타낼 수 있다. 전술한 예에서, Add 명령어는 태그의 다른 전체 시퀀스를 발생하는데 사용될 수 있는 다음 태그 발생기를 발생하는데 사용될 수 있다. 아래에서 논의되는 바와 같이, 초기 세트의 태그 발생기(다른 시퀀스를 발생하는 시작점으로 사용되는 추가의 태그 발생기 자체)는 다른 태그 시퀀스를 생성하는 발생기로서 더 이상 사용될 수 없는 정규 또는 비-생성 태그와 구별될 수 있다. 따라서, ADD와 같은 특정 명령어는 규칙 및 미스 처리를 트리거하여 태그 발생기들의 세트 또는 시퀀스를 발생하는데 사용될 수 있다. 이것은 시퀀스에서 비-발생 태그를 발생하는 규칙 및 미스 처리를 트리거할 수 있는 MOVE와 같은 다른 명령어와 대조될 수 있다. malloc과 같은 코드와 관련하여, ADD 명령어는 제 1 애플리케이션에 대해 상이한 컬러의 시퀀스를 발생하는데 사용되는 새로운 애플리케이션 태그 컬러 발생기를 발생하는데 유사하게 사용될 수 있다(예를 들면, 새로운 애플리케이션 태그 컬러 발생기는 특정 애플리케이션에 대해 상이한 컬러 RED-APP1, BLUE-APP1, GREEN-APP1 등의 시퀀스를 발생하는데 사용되는 APP1일 수 있다). 그러면 태깅된 ADD 명령어는 RED-APP1-gen, BLUE-APP1-gen 또는 GREEN-APP1-gen 중 하나와 같은 특정한 애플리케이션 특정 시퀀스에서 다음 태그를 획득하는데 사용될 수 있다. 그런 다음 태깅된 MOVE 명령어는 RED-APP1-gen, BLUE-APP1-gen 또는 GREEN-APP1-gen으로부터 실제 컬러 RED-APP1, BLUE-APP1 또는 GREAN-APP1을 각각 생성하는데 사용될 수 있다(여기서 RED-APP1, BLUE-APP1, GREEN-APP1은 추가 태그 시퀀스를 추가로 발생하는데 사용될 수 없다).
PUMP가 연계되는 동안 실행되는 부트스트랩 프로그램의 코드 세그먼트는 실행될 때 커널 코드/명령어에 태깅하고 부가적으로 다른 코드 모듈 또는 엔티티를 임의의 원하는 특수 명령어 태그로 태깅하여 이렇게 특수 태깅된 코드가 원하는 권한 또는 인가를 가질 수 있게 하는 규칙을 트리거하는 추가 코드를 또한 포함할 수 있다. 예를 들어, 코드 세그먼트는 로더 코드에 태깅하고 루틴 malloc 및 free의 코드를 권한 또는 인가를 확장하는 특수 명령어 태그로 태깅하여 이러한 코드가 권한 있는 태깅 동작을 수행하도록 하는 규칙을 트리거하는 명령어를 포함할 수 있다. 특수 코드 태그는 추가의 원하는 태그를 발생하고 또한 부가적인 코드 및/또는 데이터를 일반화된 태그로 적절하게 태깅하는 규칙을 트리거하는, 미리 결정된 코드 시퀀스/명령어 세트를 사용하는 위에서 언급한 것과 유사한 방식으로, 태그의 초기 세트로부터 발생될 수 있다.
적어도 하나의 실시예에서, 위에서 언급한 코드 세그먼트의 부분과 관련하여 부가적인 방책 또는 기술이 취해질 수 있다. 예를 들어, 초기 태그 세트를 생성하기 위해 사용된 위에서 언급한 4 명령어는 예컨대 본 명세서의 다른 곳(예(400)에 설명된 순차성(sequentiality) 및 원자성을 시행하는 "글루 (glue)" 정책의 규칙을 사용하여 제 1 명령어 시퀀스에 포함될 수 있다.
위에서 언급한 코드 세그먼트가 초기 태그 세트를 발생하고 커널 코드 및 임의의 다른 원하는 명령어를 추가로 특수 태깅하도록 실행된 후, 제어는 부가적인 부트 코드로 이전될 수 있다. RISC-V 아키텍처에 기초한 적어도 하나의 실시예에서, 부가적인 부트 코드는 하이퍼바이저 권한 레벨에서 실행될 수 있다. 이러한 부가적인 부트 코드는 예를 들어, PUMP에 초기 규칙 세트를 로딩하는 것을 트리거하는 명령어를 포함할 수 있다. 부팅이 완료되면, tagmode CSR에 의해 표시되는 PUMP 태그 모드는 사용자 권한 레벨에서 실행하는 것과 같은 사용자 코드와 관련하여 PUMP를 연계시키기에 적합한 레벨로 설정될 수 있다(예를 들어, 예(910)의 (911c)에서처럼 PUMP가 연계되고 U (사용자) 모드 또는 권한 레벨에서만 작동함을 나타내는 태그 모드로 설정된다).
도 72를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 수행될 수 있는 처리 단계의 흐름도가 도시된다. 흐름도(1600)는 전술한 처리를 요약한다. 단계(1602)에서, 태그 모드는 tagmode CSR이 예(910)의 (911a)와 관련하여 본 명세서의 다른 곳에서 설명된 바와 같이 PUMP 오프 상태를 나타내는 오프 상태로 설정된다. 단계(1604)에서, boottag CSR은 특수 부트스트랩 태그로 초기화된다. 단계(1606)에서, 부트스트랩 프로그램의 실행이 시작된다. 단계(1608)에서, 부트스트랩 프로그램은 defaultatg CSR을 디폴트 태그로 설정할 수 있다. 단계(1610)에서, tagmode CSR은 디폴트 태그를 모든 결과에 기입하는 모드로 수정될 수 있다(예를 들어, 이 태그 모드에 있는 동안 각 Rtag=디폴트 태그). 단계(1612)에서, 메모리 위치를 초기화하고 메모리 위치를 디폴트 태그로 태깅하는 규칙을 트리거하는 명령어가 실행될 수 있다. 단계(1614)에서, tagmode CSR은 단계(1616)에서 후속 코드 세그먼트의 실행 동안 PUMP를 연계시키는 모드로 변경될 수 있다. 단계(1616)에서, 후속 코드 세그먼트는 PUMP가 연계되어 실행된다. 코드 세그먼트는 초기 태그 세트를 발생하고, boottag CSR을 클리어하고, 커널 코드에 태깅하며, 부가적인 코드 부분을 특수 태그로 태깅하여 그렇게 태깅된 코드에게 원하는 것으로서 확장된 능력, 인가 및 권한을 제공하는 규칙을 트리거하는 명령어를 포함한다. 단계(1618)에서, 제어는 실행되는 부가적인 부트 코드로 이전될 수 있다. 부팅 프로세스가 완료될 때, 시스템은 이제 PUMP가 연계되고 사용자 코드 실행을 위한 작동 가능 상태로 사용자 코드를 실행할 준비가 된다.
이제 부트스트랩 태그로부터 태그를 발생하는 방법에 대해 보다 상세하게 설명된다. 부트스트랩 태그로 시작하는 태그 발생 처리는 태그 트리(tag tree) 또는 생명의 트리(tree of life)라고 불릴 수도 있다. 보다 일반적으로, 태그 발생 프로세스는 도 73의 예(1620)에 도시된 바와 같은 계층 구조를 형성한다.
예(1620)는 태그 발생 프로세스의 기원으로서 boottag(1621)를 도시한다. 요소(1621a 내지 1621d)는 예컨대 위에서 설명한 바와 같이 발생된 초기 태그 세트를 나타낼 수 있다. 이 예에서, 초기 태그 세트(1621a 내지 1621d)는 무한한 수의 특수 명령어 태그의 시퀀스(1622)를 더 발생하는데 사용되는 초기 OS 특수 명령어 태그(1621a)를 포함할 수 있으며, 이후 무한의 특수 명령어 태그는 (1623)에 적용되어 상이한 코드 또는 모듈(1624)의 명령어에 태깅할 수 있다. 초기 OS 특별 명령어 태그(1621a)로부터, 부가적인 태그(1622)가 태깅될 상이한 모듈에 대해 생성될 수 있다. 예를 들어, malloc에 대해 제 1 OS 특수 명령어 태그(1622a)가 발생되고 malloc에 적용되어(1623a), malloc의 명령어가 특수 명령어 태그(1622a)로 태깅된다(1624a). 이러한 방식으로, malloc 코드는 태그 발생기로서 malloc을 식별하는 (예를 들어, malloc 코드가 다른 새로운 태그를 더 발생하고 새로이 발생된 태그를 더 사용하여 다른 메모리 셀을 태깅하는 권한을 갖는 것을 나타내는) 특수 명령어 태그로 태깅될 수 있다.
malloc에 관한 이러한 예에서, (1621b)는 malloc의 인스턴스가 각각의 사용자 애플리케이션에 포함되어 있기 때문에 사용자 애플리케이션 당 하나씩 malloc 태그 발생기 애플리케이션 태그(1626)를 더 발생하는데 사용되는 초기 malloc 태그일 수 있다. 본 발명은 각 사용자 애플리케이션에 있는 그러한 각 malloc 인스턴스에 (1625)에 포함된 상이한 컬러화된 태그를 발생하는 권한을 부여하고자 한다.
일반적으로, 예(1620)는 특수 명령어 태그(1621a), Malloc(1621b), CFI(1621c) 및 Taint(162d)에 대한 초기 태그 세트(1621a 내지 1621d)를 도시한다. 따라서, (boottag(1621) 이외의) 제 1 행의 태그의 수직 표시에 있는 태그(1621a 내지 1621d) 각각은 무한 태그 시퀀스를 생성하기 위해 사용된 상이한 초기 태그를 나타낸다. 예를 들어, 값(1621a)은 무한한 수의 특수 명령어 태그(1622)를 더 도출하거나 발생하는데 사용된다. 값(1621b)은 무한한 수의 값(1626)을 더 도출하거나 발생하는데 사용된다. (1626)의 각각의 인스턴스는 각 애플리케이션에 대해 태그의 다른 무한 시퀀스의 발생기로서 더 사용될 수 있다. 예를 들어, (1626a)는 단일 애플리케이션 app1에 사용되는 서로 다른 컬러의 다른 무한 시퀀스 (1629)를 더 발생하는데 사용되는 발생기 값을 나타낸다. 유사한 방식으로, (1626)의 각각의 상이한 발생기 값은 각 애플리케이션에 대해 무한한 수의 컬러를 더 발생하기 위해 사용될 수 있다.
값(1621c)은 무한한 수의 값(1627)을 더 발생하는 발생기로서 사용될 수 있다. 요소(1627)는 특정 어플리케이션 또는 앱(app) N에 대해 CFI 태그 발생기 n이 발생할 때마다 다른 무한 시퀀스를 더 발생하는 권한 또는 기능을 나타낸다는 점에서 (1626)과 유사하다. 예를 들어, (1627a)는 단일 애플리케이션 app1에 사용되는 상이한 컬러의 다른 무한 시퀀스(1630)를 더 발생하는데 사용되는 발생기 값을 나타낸다. 유사한 방식으로, (1627)의 각각의 상이한 발생기 값은 각각의 애플리케이션에 대해 무한한 수의 컬러를 더 발생하기 위해 사용될 수 있다.
값(162d)은 무한한 수의 값(1628)을 더 발생하는 발생기로서 사용될 수 있다. 요소(1628)는 특정 애플리케이션 또는 앱 N에 대한 태그 발생기 n이 발생할 때마다 다른 무한 시퀀스를 더 발생하는 권한 또는 기능을 나타낸다. 예를 들어, (1628a)는 단일 애플리케이션 app1에 사용되는 상이한 컬러의 다른 무한 시퀀스(1631)을 더 발생하는데 사용되는 발생기 값을 나타낸다. 유사한 방식으로, 각각의 상이한 발생기 값(1628)은 각각의 애플리케이션에 대해 무한한 수의 컬러를 더 발생하는데 사용될 수 있다.
도시된 바와 같이, (1621c 내지 1621d)로부터 각각 유래하는 CFI 및 Taint의 시퀀스 또는 서브트리는 (1621b)로부터 시작하는 Malloc 서브트리와 유사하다. 예(1620)에서, nxtTag 또는 TInxtTag는 발생된 무한 시퀀스의 다음 요소를 나타내는데 사용되며, getTag는 시퀀스 멤버로부터 다음 태그를 추출하는데 사용된다. 일반적으로, getTag는 태그 발생기가 아닌, 사용할 태그 자체를 추출하는 것을 나타내는데 사용될 수 있다. 사용 가능한 태그가 특정 코드 부분에 제공되어 사용할 것으로 예정되어 있으면, 본 발명은 코드 부분에 태그를 발생하는 기능을 또한 부여하기를 원하지 않는다. 예를 들면, 각 애플리케이션에 그 애플리케이션을 위한 Malloc 태그 발생기(예를 들어, App1ColorTagX)를 제공하기를 원하지만, 애플리케이션에 다른 애플리케이션을 위한 Malloc 태그 발생기를 발생하는 기능을 제공하기를 원하지 않는다. 그래서, getTag는 타입을 발생기에서 인스턴스로 변경한다. nxtTag와 TInxtTag의 차이점은 nxtTag가 "태깅된 명령어" 없이도 사용 가능하지만, TInxtTag는 적합하게 태깅된 명령어에 의해서만 사용 가능한 것이다.
Malloc 애플리케이션 태그(Malloc Application Tag) 시퀀스(1626)는 오퍼레이팅 시스템 또는 로더가 각 애플리케이션의 컬러 태그 발생기를 발생할 수 있게 한다. 예를 들어, 요소(1626a)는 애플리케이션 컬러 시퀀스(1629)의 태그를 발생하는데 사용되는 애플리케이션-특정 컬러 태그 발생기 값을 나타낸다. 애플리케이션 내에서, AppYColorTag 시퀀스(1629)는 malloc이 각 컬러에 대한 권한을 발생하게 한다. 그 컬러 권한은: 할당된 메모리에 대해 셀을 컬러화하고, 할당을 위한 포인터를 컬러화하고 (예를 들어, free가 호출될 때) 그 컬러의 셀을 프리로 만드는데 사용될 수 있다. 예컨대 malloc 및 free를 이용한 컬러의 사용은 본 명세서의 다른 부분에서 설명된다.
이러한 방식으로, 상이한 태그는 상이한 용도로 예약될 수 있다. 위에서 언급한 바와 같이 초기에 태깅된 커널 명령어로부터, 다른 코드 부분을 상이한 능력 또는 인가로 더 태깅하는 커널 코드가 실행될 수 있다. 예를 들어, 오퍼레이팅 시스템의 커널 코드는 로더에게 다른 코드 및 데이터를 더 태깅하고, 부가적인 태그 발생기를 발생하는 등의 기능을 부여하는 것과 같이, 로더와 같은 다른 코드 엔티티를 특수 권한으로 더 태깅할 수 있다. 로더는 malloc을 포함하는 사용자 프로그램을 로딩할 때 malloc 코드를 특수 명령어 태그(들)로 더 태깅하여 이를 상이한 메모리 영역을 컬러화하는데 사용되는 다른 태그를 더 발생하는 능력을 제공하는 malloc 코드로서 표시할 수 있다. 따라서 로더의 코드에 배치되는 특정 명령어 태그는 로더에게 한 세트의 권한을 제공한다. malloc 코드상에 제 2 상이한 명령어 태그를 배치하면 malloc 코드에 상이한 권한 세트가 제공된다. 일반적으로, 시퀀스의 태그 발생을 수행할 때, 시퀀스 내의 현재 태그는 시퀀스 내의 다음 태그를 발생하는 것과 관련하여 참조되고 사용되는 상태 정보로서 저장된다. 본 명세서에 설명된 바와 같이, 시퀀스 내의 현재 태그에 관한 이러한 상태 정보는 저장되어 메타데이터 처리 도메인에서 사용될 수 있다. 현재의 태그, 또는 보다 일반적으로는 메타데이터 처리 상태 정보는 규칙 처리 및 캐시 미스 처리의 결과로서 저장되고 복원될 수 있다. 특정 애플리케이션에 사용하기 위해 할당된 마지막 컬러와 같은 시퀀스 내의 현재 태그는 시퀀스의 현재 상태로서 지정된 메모리 위치상의 태그로서 저장될 수 있다. 애플리케이션의 새로운 다음 컬러가 할당되어야 할 때, malloc의 코드는 애플리케이션에 대해 마지막으로 할당된 컬러를 검색하는 규칙을 트리거하고 마지막 할당된 컬러를 사용하여 애플리케이션-특정 컬러 시퀀스의 다음 컬러를 결정한다. 일반적으로, 태그의 고유한 시퀀스를 발생하는 것은 다음과 같은 것을 수행하는 규칙을 트리거하는 명령어의 실행을 포함할 수 있다:
1. 원자(예를 들어, 레지스터, 메모리 위치)의 태그 부분에 시퀀스 상태를 저장/보관;
2. 보관된/저장된 시퀀스 상태를 사용하여 시퀀스의 다음 태그를 발생하는 규칙을 트리거하는 명령어를 실행; 및
3. 다음 태그가 지금 시퀀스의 업데이트된 현재 상태인 원자의 태그 부분에 (2로부터 생성된) 시퀀스의 다음 태그를 저장/보관.
예(1620)를 다시 참조하면, 로더는 malloc을 사용하여 각 애플리케이션에 대해 (1626)의 malloc 태그 발생기 어플리케이션 태그 중의 특정한 하나의 태그를 할당할 수 있다. 로더는 예를 들어, (1626a)와 같은 다음 malloc 태그 발생기 태그를 발생하는 규칙을 트리거하는 코드를 실행한 다음, 메모리 위치에 태깅함으로써 이 태그를 상태 정보로서 저장할 수 있다. 후속하여, 애플리케이션에 의한 malloc에게 첫 호출 시, 규칙을 트리거하는 malloc 코드가 실행되어, 보관된 malloc 태그 발생기 태그를 검색하고, 보관된 태그를 사용하여 애플리케이션의 제 1 컬러를 발생한 다음, 저장된 상태를 업데이트하여 제 1 컬러를 애플리케이션에 대해 생성된 마지막 또는 최신 컬러로 저장할 수 있다. 애플리케이션에 의한 malloc에게 두 번째 호출에서, 규칙을 트리거하는 malloc 코드가 실행되어, 이전에 보관된 제 1 컬러를 검색하고, 보관된 제 1 컬러를 사용하여 애플리케이션의 제 2 컬러를 발생한 다음, 보관된 상태 정보를 업데이트하여 이제 제 2 컬러를 애플리케이션에 대해 발생된 마지막 또는 최신 컬러로서 저장할 수 있다. 유사한 방식으로, malloc으로의 다른 후속 호출은 애플리케이션에 대해 보관된 상태 정보(예를 들어, 가장 최근에 할당된 컬러)에 기초하여 추가의 컬러를 할당하는 다른 규칙을 트리거할 수 있다.
이제 본 명세서에서의 기술에 따른 실시예에 포함될 수 있는 직접 메모리 액세스(direct memory access)(DMA) 아키텍처의 양태가 설명될 것이다. 일반적으로 다음 단락에서는 태깅되지 않은 데이터를 사용하는 제 1 인터커넥트 패브릭에 연결된 신뢰성 없는 디바이스와 같은 소스에서 발급된 DMA를 중재하여 태깅된 데이터를 사용하는 제 2 인터커넥트 패브릭의 메모리에 저장된 데이터에 액세스하는 I/O PUMP의 쓰임새가 설명된다.
도 74를 참조하면, 본 명세서에 설명된 실시예에 포함될 수 있는 컴포넌트의 예가 도시된다. 예(1500)는 본 명세서의 다른 곳에서 설명된 예(700) 및 다른 예(예를 들어, 도 57 내지 도 60)의 컴포넌트와 유사한 번호를 가진 컴포넌트를 포함한다. 또한, 예(1500)는 I/O PUMP(1502) 및 추가의 액터(actor), 즉 메모리(712c)에 저장된 데이터에 액세스하려는 DMA 요청을 발행할 수 있는 DMA 요청 소스 또는 개시자(initiator)(1504a 내지 1504c)를 포함한다. 예(1500)는 태깅되지 않은 패브릭(715)에 연결된 이더넷 DMA 디바이스 A(1504a), 이더넷 DMA 디바이스 B(1504b) 및 UART(universal asynchronous receiver/transmitter)(범용 비동기 수신기/송신기) 또는 직렬 통신 디바이스(1504c)를 포함한다. 데이터를 판독 또는 기입하려는 DMA 요청은 디바이스(1504a 내지 1504c) 중 하나로부터 유래될 수 있다. 이 요청은 DMA 요청이 허용되는지를 결정하는 처리를 수행하는 I/O PUMP(1502)로 전달되고, 만약 허용된다면, 요청이 진행될 수 있게 한다. 따라서, I/O PUMP(1502)는 태깅되지 않은 패브릭(715)을 통해 수신된 DMA 요청을 중재하는 것으로 특징 지을 수 있고, 이에 따라 일반적인 가정은 이러한 DMA 요청을 발행하는 (715)에 연결된 디바이스는 신뢰성 없을 수 있다는 것이다.
적어도 하나의 실시예에서, I/O PUMP(1502)는 본 명세서에 설명된 바와 같은 PUMP의 인스턴스화(예를 들어, 도 22)일 수 있고, 차이점은 시행된 규칙이 메모리(1712c)로의 DMA 액세스를 제어하는 DMA 정책의 규칙이라는 점이다. 전술한 I/O PUMP(1502)의 사용은 메모리 동작을 포함하는 모든 명령어가 규칙에 의해 중재되는 것임을 확인하는 일반적인 아키텍처와 일치한다. 자율 DMA 디바이스(1504a 내지 1504c)가 메모리로의 직접적이고 중재되지 않은 액세스를 허용한다면, DMA 디바이스(1504a 내지 1504c)는 규칙이 시행하는 불변성 및 안전 특성을 훼손할 수 있다. 결과적으로, DMA를 허용하기 위해, 본 명세서에서의 기술에 따른 실시예는 또한 메모리(712c)로의 DMA 액세스에 관한 규칙을 시행할 수 있다. 프로세서 명령어에 대한 규칙을 시행하는 PUMP와 유사하게, I/O PUMP(1502)는 (1504a 내지 1504c)와 같은 DMA 디바이스에서 메모리 로드 및 스토어에 필요한 규칙을 시행한다. 일반적으로, I/O PUMP는 모든 로드 및 스토어를 중재한다. RISC-V 아키텍처에 기초하여 본 명세서에 설명된 적어도 하나의 실시예에서, I/O PUMP는 CSR을 사용하고 RISC-V 아키텍처에서 사용되는 PUMP와 관련하여 본 명세서의 다른 곳에서 설명된 것과 유사한 방식으로 규칙 캐시 미스 처리를 수행한다. I/O PUMP(1502)는 PUMP와 유사한 한 세트의 CSR을 갖지만, 메모리 매핑된 어드레스를 통해 이들에게 액세스한다. 예컨대 예(1520)와 관련하여 다음 단락에서 설명되는 I/O PUMP CSR로의 액세스는 규칙을 사용하여 보호되는 태그일 수도 있다. I/O PUMP에서 규칙을 찾으려 시도할 때 만나게 되는 규칙 캐시 미스는 인터럽트가 프로세서 RISC-V CPU(702)에 의해 서비스되도록 트리거할 수 있다. I/O PUMP는 프로세서(702)와 동일한 규칙 해결 프로세스를 사용하지만, 메모리(712c) 내의 데이터에 액세스하려는 DMA로드 및 스토어에 대한 규칙만을 포함하는 단일 DMA 정책이 존재한다. I/O PUMP는 원자적으로 메모리(712c)에 기입한다(예를 들어, 태그 및 값을 단일 원자 동작으로 기입한다). 그러나, 일부 실시예에서, Mtag를 판독하는 것부터 Mtag을 기입하는 것까지의 (예를 들어, 태그 체크를 수행하거나 입증하고 기입하는 처리까지의) 완전한 프로세스는 표준 스토어와 원자적으로 함께 사용하지 않을 수 있다.
I/O PUMP(1502)는 SDMP를 위한 규칙 캐시이다. I/O PUMP는 DMA 동작에 연루되는 태그 세트와 동작 결과 사이의 매핑을 제공한다. 적어도 하나의 실시예에서, I/O PUMP는 프로세서(702)와 독립적으로 실행된다. I/O PUMP(1502)는 캐시이기 때문에, 이전에 입력 세트를 본 적이 없을 때(강제적) 또는 규칙에다 보유할 수 없을 때(용량 또는 아마도 충돌), 미스를 발생할 것이다. 이것은 본 명세서에서 PUMP에 대해 설명된 바와 같이 규칙 캐시 미스와 유사한 방식으로 I/O PUMP와 관련된 규칙 캐시 미스를 발생한다. I/O PUMP 규칙 캐시(1502)에 관련한 미스는 - 서비스 프로세서(702)가 트랩을 놓치는 것과 동일한 - 규칙 캐시 미스 핸들러 시스템에 의해 소프트웨어에서 처리되는 인터럽트를 발생시킨다. I/O PUMP(1502)에 관련한 규칙 미스 시, 입력은 아래(예를 들어, 예(1520))에서 설명되는 I/OPUMP CSR을 통해 (예컨대 메타데이터 처리 도메인의 프로세서(702)의 코드상에서 실행되는) 미스 핸들러에 전달되고, 규칙 삽입은 CSR을 통해 I/O PUMP에 다시 제공된다. I/OPUMP 미스는 I/O PUMP가 프로세서(702)에 의해 서비스될 때까지 디스에이블되게 한다. 적어도 하나의 실시예에서, I/O PUMP의 디스에이블 상태는 I/O PUMP가 중재하는 모든 DMA 이전이 I/O PUMP 미스가 서비스될 때까지 기능 중지된다는 것을 의미한다.
본 명세서의 다른 부분에서의 PUMP와의 논의와 일관하여, I/O PUMP 입력은 opgroup(opgrp), DMA 명령 및 그의 오퍼랜드에 대한 태그(예를 들어, PCtag, CI tag, OP1 tag, OP2 tag, Mtag(본 명세서에서 때로는 MRtag라고도 지칭함)를 포함한다. I/O PUMP 출력은 본 출원에서 설명된 바와 같이 Rtag 및 PCnew 태그(다음 명령어의 PC에 대한 태그)를 포함할 수 있다. I/O PUMP와 관련하여, 이러한 입력 및 출력은 일 실시예에서 아래와 같은 다른 의미와 값을 가질 수 있다.
다음의 것은 일 실시예에서 I/O PUMP 입력이다:
1. Opgrp - 현재 두 가지가 있다: 로드 및 스토어
2. PCTag - DMA I/O 디바이스의 상태(코드에 대한 PCtag와 유사함)
3. CItag - DMA IO 디바이스를 식별하는 태그(지정된 코드 영역의 명령어 태그와 유사)
4. OP1tag - 항상 "공개적, 신뢰성 없음"으로 가정 (IOPUMP 캐시에는 물리적으로 표현되지 않지만 규칙에는 사용됨)
5. OP2tag - OP1tag와 동일함
6. Mtag - DMA 동작으로의 메모리 입력상의 태그
7. byteenable - 어느 바이트가 판독/기입 중인가?
다음의 것은 일 실시예에서 I/O PUMP 출력이다:
8. Rtag - 스토어에 대한 메모리 결과상의 태그
10. PCnew 태그 - 이 동작 이후 DMA I/O 디바이스의 상태
I/O PUMP에서, 프로그래머블 opgroup 매핑 테이블이 없을 수 있다(예를 들어, 예(420)). 오히려, I/O PUMP가 규칙을 찾기 위해 사용하는 opgroup은 DMA로드 및 DMA 스토어 동작을 위한 단일 opgroup을 나타내는 고정된 opcode일 수 있다. 적어도 하나의 실시예에서, I/O PUMP를 위한 케어 마스킹(care masking)은 없다.
예컨대 도 22에서 본 명세서에 설명된 바와 같이 PUMP와 관련하여 규칙 캐시 미스가 있을 때, 프로세서(702)는 대응하는 규칙이 PUMP 규칙 캐시에 삽입된 후 미스를 야기했던 명령어를 자동으로 재발행할 것으로 예상될 수 있다. 결과적으로, 규칙 삽입은 간단히 규칙을 PUMP 캐시에 배치하고 태깅된 결과를 얻기 위해 명령어를 다시 발행할 것으로 기대한다. 그러나 DMA 동작에 따른 거동은 이전과 다르다. DMA 동작은 인터럽트되고 재시도 동작을 필요로 할 것으로 예상되지 않는다. 이러한 DMA 동작을 지원하기 위해, I/O PUMP에 대한 규칙 삽입은 상이하게 처리될 수 있다. 특히, 일단 미스로 인해 I/O PUMP가 결함을 일으켰다면, 처리는 보류중인 DMA 동작을 보유하고 프로세서(702)를 대기시켜 (예를 들어, 새로운 규칙에 대한 출력 태그 Rtag 및 PCnew tag를 계산하기 위해 규칙 미스 처리를 수행함) 규칙에 대해 미싱 출력 태그를 공급한다(허용될 것으로 가정한다). 출력이 공급될 때, IOPUMP 내로 규칙 기입을 트리거하는 것 외에도, 출력은 마치 I/O PUMP에서 온 것처럼 (예를 들어, 아래의 예(1540)과 관련하여 설명되는) DMA 파이프라인에 포워딩되고, 그래서 I/O PUMP에 동작을 강제로 재 발행되게 하지 않고 동작은 계속될 수 있다. 규칙 위반은 지정된 disenabled-DMA-device 태그를 업데이트된 PCtag, PCnew tag에 제공함으로써 처리될 수 있으며, 이는 동작이 허용되지 않으며 PCtag가 리셋될 때까지 그 특정 DMA 디바이스(1504a 내지 1504c)로부터 더 이상의 DMA 동작이 허용되지 않을 것이라고 신호로 알려줄 것이다. 일반적으로, DMA 동작 또는 DMA 요청을 발행하는 특정 DMA 디바이스, 예컨대 (1504a 내지 1504c) 중 하나의 DMA 디바이스에 대한 디바이스 태그는 발행하는 DMA 디바이스(예를 들어, DMA 요청의 소스)를 고유하게 식별하는 CI의 특정 값 및 PC 태그 DMA 디바이스의 현재 상태를 나타내는 PC 태그의 특정 값일 수 있다. 적어도 하나의 실시예에서, PC 태그는 CI 태그에 의해 식별된 특정 DMA 디바이스로부터의 DMA 요청의 추가 처리를 디스에이블하는 시점에서 특정 값으로 설정될 수 있다.
도 75를 참조하면, 본 명세서에서의 기술에 따른 실시예에서 I/O PUMP에 의해 사용될 수 있는 CSR의 테이블이 도시된다. 테이블(1520)은 어드레스 열(1524)(CSR의 메모리 매핑된 어드레스를 표시함), 이름 열(1526) 및 설명 열(1528)을 포함한다. 테이블(1520)의 각 행은 I/O PUMP에 의해 사용되는 정의된 CSR 중 하나에 대응한다. 행(1522a)은 CSR 트랜잭션 id가 어드레스 0x00를 가지고 있음을 나타낸다. 트랜잭션 id CSR로의 기입은 (예를 들어, 프리페치하기 위해) 저장된 현재 트랜잭션 id를 증분하고, 트랜잭션 id CSR으로부터의 판독은 트랜잭션 id CSR에 저장된 현재 트랜잭션 id를 리턴한다. 행(1522b)는 CSR opgrp가 0x01 어드레스를 가지고 있음을 나타낸다. opgrp CSR은 현재 DMA 명령어에 대한 opgroup을 포함하며 규칙 미스 시 규칙 미스 핸들러로의 입력으로서 사용된다. 행(1522c)은 CSR byteenable이 어드레스 0x02를 가지고 있음을 나타낸다. byteenable CSR은 워드의 어느 바이트가 DMA 동작에 영향을 미치고 규칙 미스 시 규칙 미스 핸들러로의 입력으로서 사용된다는 것을 나타낸다. 본 명세서에서의 다른 논의와 일관하여, 이것은 정책이 바이트 레벨 보호를 제공할 수 있게 하고; 트리거된 규칙은 DMA 요청된 데이터의 바이트가 예컨대 상이한 DMA 디바이스에 액세스 가능한 메모리 부분을 특수하게 태깅함으로써 그 요청을 개시하는 특정 DMA 디바이스에 의해 액세스되도록 허용되는지를 체크할 수 있다. 행(1522d)은 CSR pctag가 어드레스 0x03을 가지고 있음을 나타낸다. pctag CSR은 현재 DMA 명령어에 대한 PC 태그를 포함하며 규칙 미스 시 규칙 미스 핸들러로의 입력으로서 사용된다. 행(1522e)는 CSR citag가 어드레스 0x04를 가지고 있음을 나타낸다. citag CSR는 현재 DMA 명령어에 대한 CI 태그가 포함되어 있으며 규칙 미스 시 규칙 미스 핸들러로의 입력으로서 사용된다. 행(1522f)은 CSR mtag가 어드레스 0x07을 가지고 있음을 나타낸다. mtag CSR은 현재 DMA 명령어에 대한 M 태그를 포함하며 규칙 미스 시 규칙 미스 핸들러로의 입력으로서 사용된다. 행(1522g)은 CSR newpctag가 어드레스 0x08를 가지고 있음을 나타낸다. newpctag CSR은 현재 DMA 명령어의 완료(예를 들어, PUMP 및 캐시 미스 처리의 출력) 이후에 PC 상에 배치되는 PC new tag를 포함한다. 행(1522h)은 CSR rtag가 어드레스 0x09를 가지고 있음을 나타낸다. rtag CSR은 현재 DMA 명령어의 메모리 결과(예를 들어, PUMP 및 캐시 미스 처리의 출력) 상에 배치되는 태그를 포함한다. 행(1522i)은 CSR 커밋이 어드레스 0x0A를 가지고 있음을 나타낸다. 커밋 CSR에 기입하는 것은 커밋 CSR에 기입된 값과 (트랜잭션 id CSR에 저장된) 현재 트랜잭션 id을 비교하게 한다. 전술한 두 개가 매칭하면, 매칭은 I/O PUMP로의 규칙의 기입을 트리거한다. 기입된 규칙은 현재 DMA 명령어에 대한 opcode 및 (미스 처리에 의해 결정된 것으로서) 태그 입력 및 출력을 포함한다. 행(1522j)은 CSR 상태가 어드레스 0x0E를 가지고 있음을 나타낸다. 상태 CSR는 I/O PUMP의 상태를 나타내는 값을 포함한다. 예를 들어, 본 명세서에 설명된 바와 같은 일 실시예에서, 상태 CSR는 I/O PUMP가 인에이블 또는 디스에이블되는지를 나타낼 수 있다. 이것은 본 명세서의 다른 곳에서 설명된 바와 같이 PUMP I/O 규칙 캐시 미스의 경우에는 디스에이블될 수 있다. 행(1522k)은 CSR 플러시가 0x0F 어드레스를 갖는다는 것을 나타낸다. flush CSR은 기입될 때, I/O PUMP의 플러시를 트리거한다(예를 들어, I/O PUMP 캐시로부터의 규칙을 플러시하거나 클리어한다).
적어도 하나의 실시예에서, 상태 CSR의 비트 0이 1이면, 이는 I/O PUMP가 디스에이블됨을 의미하고, 그렇지 않고 비트 0이 0의 값을 갖는다면, I/O PUMP가 디스에이블됨을 의미한다. PUMP I/O 미스는 pump를 디스에이블한다. 상태 CSR의 비트1은 PUMP가 결함을 일으켰고 서비스를 대기 중인지를 나타낸다(예를 들어, Bit1=1은 I/O PUMP 결함/캐시 미스 및 서비스 대기 중임을 의미한다). 상태 CSR의 비트2는 I/O PUMP 규칙 미스가 현재 규칙 캐시 미스 핸들러에 의해 해결되고 있는지를 나타내며, 트랜잭션 id가 매칭하면, 삽입된 결과를 계류중인 미스 동작으로 직접 제공할 것이다. 상태 CSR의 전술한 모든 비트는 커밋 동작(성공 또는 실패)에 의해 리셋된다(예를 들어, bit 0=인에이블됨, bit 1=결함 없음, bit 2=계류중인 미스 없음). 상태 CSR에 기입하는 것은 예를 들어, 스타트업 때 초기에 I/O PUMP를 인에이블하기 위해 필요한 것으로서, 전술한 비트들을 리셋하기 위해서도 또한 수행될 수 있다. 실패한 기입에 대해 상태 CSR의 리셋은 DMA 디바이스가 동작을 재 시도하고 결함을 다시 트리거할 수 있게 한다.
프로세서(702)에 의한 I/O PUMP CSR로의 로드/스토어 메모리 동작은 iopump CI 태그로 태깅되어야 한다. iopump CI 태그를 가진 명령어로의 동작을 제한하는 정책 규칙이 적소에 있어야 한다. 개별 I/O PUMP CSR에는 태그가 없다.
태깅되지 않은 또는 신뢰성 없는 패브릭(715) 상의 각각의 디바이스(1504a 내지 1504c)는 프로세서가 디바이스에 로드 또는 스토어를 수행할 때 디바이스 태그로서 제시되는 자신의 태그로 구성될 수 있다(예를 들어, 디바이스 태그가 아래에 설명된 그리고 특정 디바이스가 DMA로드 또는 스토어를 수행할 때 CI 태그로서 특정된 레지스터 파일에 저장된 경우의 (1534b) 참조). 이로써 어떤 코드와 인가가 어떤 디바이스에 직접 액세스할 수 있는지에 대한 미세-세밀화된 제어가 가능하다. 디바이스로의 모든 로드 및 스토어 디바이스에 동일한 태그가 제공되며, 그 태그는 로드 및 스토어 동작에 따라 변경되지 않는다. 각각의 디바이스(1504a 내지 1504c)와 연관되고 식별하는 특정 디바이스 태그는 디바이스 레지스터 파일에 저장될 수 있다. 디바이스(1504a 내지 1504c)에 대해 특정된 특정 디바이스 태그는 디바이스 레지스터 파일을 수정함으로써만 변경될 수 있다. 디바이스 레지스터 파일은 각 디바이스(1504a 내지 1504c)에 대해 고유 타깃 디바이스 id (태깅되지 않은 또는 신뢰성 없는 패브릭(715)상의 디바이스를 식별하는데 사용됨) 및 고유 타깃 디바이스 id 에 대한 타깃 디바이스 특정 태그를 나타낼 수 있다. 적어도 하나의 실시예에서, 디바이스 레지스터 파일 자체는 자체 디바이스 태그를 사용하여 신뢰성 없는 패브릭(715)상의 디바이스로서 액세스될 수 있다. 디바이스 레지스터 파일의 사용을 부트스트랩하기 위해, (디바이스 레지스터 파일에 저장된) 디바이스 태그 레지스터 파일의 자체 태그는 스타트업 동안 PUMP가 인에이블되기 전에 파일에 기입될 수 있다. 예를 들어, 디바이스 태그 레지스터 파일의 자체 태그는 PUMP가 오프(예를 들어, 예(910)의 (911a)에 의해 표시되는 tagmode) 동안 부트 처리의 일부로서 파일에 기입될 수 있다. 명령어의 CI 태그는 로드 또는 스토어 명령어를 수행하는 DMA 타깃 디바이스의 타깃 ID를 식별할 수 있으며, 위의 명령어에서 CI 태그는 그러한 로드 및 스토어 동작에 의해 트리거된 규칙에서 사용되어 특정된 DMA 디바이스에 의한 특정 로드 또는 스토어 동작을 제한(예를 들어, 허용 또는 허용하지 않음)할 수 있다. 또한, 특정 DMA 디바이스가 허용되지 않는 로드 및/또는 스토어 동작을 수행하면, 특정 DMA 디바이스와 연관된 상태는 디스에이블되도록 수정되어, 더 이상의 요청(예를 들어, DMA로드 및 스토어)이 무시되도록 한다.
위에서 언급한 바와 같이, DMA 요청 또는 명령어를 개시하거나 그 소스인 DMA 디바이스는 DMA 디바이스의 PCtag에 의해 지시되는 연관된 상태를 가질 수 있다. 특히, 고유한 PCtag는 (CI 태그에 의해 식별된) DMA 디바이스로부터 허용되는 DMA 동작에 대해 디스에이블된 상태를 나타내기 위해 사용될 수 있다. 디스에이블된 개시자는 아래(예를 들어, 예(1530 및 1540))에서 설명되는 DMA 또는 트러스트브릿지(Trustbridge) 파이프라인의 시작 시 자신의 DMA 요청을 거절할 수 있다.
실시예는 모든 DMA 트래픽, DMA 엔진 당 I/O PUMP, 또는 다수의 DMA 엔진에 대해 DMA 트래픽을 중재하는 다수의 I/O PUMP를 중재하는 단일 I/O PUMP를 가질 수 있다는 것을 알아야 한다. 예(1510)에는 단일 DMA 엔진(예를 들어, 단일 메모리(712c))에 대한 단일 I/O PUMP가 도시된다. 예(1500)에서와 같이 단일 I/O PUMP의 사용은 병목이 될 수 있으며, 따라서 실시예는 다수의 I/O PUMP가 I/O 트래픽을 중재하도록 선택할 수 있다. 다수의 I/O PUMP가 존재하는 그러한 실시예에서, 각각은 독립적으로 인에이블 또는 디스에이블될 수 있으므로, 다수의 I/O PUMP 중 하나 이상의 제 1 부분이 (I/O PUMP 미스로 인해) 디스에이블될 수 있을지라도, 다중 I/O PUMP의 나머지 제 2 부분은 디스에이블되어 DMA 요청을 계속 서비스할 수 있다.
적어도 하나의 실시예에서, DMA 동작의 개시자 또는 소스로서 작용하는 상이한 DMA 디바이스는 각각 메모리(712c)의 특정된 부분에만 액세스하도록 허용될 수 있다. DMA를 통해 액세스 가능한 메모리(712c)의 상이한 부분은 개별 태그로 각각 태깅될 수 있다. 예를 들어, 디바이스(1504a)는 메모리(712c)의 제 1 어드레스 범위에 액세스할 수 있고 디바이스(1504b)는 메모리(712c)의 다른 제 2 어드레스 범위에 액세스할 수 있다. 제 1 범위에 대응하는 메모리 위치(712c)는 제 1 태그로 태깅될 수 있고, 제 2 범위에 대응하는 메모리 위치(712c)는 제 2 태그로 태깅될 수 있다. 이러한 방식으로, 제 1 범위 내의 메모리 위치에 디바이스(1504a)의 액세스를 시행하거나 제한하고 제 2 범위 내의 메모리 위치에 디바이스(1504b)의 액세스를 시행하거나 제한하는 규칙이 사용될 수 있다. 변형예로서, 상이한 태그가 허용된 액세스의 유형(예를 들어, 판독 전용, 기입 전용 판독 및 기입)과 연관될 수 있다. 유사한 방식으로, 동일한 메모리(712c)를 액세스하는 다수의 DMA 엔진을 갖는 실시예에서, DMA 엔진 각각에 독점적으로 액세스 가능한 단일 메모리(712c)의 상이한 부분은 고유하게 태깅될 수 있고, 그에 따라 규칙은 메모리 위치의 특정된 어드레스 범위에 각 DMA 엔진의 액세스를 시행하고 제한한다.
도 76을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 신뢰성 있는 패브릭(1532)(예를 들어, 태깅된 인터커넥트 패브릭(710)에 대응함)과 신뢰성 없는 패브릭(1536)(예를 들어, 태깅되지 않은 인터커넥트 패브릭(715)에 대응함) 사이의 데이터 흐름을 도시하는 예가 도시된다. 요소(1534)는 일반적으로 (1532)와 (1536) 사이의 DMA 중재와 관련하여 I/O PUMP(1534a)에 의해 수행되는 처리를 나타낸다. 요소(1534)는 DMA 중재의 일부로서 DMA 동작을 입증하고 서비스하기 위해 수행되는 트러스트 브리지 또는 DMA 파이프라인(1534c)을 나타낼 수 있다. 요소(1538a)는 신뢰성 없는 패브릭(1536)으로부터 (예를 들어, 예컨대 예(1500)의 DMA 디바이스(1504a 내지 1504c)까지의) 출력 채널을 나타낼 수 있다. 요소(1538b)는 (예를 들어, 디바이스(1504a 내지 1504c) 중 하나로부터) 신뢰성 없는 패브릭(1536)으로의 입력 채널을 나타낼 수 있다. 일반적으로, I/O PUMP(1534a)는 DMA 판독 및 기입 동작 동안 판독 요청을 발행하여 타깃 메모리상의 태그가 요청된 DMA 액세스를 허용하는 것을 입증할 필요가 있다. I/O PUMP는 (아래의 예(1540)에서 처리 스테이지 사이에서 설명되는 바와 같이) 요청을 버퍼링하고 태깅된 통신 동작의 마스터 제어를 수행해야 할 것이다.
요소(1537)는 예(1520)에 설명된 바와 같이 I/O PUMP CSR을 로드(또는 검색)하는 입력으로서 제공된 값을 나타낸다. 또한, 상이한 DMA 디바이스 개시자의 디바이스 상태 정보는 PCtag(예를 들어, 이 DMA 디바이스로부터의 요청이 디스에이블되는지와 같은 DMA 디바이스의 상태) 및 (예를 들어, 신뢰성 없는 패브릭(715)상의 (1504a 내지 1504c)와 같은) DMA 디바이스 개시자의 CItag(예를 들어, DMA 디바이스의 고유 식별자)를 포함하는 신뢰성 없는 패브릭 디바이스 레지스터 파일(1534b)에 저장될 수 있다. DMA로드 또는 스토어를 수행하는 특정 DMA 디바이스에 대한 디바이스 레지스터 파일(1534b)의 엔트리는 현재 DMA로드 또는 스토어에 대한 CItag 및 PCtag 값을 제공할 수 있다. 요소(1535a)는 (1534)의 (1534)의 중재된 DMA 처리 요청을 만들어 주는 신뢰성 없는 패브릭(1536)상의 디바이스에 대해 사용된 채널을 표시한다. 요소(1535b)는 신뢰성 없는 패브릭(1536)으로의 (1534)의 중재된 DMA 요청의 결과를 리턴하는데 사용되는 채널을 나타낼 수 있다.
요소(1531a 내지 1531b)는 신뢰성 없는 패브릭(1536)로부터 ((1534)의 DMA 중재 처리를 통해) 신뢰성 있는 패브릭(1532)으로 DMA 요청을 포워딩하기 위한 채널을 나타낸다. 특히, 채널(1531a)은 초기 태그 판독된 (입증되지 않은) DMA 요청을 신뢰성 있는 패브릭(1532)로 포워딩하기 위한 채널이고, 채널(1531b)은 업데이트된 태그를 사용하여 데이터의 최종 기입을 포워딩하기 위한 제 2 채널이다. 두 개의 채널을 사용하는 것은 예(1540)와 관련하여 아래에서 설명되는 DMA 또는 트러스트브릿지 파이프라인에 관한 더 이상의 논의를 고려해볼 때 더 명백해질 수 있다. 요소(1531c)는 DMA 중재 처리(1534)를 통해 신뢰성 있는 패브릭(1531c)으로부터 신뢰성 없는 패브릭으로의 채널을 나타낸다.
일 실시예에서, 요소(1534)는 도 77의 예(1540)에 도시된 바와 같이 DMA 처리 파이프라인을 나타낼 수 있다. 예(1540)은 신뢰성 없는 또는 태깅되지 않은 패브릭(예를 들어, 예(1500)의 (1506), 예(1530)의 (1536))으로부터 DMA 디바이스(1504a 내지 1504c)에 의해 수행된 DMA 동작을 서비스하기 위한 4 스테이지 처리 파이프라인을 나타낸다. 요소(1542, 1544, 1546 및 1548)는 DMA 요청의 결과로서 트리거된 규칙을 나타낼 수 있다. 요소(1545)는 예컨대 다른 도면(예를 들어, (1500)의 (1502))과 관련하여 설명된 I/O PUMP를 나타낸다. 요소(1543)는 DMW 처리 파이프라인의 스테이지를 나타낸다. 제 1 스테이지(1541a)에서, DMA 요청은 신뢰성 없는 패브릭으로부터 수신되고, 입증되지 않은 요청은 메모리(712c)로부터 요청된 DMA 데이터 및 그의 연관된 태그를 획득하기 위해 제 2 메모리 페치 스테이지(1541b)의 규칙(1542)을 통해 이루어진다. DMA 요청된 데이터에 대해 메모리로부터의 페치된 태그 정보는 현재 DMA 요청에 대응하는 규칙에 대한 I/O PUMP 캐시(1545)에서 룩업이 수행되는 제 3 입증 스테이지(1541c)로의 입력으로서 제공된다. I/O PUMP에서 규칙이 발견되지 않으면, I/O PUMP 처리는 스테이지(1541c)에서 정지되고 디스에이블될 수 있지만, DMA 미스 핸들러는 프로세서(702)에서 실행되어 DMA 요청에 대한 출력 Rtag 및 PCnew tag를 계산하거나 그렇지 않으면 현재 DMA 요청이 허용되지 않음을 결정한다(이에 따라 결함 또는 트랩을 트리거한다). 현재 DMA 요청에 대한 규칙을 I/O PUMP에서 찾는다고 가정하면, DMA 요청이 실행되도록 허용된다고 결정된다. DMA 요청이 기입 요청이면, DMA 요청의 기입 데이터는 그의 태그 정보와 함께 스테이지4(1541d)에서 메모리(712c)에 라이트백된다. DMA 기입 동작의 경우, 일단 기입이 완료되면, 응답(1548a)이 신뢰성 없는 패브릭(및 그 다음으로 DMA 요청을 개시한 DMA 디바이스)에 제공될 수 있다. DMA 판독 동작의 경우, 응답(1546a)이 신뢰성 없는 패브릭(및 그 다음으로 DMA 요청을 개시한 DMA 디바이스)으로 리턴되고, 이 경우 응답은 스테이지 2(1541b)에서 페치된 요청된 데이터를 포함한다.
요소(1542)는 스테이지 2(1541b)에서 메모리 페치가 수행되는 동안 신뢰성 없는 패브릭으로부터의 요청을 통과시키고 (스테이지 3(1541c)에서) I/O PUMP(1545)에 대한 I/O 요청에 관한 (스테이지 1(1541a)로부터) 정보를 통과시키는 규칙을 나타낼 수 있다. 요소(1544)는 신뢰성 있는 패브릭으로부터의 태그 응답을 모으고, I/O PUMP에 입력된 실제 규칙을 공식화하며, I/O PUMP의 출력과 병합되도록 스테이지(1541b)로부터 라이트백 스테이지(154dd)로 정보를 전파하는 규칙을 나타낼 수 있다.
전술한 실시예의 변형예로서, 예(1500)를 다시 참조한다. 적어도 하나의 실시예에서, 위에서 설명한 바와 같이 규칙을 I/O PUMP 캐시에 저장하기 보다는, I/O PUMP는 하드와이어드 I/O PUMP로서 구현될 수 있고, 하드와이어드 I/O PUMP에서 규칙은 고정 세트의 I/O PUMP 로드 및 스토어 규칙을 구현하기 위해 배선된 로직 게이트와 같은 전용 하드웨어를 사용하여 구현될 수 있다.
또 다른 변형예로서, I/O PUMP는 예(1500)와 관련하여 설명된 바와 같이 또 다른 실시예에서 프로그래머블 캐시로서 대안적으로 정의될 수 있으며, 차이점은 규칙 캐시로서 I/O PUMP가 유한 용량을 갖고 I/O PUMP 캐시에 모두 저장되는 고정된 규칙 세트로 채워진다는 점이다. 이러한 후자의 실시예에서, I/O PUMP는 모든 DMA 규칙의 완전한 세트로 채워질 수 있으므로 I/O PUMP에 대한 규칙 캐시 미스는 결코 없다. 따라서, I/O PUMP 규칙 캐시 미스를 서비스할 필요가 절대로 없다.
이제는 메모리 위치와 연관될 수 있는 태그 초기화, 설정 또는 리셋팅과 관련하여 사용될 수 있는 기술이 설명될 것이다. 본 명세서의 다른 설명과 일관하여, 그러한 기술과 관련하여 사용되는 태그는 비-포인터 태그(비-포인터 태그는 연관된 메모리 위치에 대한 실제 태그 값임) 또는 포인터 태그(포인터 태그는 포인터 또는 실제 태그 값 또는 값들을 포함하는 다른 메모리 위치의 어드레스임)를 나타낼 수 있다. 예를 들어, 메모리 위치와 연관된 포인터 태그는 복합 태그와 관련하여 사용될 수 있으며, 복합 태그에서 포인터는 예컨대 병렬로 구현된 복수의 복합 정책에 대한 다수의 태그 값을 포함하는 메모리 내의 어드레스를 식별한다. 본 명세서의 다른 곳에서 설명된 바와 같이, 병렬로 지원될 수 있는 예시적인 복합 정책은 본 명세서에서 설명된 메모리 안전 정책 및 CFI(제어 흐름 무결성) 정책을 포함한다.
메모리 안전 및 스택 정책과 관련하여 수행되는 처리는 예를 들어, 메모리 위치와 연관된 많은 수의 태그를 특정 값으로 설정하거나 초기화하는 것을 포함할 수 있다. 예를 들어, 메모리 영역의 할당이 예컨대 특정 컬러와 관련될 수 있을 때, 영역 내의 메모리 위치와 연관된 각각의 태그는 특정 컬러 값을 갖도록 초기화되어야 한다. 다른 예로서, 메모리 영역을 되돌려 놓을 때, 예컨대 메모리 영역을 프리로 만들 때, 프리 또는 할당되지 않은 영역의 모든 메모리 위치는 프리 또는 할당되지 않은 메모리 위치를 나타내는 특정 태그 값으로 초기화될 수 있다.
영역 내의 모든 메모리 위치의 태그를 초기화 또는 리셋하기 위해 수행되는 처리는 수용할 수 없는 양의 시간을 소비할 수 있으며, 태깅될 메모리 영역의 크기가 증가함에 따라 특히 수용할 수 없게 된다. 따라서, 메모리 위치의 태그를 효율적으로 초기화 또는 설정(태깅)하기 위한 기술이 다음 단락에서 설명된다. 적어도 하나의 실시예에서, 태그 초기화 또는 설정은 예를 들어, 메모리의 영역 할당 또는 메모리 영역의 프리 상태화와 관련하여 수행될 수 있다. 본 명세서에 설명된 이러한 기술은 큰 메모리 영역과 함께 사용하기 위해 확장 가능하다. 이러한 기술이 메모리 위치의 태그와 관련하여 아래에 예시되지만, 보다 일반적으로, 이러한 기술은 데이터 아이템 또는 엔티티와 각각 연관된 값을 초기화, 설정 또는 리셋팅하는 것과 관련하여 사용될 수 있다.
적어도 하나의 실시예에서, 메모리 영역의 태그 및 연관된 메모리 위치는 계층 구조의 리프가 메모리 위치에 대한 태그를 나타내는 계층적 구조 또는 배열로 표현될 수 있다. 설명의 목적 상, 다음의 논의는 트리를 계층 구조로서 참조한다. 그러나, 보다 일반적으로, 임의의 적합한 계층 구조가 메모리 위치 영역과 연관된 어드레스 공간을 표현하는데 사용될 수 있다.
극단적인 사례로, 일 실시예에서, 트리 또는 계층 구조의 리프는 메모리 내의 개별 워드를 나타내고 태그를 보유할 수 있다. 그러나, 전체 서브트리가 동일한 태그 값으로 동질로 태깅되면, 본 명세서에서의 기술은 서브트리의 임의의 자손 노드를 더 나타내지 않고 트리 내의 특정 노드 및 연관된 레벨에 태그 값을 단순히 저장할 수 있다. 이 경우, 노드의 태그 값은 (예를 들어, 연속적인 또는 인접한 메모리 어드레스의 범위와 같은) 특정 영역의 다수의 메모리 위치에 대한 태그 값을 특정한다. 이러한 방식으로, 동질로 태깅된 큰 영역이 존재하면, 저장소는 태그 값을 저장하는데 절약될 수 있다. 동질의 태그 값이 없는 최악 사례의 시나리오(예를 들어, 연속적인 어드레스를 갖는 두 개의 메모리 위치가 동일한 태그 값을 갖지 않음)에서, 트리의 리프는 각각 영역 내의 단일 워드와 같은 단일 메모리 위치에 대한 태그 값을 나타낸다.
다음 단락에서 설명되는 바와 같은 트리와 같은 그러한 계층 구조에서, 하나의 노드를 간단히 트리에 다시 기입함으로써 2의 제곱의 메모리 영역을 다시 태깅하거나 초기화하는 처리가 수행될 수 있다. 2의 제곱을 하지 않은 영역의 경우, 처리를 수행하여 영역을 최소 세트의 2제곱 영역으로 (예를 들어, 최소 세트의 그러한 영역을 최대 2*log2(영역 크기)로) 분할하는 처리가 수행될 수 있다. 특정 워드 또는 메모리 위치의 태그가 필요할 때(예를 들어, 연관된 메모리 위치에 대한 태그를 판독할 때), 트리를 사용하여 태그를 결정하는 처리가 수행될 수 있다. 아래에서 설명되는 적어도 하나의 실시예에서, 캐시 메모리의 계층은 트리의 상이한 레벨에 이용될 수 있다. 태그 값은 원하는 메모리 위치에 관련하여 캐시 히트를 갖는 트리의 최고 레벨과 연관된 캐시에 의해 제공될 수 있다(예를 들어, 원하는 메모리 위치의 어드레스에 대한 태그 값의 캐시 룩업을 수행한다). 메모리 위치와 연관된 태그 값을 기입 또는 수정하기 위해 수행되는 처리와 관련하여, 처리는 서브트리 또는 다중 기입(예를 들어, 2*log2(영역 크기) 로그 기입(log write))을 표시하는 단일 기입을 수행하는 것을 포함할 수 있다. 이러한 다중 기입은, 예를 들어, 태그 값을 수정하거나 설정하기 전에 동질로 태깅된 제 1 메모리 영역에 포함된 제 1 메모리 위치의 태그를 수정 또는 설정하는 것에 응답하여 수행될 수 있다. 이 경우, 태그 값을 설정 또는 변경하는 것은 제 1 메모리 영역이 더 이상 동질로 태깅되지 않게 하며, 이에 따라서 제 1 메모리 영역에 대한 태그 값을 나타내는 계층 구조는 제 1 메모리 영역에 대한 태그 값을 나타내는 서브트리를 더 분해하도록 업데이트한다.
도 78을 참조하면, 본 명세서에서의 기술에 따른 실시예에서 메모리 영역에 대응하는 어드레스 공간에 대한 태그 값을 표현하기 위해 사용될 수 있는 계층 구조체의 예가 도시된다. 예(100)는 도시의 단순화를 위해 8 메모리 위치를 포함하는 메모리 영역을 나타내는데 사용되는 계층 구조체로서 트리를 도시한다. 보다 일반적으로, 본 명세서에서의 기술은 임의의 수의 레벨, 각 레벨에서 임의의 적합한 수의 노드, 부모 노드 당 임의의 적합한 수의 자식 노드 및 각 레벨에서 임의의 적합한 수의 노드를 갖는 임의의 적합한 계층을 사용하여 임의의 어드레스 공간 또는 메모리 영역에 대한 태그 값을 나타내는데 사용될 수 있다.
예(100)는 어드레스 0 내지 7을 포함하여 8 메모리 위치에 대한 태그 값의 이진 트리 표현을 도시한다. 이 예에서 트리는 만일 있다면, 8 메모리 위치 중 어느 것이 구조체(100)의 동일한 서브트리를 사용하여 동질로 태깅되었는지에 따라 최대 4 레벨의 노드를 포함할 수 있다. 이 예에서, 8 메모리 위치의 전체 메모리 영역은 두 개의 더 작은 메모리 영역의 제곱으로 반복적으로 분할될 수 있고, 더 작은 메모리 영역의 각각의 그러한 분할은 트리 내의 노드들의 서로 다른 레벨에 대응한다. 예를 들어, 레벨 1(104)은 레벨 2(106)에서의 노드(노드 B1 및 B2)에 의해 각각 표현되는 두 개의 더 작은 영역으로 분할되는 전체 어드레스 공간 0 내지 7에 대응하는 노드 A1을 포함한다. 레벨 2(106)는 어드레스 0 내지 3과 연관된 노드 B1 및 어드레스 4 내지 7과 연관된 노드 B2를 포함한다.
레벨 2(106)에서의 노드 B1 및 B2 각각은 레벨 3(108)에서의 노드에 의해 각각 표현되는 두 개의 더 작은 영역으로 더 분할될 수 있다. 노드 B1 및 그의 연관된 어드레스 범위 0 내지 3은 노드 C1 및 C2에 의해 표현되는 두 개의 영역으로 분할되며, 여기서 C1은 어드레스 범위 0-1과 연관되며 C2는 어드레스 범위 2-3과 연관된다. 유사하게, 노드 B2 및 그의 연관된 어드레스 범위 4 내지 7은 노드 C3 및 C4에 의해 표현되는 두 개의 영역으로 분할되며, 여기서 C3은 어드레스 범위 4-5와 연관되고 C4는 어드레스 범위 6-7과 연관된다.
레벨 3(108)에서의 노드 C1 내지 C4) 각각은 레벨 4(110)에서의 노드에 의해 각각 표현되는 두 개의 더 작은 영역으로 더 분할될 수 있다. 이 예에서, 레벨 4에서의 노드는 각각 단일 워드 또는 메모리 위치에 대한 태그 값을 나타낸다. 노드 C1 및 그의 연관된 어드레스 범위 0-1은 노드 D1 및 D2로 표현되는 두 개의 영역으로 분할되며, 여기서 D1은 어드레스 0과 연관되고 D2는 어드레스 1과 연관된다. 노드 C2 및 그의 연관된 어드레스 범위 2-3은 노드 D3 및 D4로 표현되는 두 개의 영역으로 분할되며, 여기서 D3는 어드레스 2와 연관되고 D4는 어드레스 3과 연관된다. 노드 C3 및 그의 연관된 어드레스 범위 4-5는 노드 D5 및 D6로 표현되는 두 개의 영역으로 분할되며, 여기서 D5는 어드레스 4와 연관되고 D6은 어드레스 5와 연관된다. 노드 C4 및 그의 연관된 어드레스 범위 6-7은 노드 D7 및 D8로 표현되는 두 개의 영역으로 분할되며, 여기서 D7은 어드레스 6과 연관되고 D8은 어드레스 7과 연관된다.
모든 노드(A1, B1-B2, C1 내지 C4 및 D1 내지 D8)은 8 메모리 위치의 영역에 대한 태그 값의 계층적 표현에 존재할 수 있는 가능한 노드의 최대 수를 나타낼 수 있다. 그러나, 보다 상세하게 아래에서 설명되는 바와 같이, 메모리 위치 0 내지 7에 저장된 태그 값을 나타내는 트리에 포함된 특정 노드는 특정 태그 값 및 다양한 시점에서 표현된 동질 및 비동질 태그 영역에 따라 달라질 수 있다. 계층의 레벨은 루트 또는 레벨 1(104) 노드에 대응하는 최상위 레벨로부터 최하단 레벨 4(110)에 대응하는 최하위 레벨로 등급이 매겨질 수 있다.
본 명세서에서의 기술과 관련하여 제 1 예에 대해, 도 79의 (120)이 참조된다. 이러한 제 1 예에서, 계층(120)의 특정 레벨에 있는 노드와 연관된 모든 메모리 위치는 동일한 태그 값 T1을 갖고, 이에 따라 동질로 태깅된 메모리 위치의 서브트리를 나타내고, 특정 레벨에서의 노드는 모든 그러한 메모리 위치의 태그 값을 가지며, 서브트리 내의 더 이상의 자손 노드는 동질로 태깅된 메모리 위치 중 임의의 메모리 위치에 대한 태그 값을 결정하기 위해 참조될 필요가 없다. 예컨대, 동일한 태그를 갖는 메모리 영역을 초기화하는 것과 관련하여 모든 메모리 위치 0 내지 7이 동일한 태그 값 T1을 포함하면, 메모리 위치 0 내지 7에 대한 태그 값 T1은 (예를 들어, 노드 A1에 의해 "tag=T1" 표시로 나타내는 바와 같이) 노드(A1)에 저장될 수 있다. 적어도 하나의 실시예에서, 어드레스 0 내지 7에 대한 전체 영역에 대한 태그 값은 단일 노드 A1에 의해 표현되기 때문에 트리의 다른 노드에 대한 추가 태그 값을 더 이상 저장할 필요가 없다. 이 경우, 요소(122)는 어드레스 0 내지 7을 갖는 메모리 위치에 저장된 태그 값의 계층적 표현에 포함될 수 있는 단일 노드를 나타내며, 나머지 노드(B1, B2, C1 내지 C4 및 D1 내지 D8)는 계층적 표현에서 생략될 수 있다
제 2 예에서, 도 80의 (130)이 참조된다. 이러한 제 2 예에서, 메모리 위치 0 내지 3이 동일한 제 1 태그 값 T1을 갖고 메모리 위치 4 내지 7이 동일한 제 2 태그 값 T2을 갖는다고 가정한다(제 1 및 제 2 태그 값 태그 값은 상이하다). 이 경우, 노드(A1)는 노드 A1이 메모리 위치 0 내지 7에 대한 동질 태그를 특정하지 않고 메모리 위치 0 내지 7에 대한 태그 값이 계층의 하나 이상의 하위 레벨에 있는 노드에 의해 특정되는 것을 나타내는 표시자(예를 들어, 노드 A1에 의해 "TAG VALUE = NO TAG VALUE" 표시로 나타냄)를 포함할 수 있다. 계층의 레벨 2에서, 제 1 태그 값 T1은 노드 B1에 저장될 수 있고(노드 B1에 의해 "TAG VALUE=T1" 표시로 나타냄), 제 2 태그 값 T2는 노드 B2에 저장될 수 있다(노드 B2에 의해 "TAG VALUE=T2" 표시로 표시됨). B1이 루트인 서브트리(B1, C1, C2, D1 내지 D4)는 동질로 태깅된 메모리 위치 0 내지 3의 한 세트를 나타낸다. B2가 루트인 서브트리(B2, C3, C4, D5 내지 D8)는 동질로 태깅된 메모리 위치 4 내지 7의 다른 세트를 나타낸다. 적어도 하나의 실시예에서, 레벨 3 및 4에서의 트리의 다른 노드(예를 들어, 레벨 3에 대한 노드 C1 내지 C4 및 레벨 4에 대한 노드 D1 내지 D8)에 대한 추가 태그 값을 더 이상 저장할 필요는 없는데, 그 이유는 어드레스 0 내지 7에 대한 전체 영역에 대한 태그 값이 레벨 2에서의 노드 B1 및 B2로 표현되기 때문이다. 이 경우, 요소(132)는 어드레스 0 내지 7을 이용한 메모리 위치에 저장된 태그 값의 계층적 표현에 포함될 수 있는 노드를 나타내고, 나머지 노드(C1 내지 C4 및 D1 내지 D8)은 계층적 표현에서 생략될 수 있다.
제 1 시점에서, 모든 태그가 동일한 태그 값을 가지므로, 태그 계층은 단일 노드(122)만으로 예(120)와 관련하여 설명된 바와 같을 수 있다. 후속하는 제 2 시점에서, 어드레스 0 내지 3에 대한 태그 값은 동일한 제 1 태그 값 T1로 수정될 수 있고 어드레스 4 내지 7은 동일한 제 2 태그 값 T2로 수정될 수 있다. 전술한 태그 수정의 결과로서, 예(130)에서 위에서 설명된 바와 같은 두 개의 부가 노드 B1 및 B2가 계층에 추가될 수 있다. 후속하는 제 3 시점에서, 이제 어드레스 0 내지 3에 대한 태그 값은 예(130)에서와 동일하게 유지된다고 가정한다. 그러나, 어드레스 4 내지 7에 대한 태그 값은 도 81과 관련하여 아래에서 설명되는 바와 같이 수정될 수 있으며, 이에 의해 (C4 및 D5-D6)이 태그 계층에 추가된다.
제 3 예에서, 도 81의 (140)이 참조된다. 이러한 제 3 예에서, 메모리 위치 0 내지 3은 위에서 설명된 바와 동일한 제 1 태그 값 T1을 갖는다고 가정한다(여기서, 제 1 태그 값 T1은 노드 B1 및 서브트리(B1, C1, C2, D1 내지 D4)에 저장되며, 서브트리 중 B1은 동질로 태깅된 한 세트의 메모리 위치 0 내지 3을 나타낸다. 또한, 메모리 위치 4-5는 각각 상이한 태그 값을 포함하며, 여기서 메모리 위치 4는 태그 값 T3을 갖고, 메모리 위치 5는 태그 값 T4를 가지며, 메모리 위치 6-7는 동질로 태깅되고 동일한 태그 값 T5를 포함한다고 가정한다. 이 경우, 노드 A1, B2 및 C3는 위의 설명과 일관하여, 각각 특정 노드가 태그 값을 특정하지 않는 표시자(예를 들어, TAG=NO TAG)를 포함할 수 있고, 이에 따라 계층 내의 하나 이상의 하위 레벨에서의 노드는 노드 A1, B2 및 C3와 연관된 특정 메모리 위치에 대한 태그 값을 특정한다. 예를 들어, 메모리 위치 4-5에 대응하는 노드 C3는 노드 C3이 태그 값을 특정하지 않음으로써, 계층 내의 하나 이상의 하위 레벨에서의 노드가 메모리 위치 4-5에 대한 태그 값을 특정한다는 표시자를 포함할 수 있다. 레벨 4에서의 노드 D5는 메모리 위치 4에대한 태그 값 T3를 특정(예를 들어, 노드(D5)에 의해 TAG=T3 표시자)할 수 있고, 레벨 4에서의 노드 D6는 메모리 위치 6-7에 대한 태그 값 T4를 특정(예를 들어, 노드 D6에 의해 TAG=T4 표시자)할 수 있다. 메모리 위치 6-7에 대응하는 노드 C4는 태그 값 T5을 메모리 위치 6-7에 공통인 동질 태그 값으로 특정(예를 들어, 노드 C4에 의해 TAG=T5 표시자)할 수 있고, 노드 D7 및 D8에 추가 태그 값을 더 이상 저장할 필요가 없음(예를 들어, C4의 자손 노드 D7, D8을 더 이상 검사할 필요가 없음)을 표시한다. 이 경우, 요소(142)는 어드레스 0 내지 7을 이용한 메모리 위치에 저장된 태그 값의 계층적 표현에 포함될 수 있는 노드를 나타내며, 나머지 노드(C1-C2, D1 내지 D4 및 D7 내지 D8)는 계층적 대현에서 생략될 수 있다.
(120, 130 및 140)의 전술한 예시는 메모리 위치와 연관된 태그 값이 시간에 따라 변할 수 있기 때문에 상이한 시점에서 어드레스 또는 메모리 위치 0 내지 7에 대한 메모리 영역에 대한 태그 값의 계층적 표현을 나타낼 수 있다. 위에서 설명된 바와 같은 계층에 노드를 추가하는 것과 유사한 방식으로, 기존 노드의 서브트리가 모두 동일한 태그 값을 갖도록 수정되므로 필요에 따라 노드는 계층에서 제거할 수 있다(예를 들어, 노드의 후손이 모두 동일한 태그 값이면, 모든 자손 노드는 계층에서 제거될 수 있고 노드는 서브트리의 유일한 노드로서 사용되어 노드 및 그 후손의 단일의 동질 태그 값을 나타낼 수 있다).
적어도 하나의 실시예에서, 트리의 레벨에서의 제 1 노드가 제 1 노드와 연관된 하나 이상의 메모리 위치에 대한 값을 특정할 때, 제 1 노드의 자손 노드를 더 나타낼 필요가 없다(예를 들어, 제 1 노드 이외의 서브트리 노드를 더 나타낼 필요가 없다). 추가로 설명하면, 메모리 영역 0 내지 7에 대한 단일의 동질 태그 값을 나타내기 위해 노드 A1의 태그 값만이 필요한 도 79의 (120)에서 위에서 언급된 제 1 예가 참조된다. 추가로 설명하면, 실시예가 노드(C1 내지 C2, D1 내지 D4 및 D7 내지 D8)를 더 나타내지 않을 수 있는 위에서 언급된 도 81의 제 3 예(140)가 참조된다. 이러한 방식으로, 메모리 위치 및 연관된 태그 값의 이와 같은 계층적 표현을 사용하면 메모리 위치에 대한 태그 값과 관련하여 저장소를 절약할 수 있다. 다시 말해서, 적어도 하나의 실시예에서, 각각의 메모리 위치에 대한 개별 태그 값을 항상 할당하고 저장하기보다는, 계층 내의 단일 태그 값이 연속적 또는 인접한 어드레스를 갖는 다수의 메모리 위치에 대해 동질 태그 값을 나타내는 저장 디바이스가 할당될 수 있다. (120)에서 언급된 제 1 예를 참조하면, 각각이 동일한 태그 값을 포함하는 메모리 위치 0 내지 7에 대한 8 태그 값을 위한 저장소를 할당하기보다는, 노드(A1)의 단일 태그 값을 저장하기 위한 메모리가 할당될 수 있다.
어드레스 0 내지 7을 갖는 메모리 영역에 동질로 태깅된 메모리 위치가 없다고 가정하는 최악의 시나리오에서, 도 78의 전체의 노드 계층 구조체는 어드레스 0 내지 7에 저장된 태그 값을 나타내기 위해 사용된다. 예를 들어, 계층의 각 리프는 메모리의 다른 워드를 나타낼 수 있다. 따라서, 계층의 최하단 레벨 4(110)는 어드레스 공간 0 내지 7에 대한 태그 값을 나타낼 수 있다.
다시 도 78을 참조하면, 메모리 위치 0 내지 7의 어드레스를 나타내는데 사용되는 8 비트 어드레스 공간이 있다고 가정한다. 적어도 하나의 실시예에서, 전체 8 비트 어드레스 공간은 각각이 8 메모리 위치를 포함하는 상이한 메모리 영역으로 분할될 수 있고, 각각의 상이한 메모리 영역은 태그 값 계층의 상이한 인스턴스에 의해 표현되는 태그 값을 가질 수 있다. 따라서, 방금 설명한 어드레스 0 내지 7의 메모리 영역에 대해, 최상위 또는 최상단 5 비트는 all=0이고, 어드레스 0 내지 7은 나머지 하위 3 비트에서 표현될 수 있다. 따라서 최상위 또는 최상단 5 비트=0은 어드레스 0 내지 7의 메모리 영역을 나타내는데 사용될 수 있다. 이러한 실시예에서, 8 메모리 위치의 각각의 메모리 영역은 예컨대 특정 메모리 영역의 태그 값을 나타내는 도 78에 도시된 분리된 태그 값 계층을 가질 수 있다. 이 예에서, 8 어드레스 또는 메모리 위치의 상이한 범위를 나타내는 상이한 메모리 영역 각각은 메모리 위치의 8 비트 어드레스의 최상단 5 비트를 검사함으로써 구별될 수 있다.
본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 태그 캐시의 수가 태그 값을 나타내는 노드의 계층에서의 레벨의 수에 대응할 수 있는 일련의 태그 캐시 메모리가 사용될 수 있다. 위에서 논의된 예를 계속 진행하면서 도 78의 (100)을 다시 참조하면, 8 메모리 위치의 메모리 영역에 대한 태그 계층의 각 인스턴스는 4 레벨을 갖는다. 이러한 경우에, 실시예는 메모리 위치에 대한 태그를 저장하기 위해 도 82의 예(150)에 도시된 바와 같이 4 태그 캐시 메모리(152, 154, 156 및 158)를 사용할 수 있다. 일반적으로, 4 태그 캐시 메모리(152, 154, 156 및 158) 각각은 태그 값 계층에서 상이한 레벨과 연관되고 태그 값 계층의 연관된 상이한 레벨에 각 노드에 관한 정보를 저장할 수 있다. 예를 들어, 태그 레벨 캐시(152)는 레벨 1(104) 노드 또는 메모리 영역(위에서 언급한 바와 같이 이러한 특정 예에서는 8 메모리 위치의 메모리 영역) 각각에 대한 태그 값 계층의 루트에 대한 정보를 포함할 수 있다. 태그 레벨 캐시(154)는 각각의 메모리 영역에 대한 태그 값 계층의 레벨 2(106) 노드에 대한 정보를 포함할 수 있다. 태그 레벨 캐시(156)는 각각의 메모리 영역에 대한 태그 값 계층의 레벨 3(108) 노드에 대한 정보를 포함할 수 있다. 태그 레벨 캐시(158)는 각각의 메모리 영역에 대한 태그 값 계층의 레벨 4(108) 노드에 대한 정보를 포함할 수 있다. 이 예에서 레벨 4(110)인 계층의 최하위 또는 최하단 레벨은 데이터 캐시에 저장될 수 있는 메모리 위치에 대한 캐시 라인에 대응할 수 있다(예를 들어, 도 1의 요소(20)으로 표시되는 바와 같이 (L1-D$)로 나타낸다). 실시예는 태그 캐시의 레벨 4(158)를 가질 수 있고 데이터 캐시의 캐시 라인에 개별적으로 저장될 수 있는 메타데이터 태그를 부가적으로 데이터 캐시의 캐시 라인에 별도로 저장될 수 있는 메타데이터 태그를 가질 수 있다. 노드의 캐시(152, 154, 156 및 158) 각각은 메인 메모리에 연관된 표현을 갖는다.
8 비트 어드레스 공간을 갖는 본 명세서에서 설명된 실시예와 관련하여, 메모리 위치의 어드레스의 최상단 또는 최상위 5 비트(152a)는 레벨 1 캐시(152)에 의해 캐시(152)가 메모리 위치의 어드레스에 대한 임의의 레벨 1 노드를 포함하는지를 검색하는데 사용될 수 있다. 메모리 위치의 어드레스의 최상단 또는 최상위 6 비트(154a)는 레벨 2 캐시(154)에 의해 캐시(154)가 메모리 위치의 어드레스에 대한 임의의 레벨 2 노드를 포함하는지를 검색하는데 사용될 수 있다. 메모리 위치의 어드레스의 최상단 또는 최상위 7비트(156a)는 레벨 3 캐시(156)에 의해 캐시(156)가 메모리 위치의 어드레스에 대해 임의의 레벨 3 노드를 포함하는지를 검색하는데 사용될 수 있다. 메모리 위치의 어드레스의 8 비트(154a)는 레벨 4 캐시(158)에 의해 캐시(158)가 메모리 위치의 어드레스에 대해 임의의 레벨 4 노드를 포함하는지를 검색하는데 사용될 수 있다.
특정 어드레스의 경우, 최하단 레벨이 아닌 다른 레벨과 연관된 각각의 캐시는 다음의 것을 리턴할 수 있다:
1) 특정의 어드레스에 대한 태그 값(이것이 그 레벨에서 다수의 어드레스에 대한 동질의 태그 값이 있는 것을 나타냄);
2) 캐시는 특정 어드레스에 대한 태그 값을 특정하지 않으며, 계층의 더 낮은 레벨에서의 캐시는 특정 어드레스에 대한 태그 값을 획득하기 위해 참조될 필요가 없다는 표시자(이러한 특정 레벨은 특정 어드레스에 대한 동질의 태그 값을 특정하지 않음); 또는
3) 특정 어드레스에 대응하는 노드 또는 태그 정보를 포함하는 특정 레벨 캐시에 캐시 위치가 없음을 나타내는 널(null) 또는 제 2 표시자. 제 2 표시자는 또한 더 낮지만 하단이 아닌 레벨 캐시에서의 어떤 캐시도 어드레스에 대한 노드 또는 태그 정보를 포함하지 않음을 나타낸다. 이에 대해서는 아래에서 자세히 설명한다.
위의 논의와 일관하여, 아이템 2)에서 리턴된 표시자는 예컨대 예(120, 130 및 140)에 도시된 노드와 연관된 "NO TAG" 표시자일 수 있다. 예를 들어, 도 80의 예(130)를 참조하여, 메모리 위치 5에 대한 태그를 결정하는 처리가 수행된다고 가정한다. 이 경우에, 레벨 1 캐시(152)는 메모리 위치 5에 대한 태그 값이 다른 하위 레벨 캐시(154, 156 또는 158) 중 하나에 의해 특정됨을 나타내는 NO TAG 표시자를 리턴할 수 있다. 레벨 2 캐시(154)는 위의 리턴된 캐시 아이템 1)을 예시하는 메모리 위치 5에 대한 태그 값 T2를 리턴할 수 있다. 제 2 표시자가 리턴된 위의 리턴된 아이템 3)을 설명하기 위해, 레벨 3 캐시(156)를 고려해 본다. 레벨 3 캐시(156)는 메모리 위치(5)에 대응하는 임의의 노드 정보를 포함하지 않을 수 있으며(예를 들어, 어떠한 캐시 위치도 연관된 노드 또는 태그 정보를 포함하지 않고) 그래서 이 레벨 3 캐시에는 메모리 위치 5에 대한 노드 정보가 없음을 표시하는 위의 3)에서 설명된 제 2 표시자가 리턴될 수 있다. 이러한 실시예에서, 처리는 최고 태그 레벨 캐시로부터 리턴된 태그 값을 일반적으로 이용할 수 있다. 예를 들어, 메모리 위치 5와 관련하여 예(130)를 참조하면, 레벨 2 캐시(154)는 메모리 위치 5에 대한 태그 값을 리턴하는 최상위 레벨의 태그 캐시이다.
L1(레벨 1) 데이터 캐시에 저장된 메모리 위치의 내용의 경우, 캐싱된 정보에는 현재 태그 값 및 태그 값이 정의된 태그 캐시 계층의 레벨이 포함될 수 있다. 도 80의 계층(130)을 사용하는 메모리 위치 5에 대한 위의 예를 다시 참조하면, 메모리 위치 5의 내용이 또한 데이터 캐시에 저장되어 있다면, 데이터 캐시는 태그 값 T2를 포함할 수 있고 또한 현재 태그 값 T2가 레벨 2 캐시(154)에 저장된 노드 정보를 갖는 레벨 2 노드(예를 들어, B2)에 의해 정의된 정보를 포함할 수 있다. 따라서, 예(150)는 태그 값이 저장될 수 있는 태그 캐시 계층의 4 태그 캐시를 도시하며, 태그 캐시 계층에 저장된 임의의 태그 정보와 별도로 태깅된 데이터 캐시(예를 들어, L1 데이터 캐시)를 부가적으로 포함한다.
본 명세서에서의 기술에 따른 실시예에서, PUMP에 의해 수행되어 특정 어드레스를 갖는 특정 메모리 위치에 대한 태그 값을 해결하거나 결정하는 처리가 수행될 수 있다. 특정 메모리 위치에 대한 태그 값 및 내용을 획득하는 처리를 수행할 때, 메모리 캐시 내용 및 그의 태그가 데이터 캐시에 저장되는 데이터 캐시 히트가 있을 수 있다. 메모리 위치에 대한 데이터 캐시 히트가 발생하면, 이 메모리 위치에 대한 태그 값을 정의하는 태그 캐시 계층의 저장된 레벨을 참조하는 처리가 수행되어, 태그 캐싱 레벨로부터 획득된 제 1 캐싱된 태그 값이 데이터 캐시에 저장된 메모리 위치의 제 2 태그 값과 매칭함을 보장해 줄 수 있다. 둘이 매칭하지 않으면, 이것은 데이터 캐시에 저장된 제 2 캐시 태그 값이 정지 상태이고, 유효 기간이 지났으며 수정되었음을 나타낸다. 이 경우, 데이터 캐시에 저장된 메모리 위치에 대한 제 2 캐시 태그 값 및 메모리 위치에 대한 태그 캐시로부터 획득된 제 1 태그 값이 매칭하지 않으면, (예를 들어, 태그 캐시 계층에 저장된 것과 매칭하도록) 데이터 캐시에 저장된 메모리 위치에 대한 제 2 캐시 태그 값을 업데이트하는 것을 포함하는 처리가 수행될 수 있다. 적어도 하나의 실시예에서, 메모리 위치가 그의 데이터를 갖고 그래서 데이터 캐시에 그의 태그가 캐싱된 경우, 태그가 정의된 태그 캐시 계층의 레벨을 포함하는 메모리 위치의 태그에 대한 데이터 캐시 내의 정보가 추적될 수 있다. 전술한 캐시 태그 계층에 레벨을 저장하는 것은 (예를 들어, 모든 태그 레벨 캐시를 참조하거나 그렇지 않으면 예컨대 루트 또는 계층의 최상단에서부터 리프 노드를 향한 하향 검색에서 기존 노드의 계층을 찾아야 하는 것 보다는) 저장된 레벨이 태그 계층으로부터의 태그 값에 용이하게 액세스하는데 사용될 수 있는 최적한 것일 수 있다. 따라서, 데이터 캐시 히트가 발생하면 그리고 메모리 위치에 대한 데이터 캐시에 저장된 태그 값이 메모리 위치에 대한 태그 계층에 저장된 태그 값과 매칭하지 않는 경우, 처리는 데이터 캐시에 저장된 태그 값을 업데이트하는 것 및 메모리 위치의 태그가 태그 계층에서 정의된 것에 관해서 데이터 캐시에 저장된 계층 레벨 정보를 추가적으로 업데이트하는 것을 포함할 수 있다. 이어서, 메모리 위치에 대한 태그 값을 해결하거나 결정하기 위해 PUMP에 의해 수행되는 처리가 재시작될 수 있다.
메모리 위치에 대한 데이터 캐시 미스가 발생하면(예를 들어, 메모리 위치 내용 및 태그가 데이터 캐시에서 발견되지 않는 경우), (예를 들어, 최하단 태그 캐시 레벨 이외의) 태그 캐시의 레벨에서 태그 값에 대한 태그 캐시 룩업을 병렬로 수행하는 처리가 수행될 수 있다. 예를 들어, 메모리 위치에 대한 태그 값에 대한 룩업은 태그 캐시의 레벨 1, 2, 3 및 4에 대해 각각 4 캐시(152, 154, 156 및 158)를 참조함으로써 병렬로 수행될 수 있다. 위에서 논의된 바와 같이, 최상위 레벨의 태그 캐시(152, 154, 156 및 158)에 의해 리턴된 태그 값은 메모리 위치에 대한 태그 값으로서 사용된다. 또한, 적절하게 표현된 태그 값 계층에서, (152, 154, 156 및 158) 중 단 하나만이 메모리 위치에 대한 태그 값을 리턴할 수 있다는 것을 유의하여야 한다. 적어도 하나의 실시예에서, 캐시(152, 154, 156 및 158)는 병렬 액세스를 할 수 있도록 색인될 수 있다.
실시예는 또한 모든 4 태그 캐시(152, 154, 156 및 158)와 관련하여 특정 메모리 위치의 태그를 찾는 병렬 검색 또는 룩업을 수행하지 않을 수 있다. 변형예로서, 실시예는 계층의 태그 캐시를 루트 노드 레벨(레벨 1)로부터 리프 노드(예를 들어, 레벨 4)를 향해 아래쪽으로 횡단(traverse)할 수 있다. 레벨N 에서 태그 캐시 미스의 경우, 특정 메모리 액세스를 위해 노드를 태그 캐시의 다른 레벨에 삽입함으로써 트리 또는 계층이 횡단될 수 있다. 태그 캐시의 병렬 검색을 위한 레벨 캐시 미스와 관련하여, 실시예는 태그가 있을 때 레벨 캐시에 노드를 삽입하는 것만을 선택할 수 있다. 따라서 일부 레벨 캐시가 태그를 제공하므로, 다른 모든 레벨 캐시가 NO TAG 엔트리를 갖는 것은 필요하지 않다.
본 명세서의 다른 곳에서 논의된 바와 같이, 메모리 위치의 태그는 수정될 수 있다. 메모리 위치의 태그를 수정하는 것에 응답하여, 메모리 위치에 대한 태그 값을 특정하는 계층을 적절히 업데이트하는 처리가 수행될 수 있다. 이러한 업데이트는 더 이상 동질이 아닌 계층의 임의의 하나 이상의 레벨을 무효화하는 것을 포함할 수 있다. 또한, 따라서 예컨대 도 82의 예(150)에 도시된 바와 같이 캐시 레벨을 적절하게 업데이트하는 처리가 수행될 수 있다.
메모리 위치의 태그를 설정 또는 초기화하는 동작을 수행할 때, 그러한 처리는 원하는 동작을 수행하는 유효성에 대해 PUMP 검사를 포함할 수 있다. 예를 들어, 메모리 영역 내의 모든 메모리 위치를 새로운 태그로 다시 태깅하는 경우를 고려해 본다. 처리는 영역 내의 모든 메모리 위치의 현재 태그 값을 획득하는 것 및 재태그(retag)의 유효성을 PUMP 처리를 통해 체크하는 것을 포함할 수 있다. 허용된다면, 처리는 영역 내의 메모리 위치의 태그를 클리어하는 것 및 허용된다면, 그 다음에는 영역 내의 메모리 위치에 대한 태그 값을 갱신하는 것을 포함할 수 있다. 위의 논의와 일관하여, 메모리 영역의 태그를 업데이트, 수정 또는 설정하는 것은 메모리 영역 내의 상이한 메모리 위치에 대한 태그 값을 반영하도록 계층 및 연관된 노드를 수정하는 것(예를 들어, 수정 이전에는 동질이고 수정 이후에는 동질이 아닌 영역의 부분을 분해하는 것, 그리하여 태그 값 수정(들)을 반영하기 위해 추가된 부가적인 자식 또는 자손 노드가 있을 수 있는 것)을 포함할 수 있다.
적어도 하나의 실시예에서, 메모리 영역에 대한 태그 값의 계층적 표현은 트리일 수 있다. 예를 들어, 트리는 각 노드가 0, 1 또는 2 자식을 갖는 이진 트리일 수 있다. 변형예로서, 계층적 표현은 트리일 수도 있지만 이진 트리가 아닐 수도 있다. 예를 들어, 트리의 각 노드는 임의의 적절한 수의 자식 노드를 특정된 최대치까지 갖도록 허용될 수 있다. 계층적 표현은 임의의 적절한 수의 레벨, 각 레벨의 노드, 부모 노드 당 자식 등을 포함할 수 있다. 관련 기술분야에 공지된 바와 같이, 깊이 또는 레벨의 수 및 각 레벨에서의 노드/부모 노드 당 자식의 수와 같은 계층적 표현의 다양한 파라미터들 사이에서 상쇄관계가 있다. 예를 들어, 각 레벨에서 노드 수가 많을수록, 메모리 위치에 대한 태그 값을 결정할 때 레벨의 수는 적어지고 따라서 참조될 시간/레벨의 양이 단축된다. 그러나, 이러한 경우, 영역을 클리어하기 위해 더 많은 기입이 수행되어야 한다.
이제 본 명세서에서의 기술에 따른 실시예에서 CFI 정책과 관련하여, 로더 코드의 결과로서 트리거되는 규칙에 의해 수행될 수 있는 기술이 설명될 것이다. 태그 정보에 액세스하는 메타데이터 처리 규칙을 사용하여 CFI 정책을 시행하려면, 허용 가능한 제어 흐름과 관련된 정보가 메타데이터 처리 도메인에 전달되어야 한다. 이를 위해, 본 명세서에서의 기술에 따른 실시예는 다음 단락에서 설명된 접근법을 사용할 수 있다. 일반적으로, 제어의 이전은 분기 소스로부터 타깃 또는 목적지로 이루어진다. 허용 가능한 제어 흐름과 관련하여, 특정 제어 흐름 타깃 또는 목적지에 대해, 특정 제어 흐름 타깃 또는 목적지로 제어의 이전이 허용되는 소스들의 세트가 식별될 수 있다. 각각의 가능한 제어 흐름 타깃에 대한 소스들의 세트는 저장된 메타데이터 태그 정보와 같은 메타데이터 처리 도메인으로 전달될 수 있으며, 그리고 나서 사용자 코드(예를 들어, 코드 실행 도메인 또는 비-메타데이터 처리 도메인에서 실행되는 코드)의 런타임 실행 동안 CFI 정책 시행과 관련하여 CFI 정책의 규칙에 의해 사용될 수 있다.
수행되는 처리는 각 소스를 고유하게 태깅한 다음, 그 특정 타깃에 제어를 이전하도록 허용된 허용 가능한 소스들의 세트(예를 들어, 소스들의 어드레스)로 각 타깃을 태깅하는 것을 포함할 수 있다. 예를 들어, 도 83이 참조된다. 예(1700)에서, 요소(1701)는 코드 실행 또는 비-메타데이터 처리 도메인에서 실행되는 애플리케이션의 명령어의 코드 부분을 나타낼 수 있다. 요소(1702a 및 1704a 내지 1704c)는 코드 부분의 명령어의 위치를 나타낸다. 요소(1702a)는 제어 흐름 타깃 A를 나타낸다. 요소(1704a 내지 1704c)는 제어를 타깃 A1(1702a)에 이전하도록 허용된 제어 흐름 소스를 나타낸다. 이러한 (1704a 내지 1704c) 각각으로부터 이러한 제어 이전은 JMP(점프) A 명령어로 표시된다. 요소(1706)는 제어를 타깃 A로 이전하도록 허용되는 허용 가능한 소스들의 세트를 나타낸다. D7은 명령어(1704a)의 고유 소스 태그를 나타낸다. C3은 명령어(1704b)의 고유 소스 태그를 나타낸다. E8은 명령어(1704c)의 고유 소스 태그를 나타낸다. (1710)으로 도시된 바와 같이, JMP(점프) 명령어(1704a 내지 1704c)는 각각 D7, C3 및 E8로서 태깅된다. 또한, (1710)으로 도시된 바와 같이, 명령어(1704a 내지 1704c)는 각각 어드레스(1020, 1028 및 1034)에 저장된다. 타깃 위치 A는 어드레스 800을 갖는다. 이 경우에, 허용 가능한 소스 세트 또는 타겟 A로 제어를 이전하도록 허용된 소스 명령어의 어드레스는 (1706)으로 표시된 세트 {1020, 1028, 1034}일 수 있다. 따라서, 세트(1706)는 허용 가능한 메타데이터 처리 도메인으로 전달되어야 하는 허용 가능한 제어 흐름 정보의 예이며, 메타데이터 처리 도메인에서 이러한 허용 가능한 제어 흐름 정보는 CFI 정책의 규칙에 의한 사용을 위해 태그 메타데이터로서 저장된다. 본 명세서에서의 기술에 따른 적어도 하나의 실시예에서, 로더의 코드는 애플리케이션에 대한 CFI 정책이 코드 부분(1701)에 대한 CFI 정책을 시행하기 위해 메타데이터 처리 도메인에 의해 필요한 제어 흐름 정보를 수집하는 처리를 수행하는 규칙을 발동시킬 수 있다. 로더 코드는 애플리케이션을 로딩하는 것(예를 들어, 애플리케이션에 필요한 실행 코드를 로드하는 것)과 관련하여 실행되고, 이에 따라 로더 코드는, 애플리케이션을 로드하기 위해 실행하면서, (애플리케이션의 실행 동안 메타데이터 처리에 의해 나중에 CFI 정책을 시행하기 위해 사용되는) 제어 흐름 정보를 수집하는데 필요한 처리를 수행하는 규칙을 트리거한다.
본 명세서의 다른 곳에서의 설명과 일관하는 적어도 하나의 실시예에서, 커널 코드의 실행은, 실행될 때, (예를 들어, 소스 태그 D7, C3 및 E8을 발생하는) 소스에 태깅하는데 사용되는 소스 태그의 시퀀스(시퀀스의 각 태그는 고유함)를 발생하는 규칙을 트리거하는 로더의 태깅된 명령어를 인에이블하는 특수 명령어 태그로 로더의 코드를 태깅하는 규칙을 트리거할 수 있다. 예를 들어, 로더의 코드를 실행한 결과 발동된 규칙에 의해 수행되는 로직 처리를 포함하는 도 84가 참조된다. 로직 처리는 이러한 처리가 A(1702a)와 같은 각 제어 흐름 타깃에 대해 수행될 수 있는 C-유사 의사 코드 서술을 사용하여 (1720)에 설명된다. 단계(1721)에서, 소스 세트는 비어 있는 세트로 초기화된다. 단계(1722)에서, 제어를 타깃에 이전하도록 허용된 각각의 소스에 대해, 단계(1723, 1724 및 1725)가 수행될 수 있다. 단계(1723)에서, t는 새로 할당된 CFI 소스 태그를 할당 받는다. 단계(1724)에서, (타깃에 제어를 이전하는 명령어의) 소스 위치는 단계(1723)에서 생성된 새롭게 할당된 태그 t로 태깅된다. 단계(1725)에서, 소스 세트는 또한 태그 t를 포함하도록 업데이트된다. 일 양태에서, 단계(1725)의 동작은 각 소스에 대해 수행되는 바와 같이, (1722)에서 시작하는 루프 처리의 매 반복마다 (1725)에서 합집합 연산이 수행되는 타깃에 대해 허용 가능한 소스들의 세트의 합집합을 형성하는 것으로 특징지을 수 있다. 단계(1726)는 타깃을 소스 세트로 태깅하거나 마킹한다.
요소(1723)는 새로운 CFI 소스 태그를 발생하거나 할당하는 규칙을 트리거하는 로더 코드에 포함된 다음의 명령어일 수 있다:
여기서 (RISC-V 명령 세트 내의 ADDI와 같은) ADD 명령어는 커널 코드에 의해, 이 명령어를 허용 가능한 태그 발생기 명령어로서 마킹하는 CFI-alloc-tag의 특수 CI 태그로 태깅되어 있다. 적어도 하나의 실시예에서, 소스 태그의 상이한 시퀀스는 CFI 정책과 관련하여 로더에 의해 각각의 애플리케이션에 대해 발생될 수 있다(예를 들어, 예(1620)에서, 로더는 애플리케이션에 대한 CFI 소스 태그의 고유 시퀀스로서 CFI 태그(1630)의 상이한 시퀀스를 사용할 수 있고, 이 애플리케이션에서 CFI 태그의 시퀀스는 (1627)의 CFI 태그 발생기 App-n 태그들 중 특정 태그로부터 생성될 수 있다). CFI-alloc-tag는 ADD 명령어가 애플리케이션-특정 CFI 시퀀스에서 다음 태그를 할당하거나 발생할 수 있음을 나타내는 위의 로더 ADD 명령어에 배치된 CI 태그이다. CFI-alloc-tag는 예(1620)과 관련하여 설명된 바와 같이 (1624)의 특수 명령 타입 중 하나일 수 있다. 위의 ADD 명령어는 R1상의 태그가 상태가 이전에 생성된 시퀀스의 마지막 태그일 수 있는 CFI 시퀀스의 상태를 유지함을 나타낸다. 위의 ADD 명령어를 실행하면 CFI 시퀀스에서 다음의 새로운 태그를 발생하고 R1상의 태그를 새로 발생된 태그로 업데이트하는 규칙이 트리거된다. 본 명세서의 다른 곳에서 설명된 바와 같이 규칙 관행을 사용하면, 다음과 같은 ADD 규칙이 위의 ADD 명령어에 의해 트리거된 규칙임을 나타낼 수 있고:
이것은 ADDI 명령어에 대한 CI 태그가 CFI-alloc-tag임을 보장한다. 이러한 ADD 규칙에서, t1은 시퀀스의 다음 태그인 t1next를 발생하는데 사용되는 (애플리케이션의 CFI 태그 시퀀스의 현재 상태로서 저장된) 시퀀스의 이전 태그를 나타내며, 여기서 이후 t1next는 RD(목적지 또는 결과 레지스터)에 대한 태그로서 저장된다. CFI 시퀀스의 전술한 태그, t1next는 소스 포인트에 배치된 고유한 CFI 소스 태그로 사용될 수 있다.
요소(1724)는 소스 위치를 고유한 CFI 소스 태그로 태깅하는 규칙을 트리거하는데 사용되는 아래의 ST(스토어) 명령어와 같은 로더 코드의 명령어일 수 있고:
여기서 R3은 태깅되는 사용자 프로그램 코드의 제어 흐름 소스 위치(예를 들어, 예(1700)의 (1704a))를 가리키는 포인터이고, R1상의 태그는 소스 위치에 배치될 고유 CFI 소스 태그이다. 위의 ST 명령어는 또한 ST 명령어가 아래의 로더 코드 트리거링 규칙 ST에 포함되어 있음을 나타내는 CI-LDR과 같은 특수 CI 태그로 태깅할 수 있고:
여기서 CI tag=CI-LDR이고, t1은 R1상에 태그로서 현재 저장된 CFI 소스 태그이고, codetag는 어드레스 R3에 있는 소스 위치상의 명령어 태그이다(예를 들어, 소스 위치가 현재 코드로서 태깅된 것을 보장하는 태그이다). 결과적으로, 목적지(R3)는 t1, 즉 고유한 CFI 소스 태그로 태깅된다.
요소(1725)는 아래의 ADD 명령어와 같이, 소스의 어드레스(예를 들어, R3가 현재 가리키고 있음, R3는 소스의 어드레스를 포함함)를 타깃으로 제어를 이전할 수 있는 허용 가능한 소스 위치를 나타내는 CFI 소스 태그들의 누적 세트에 가산하는 규칙을 트리거하는데 사용되는 로더 코드의 명령어일 수 있으며:
여기서 R2상의 태그는 허용 가능한 소스 위치들의 누적 세트를 나타내는 메모리 위치를 가리킨다. 위의 ADD 명령어는 특수 CFI UNION 명령어 태그로 태깅되어, 이 ADD 명령어가 CFI 소스의 합집합 연산을 수행하는 것이고 합집합은 R2상의 태그로서 저장됨을 나타낼 수 있다. 위의 ADD 명령어의 결과로서 ADD에 대한 다음의 규칙이 발동될 수 있으며:
이것은 CI 태그가 CFI UNION이고, tset이 타깃 세트이며, tsrc가 소스 태그임을 보장하기 위해 체크한다. 이 규칙은 tset에 tsrc를 가산함을 나타내는 새로운 CFI 세트, tunion, 을 생성한다.
요소(1726)는 아래의 ST 명령어와 같이, 타깃에 제어를 이전할 수 있는 허용 가능한 소스 위치들의 합집합 또는 누적된 리스트로 타깃을 태깅하는 규칙을 트리거하는데 사용되는, 로더 코드의 명령어일 수 있다:
R17은 타깃 위치의 어드레스를 포함하는 레지스터일 수 있고, R2는 위에서 언급한 바와 같이 허용 가능한 소스 위치들 현재 누적된 세트의 합집합으로 태깅된 레지스터일 수 있다(예를 들어, R2상의 태그는 어드레스가 R17에 포함된 타깃 위치에 대해 허용가능한 소스 위치들의 세트를 나타낸다). 위의 ST 명령어는 이 명령어를 제어 이전 타깃 위치에 태깅하도록 허용된 특수한 명령어라고 표시하는 특수 명령어 태그 CFI MARK TARGET으로 태깅될 수 있다(예를 들어, (1720)의 처리를 수행하는 규칙을 트리거하는 로드 코드 명령어상의 다른 코드 태그와 유사한 방식으로, 로더 코드의 이러한 STORE 명령어(1726)는 커널 코드에 의해 태깅될 수 있다). (1726)에 대한 위의 STORE 명령어의 결과로서 다음의 ST 규칙이 트리거될 수 있으며:
이것은 CI 태그가 CFI MARK TARGET이고, 타깃(R17이 가리키고 있음, R17은 타깃 어드레스를 포함함)이 명령어를 나타내는 코드 태그로 태깅될 때 트리거하고, tset 주석을 타깃에 배치한다.
소스, 타깃 및 허용 가능한 소스 위치들의 세트와 함께 사용하기 위해 정의될 수 있는 다른 태그 구조체 또는 레이아웃은 본 명세서의 다른 곳에서뿐만 아니라 임의의 다른 적합한 구조체 정의에서 설명되어 있다(예를 들어, 임의의 명령어와 함께 더 일반적으로 사용될 수 있을 뿐만 아니라 태깅된 워드 당 다수의 명령어와 관련하여 더 일반적으로 사용될 수 있는 태깅된 소스 및 타깃 위치와 함께 사용하기 위한 태그 레이아웃을 설명하는 예(240, 250, 260, 267, 270 및 280)를 참고할 것).
따라서, 예컨대 예(1720)에서 위에서 설명된 처리 단계는, 이러한 로더 코드가 실행될 때, 예(1720)의 단계가 본 명세서에서의 기술에 따른 실시예에서 메타데이터 처리 도메인에 의해 수행되도록 하는 규칙이 발동되도록 로더의 코드를 적절하게 태깅함으로써, 수행될 수 있다. 명령어의 결과로서의 전술한 명령어 시퀀스 및 발동된 규칙은 본 명세서에서의 기술을 사용하는 실시예에서 사용될 수 있는 명령 및 규칙의 단지 하나의 예에 불과하다는 것을 알아야 한다. 예를 들어, 실시예는 위에서 설명된 바와 같은 처리를 수행하는 규칙(예를 들어, 요소(1725))을 트리거하는 로더 코드에 ADD 이외의 상이한 명령어를 포함시킬 수 있다.
전술한 설명에서, 특정 용어는 간결성, 명료성 및 이해를 위해 사용되었다. 이러한 용어는 설명의 목적으로 사용되며 폭넓게 해석되는 것으로 의도되기 때문에 선행 기술의 요구 사항을 넘어서는 불필요한 제한이 함축되지 않는다. 더욱이, 본 개시내용의 바람직한 실시예의 설명 및 예시는 예이며, 본 개시내용은 도시되거나 설명된 정확한 세부 사항으로 제한되지 않는다.
본 명세서에서 설명된 기술의 다양한 양태는 임의의 하나 이상의 상이한 형태의 컴퓨터 판독 가능한 매체 상에 저장된 코드를 실행함으로써 수행될 수 있다. 컴퓨터 판독 가능한 매체는 착탈 가능형 또는 비착탈 가능형일 수 있는 상이한 형태의 휘발성(예를 들어, RAM) 및 비휘발성(예를 들어, ROM, 플래시 메모리, 자기 또는 광학 디스크, 또는 테이프) 저장소를 포함할 수 있다.
본 발명은 도시되고 상세한 설명된 다양한 실시예와 관련하여 개시되었지만, 본 발명의 수정 및 개선은 관련 기술분야에서 통상의 기술자에게 쉽게 명백해질 것이다. 따라서, 본 발명의 사상과 범위는 다음의 청구범위에 의해서만 제한되어야 한다.
PUMP 프로그래밍
보안을 위한 하드웨어 지원형 마이크로 정책
요약
광범위한 보안 정책은 ISA 레벨의 메타데이터에 관한 규칙으로 공식화되고 프로그래머블 하드웨어에서 효율적으로 시행할 수 있다. 우리는 주요 계산과 함께 해석되지 않은 메타데이터에 관한 유연한 규칙 평가를 지원하는 PUMP(Programmable Unit for Metadata Processing) 아키텍처를 기초로 하는 이와 같은 정책에 대한 프로그래밍 모델을 자세히 설명한다. 우리는 네 개의 특정 영역 - 공간적 및 시간적 메모리 안전, 테인트 추적, 제어 흐름 무결성 및 프리미티브 타입 지정 - 에서 다양한 복잡성의 안전 및 보안 정책의 다양한 세트를 구현함으로써 모델의 일반성을 보여준다. 우리는 간단한 RISC ISA에 대해 이러한 정책의 성능을 단독으로 또는 조합하여 특징짓는다. 대부분의 정책에 대한 평균 런타임 오버헤드는 8 %일뿐이다. 이것은 PUMP 모델이 전용 하드웨어의 성능으로 소프트웨어 집행의 유연성과 적응성을 달성할 수 있음을 보여준다.
1. 소개
공격자가 텐트 안의 프로그램을 뒤엎는 것은 너무 쉽다. 프로세서가 수행하는 동작의 의도된 높은 레벨의 의미론에 관용적이도록 설계된 최신의 프로세서는 트랜지스터가 비싸며 기본 설계 목표가 런타임 성능이었던 기술 시대의 유산인, 이러한 상황에서 상충하고 있다. 컴퓨터 시스템이 점점 중요한 업무를 맡게 됨에 따라, 시스템 보안은 마침내 핵심 설계 타깃이 되었다. 동시에, 프로세서는 현재 그저 평범한 시스템-온-칩 다이와 비교하여 크기가 작아, 프로세서를 보안을 강화하는 하드웨어로 늘리는 것이 실현 가능하고 비용이 저렴하다. 내일의 컴퓨터들에 대해, 이들이 관리하는 데이터의 개인 정보 및 무결성을 적절하게 보호하기 위해, 우리는 전체 컴퓨팅 스택을 현대적인 위협 및 하드웨어 비용과 일관하는 보안 메커니즘으로 근본적으로 재구성해야 한다.
본 보안 문헌은 악의적이고 오류가 있는 코드로 인한 취약성을 줄일 수 있는 광범위한 런타임 정책을 제공한다. 이들 정책은 종종 고급 언어 추상화(이것은 숫자 배열이고, 이것은 코드 포인터이고, …) 또는 사용자 레벨 보안 불변성(이 문자열은 네트워크에서 온 것)을 프로그램의 데이터 및 코드상의 메타데이터 주석으로 인코딩한다. 높은 레벨의 의미론 또는 정책은 계산이 진행됨에 따라 이 메타데이터를 전파하고 적절한 지점에서 위반을 동적으로 체크함으로써 시행된다. 우리는 이러한 낮은 레벨의 미세 세밀화된 집행 메커니즘을 마이크로-정책(또는 비공식적으로는 그저 "정책")이라 부른다.
마이크로-정책의 소프트웨어 실현은 임의의 메타데이터 및 임의의 강력한 계산을 이들 이상으로 정의할 수 있다. 소프트웨어 구현은 새로운 정책의 신속한 배포를 용이하게 하지만, 런타임 및 에너지 비용의 측면에서 엄청나게 비싸서(1.5x 내지 10x) [42], 호의적이지 않은 보안 성능 상충 관계를 초래할 수 있다. 간단한 마이크로-정책은 오버헤드가 낮은 하드웨어에서 지원될 수 있다[41,?]; 그러나 단일 정책을 지원하기 위해 고객화된 하드웨어는 배포하는데 수년이 걸릴 수 있으며 적응하는 것이 느리다. 오늘날의 역동적인 사이버 공격 환경은 진화하는 위협에 신속한 현장 대응을 지원하는 메커니즘을 필요로 한다.
더 큰 유연성에 대한 바람은 최근에 정책 집행 하드웨어를 더 프로그램 가능하게 만드는 최근의 많은 노력을 촉발시켰다 [18, 45, 19, 13](§5 참조). 여기서, 우리는 임의의 메타데이터에 관해 세밀화된 명령어 계산의 관점에서 광범위한 낮은 레벨의 런타임 정책이 정의될 수 있게 하는 PUMP [7], "Programmable Unit for Metadata Processing"라고 불리는 설계를 고려한다. 하드웨어 레벨에서, 모든 데이터 워드는 워드 크기의 메타데이터 태그와 연관된다. 이러한 태그는 하드웨어에 의해 해석되지 않으며; 소프트웨어에서 태그는 유형, 출처, 분류 레벨 또는 정보가 첨부된 데이터의 신뢰성과 같은 정보 표현에 매핑될 수 있다. 태그는, 포인터를 표현할 만큼 충분히 크기 때문에, 여러 직교 정책이 병렬로 시행될 수 있게 하는, 메타데이터의 튜플을 비롯한 임의의 크기와 복잡성을 가진 데이터 구조체를 말할 수 있다. 프로그램 카운터는 프로그램의 제어 상태의 이력 추적을 지원하도록 태깅되며; 프로그램 코드는 코드 출처, 제어 흐름 및 구획화에 관한 정책을 지원하도록 태깅된다. 프로세서 코어는 명령어 실행과 동시에 고성능 규칙 분석을 가능하게 하는 규칙 캐시 및 이 캐시에서 룩업이 미스될 때 정책 처리 코드로의 신속한 컨텍스트 전환을 위한 특수 동작 모드로 늘어난다. 이것은 PUMP가 소프트웨어의 표현성과 적응성 및 하드웨어의 성능을 통해 광범위한 낮은 레벨 정책을 용이하게 시행될 수 있게 한다.
이 논문의 하나의 목표는 실제 위협에 대해 PUMP와 유사한 태깅 및 규칙 처리가 유용하다는 것 및 규칙의 형태로 정책을 작성하는 것이 쉽다는 것 둘 모두를 보여주는 것이다. 우리는 PUMP가 낮은 레벨의 보안 및 안전 정책의 다양한 모음을 지원하도록 프로그램될 수 있는 방법을 상세히 설명함으로써 이를 수행한다. 우리는 네 가지 정책 계열(모두 문헌에 나와 있음): (i) 약한 형태의 타입 안전(type safety)을 시행하는 프리미티브 타입; (ii) 공간적 및 시간적 메모리 안전, 캐싱 경계 및 힙-할당된 데이터에 대한 유저-애프터-프리(use-after-free) 에러; (iii) 코드-재사용(code-reuse) 공격을 방지하는 제어 흐름 무결성(CFI) [2]; (iv) 테인트 추적(taint tracing) - 여기서 테인트는 주어진 데이터 조각의 원인이 되었을 수 있는 데이터 소스 또는 컴포넌트를 나타낼 수 있음 - 의 상세한 구현 및 평가를 제시한다. 이러한 정책의 대부분은 현재 시스템이 소프트웨어에서 효율적으로 지원할 수 있는 것 이상이다. 마지막으로, 우리는 어떻게 이러한 정책이 동시에 적용될 수 있는지를 보여준다. 이러한 정책은 기존의 문헌에서 잘 연구되었기 때문에, 우리는 이들 정책이 제공하는 보안 보증에 주요 초점을 맞추지 않고, 그 보다는 정책이 규칙으로서 표현되고 PUMP를 이용하여 시행될 수 있는 방법을 탐구한다. 우리는 명령어 추적 시뮬레이션을 사용하여 PUMP가 단순한 순차 RISC 프로세서 (Alpha [1])에 첨부될 때 SPEC CPU2006 Benchmark Suite에 대해 이러한 정책이 미치는 런타임 영향을 예측한다. 우리는 PUMP가 광범위한 복잡성을 가진 정책을 지원하고 성능 영향을 정량화할 수 있음을 보여준다. 이 범위는 위협이 진화함에 따라 정책을 개선하는 기능과 이러한 진화가 어떻게 성능에 미칠 수 있는지를 예시한다.
본 논문은 금년 여름 늦게 워크숍에서 발표될 짧은 논문인 확장되고, 풍부해지고, 재조명된 [7]의 버전이다. 이전 논문은 PUMP를 RISC 프로세서에 직접 하드웨어 통합하는데 초점을 맞추고, 대부분의 벤치마크에 대해 합리적인 성능을 수립하고, 개선할 영역을 확인한다. 본 저작물에서, 우리는 [7]에서 잘 설명되어 있는 마이크로아키텍처적 고려 사항을 피하고, 대신 프로그래밍 모델 및 훨씬 더 상세한 설명과 정책 자체의 평가에 초점을 맞춘다. 우리는 또한 PUMP 소프트웨어 서비스가 어떻게 남용으로부터 스스로를 보호하는지를 설명한다. 우리가 보고하는 성능은 (i) opgroup의 사용(§2), (ii) 미스 비용의 보다 정확한 추정(§3) 및 (iii) 필요할 때만 포인터 태그를 사용함으로써 DRAM 액세스의 저감(§4)으로 인해 [7]을 개선한다.
요약하면, 본 저작물의 주요 기여 사항은 (i) 이 아키텍처에 의해 지원되는 정책을 간결하고 정확하게 설명하기 위한 프로그래밍 모델 및 지원 인터페이스 모델 (§및 §3); (ii) 잘 연구된 정책의 네 가지 다양한 클래스를 사용하여 정책 인코딩 및 구성에 대한 상세한 예; (iii) 이들 정책에 대한 요건, 복잡성 및 성능의 정량화 (§4)이다. §5 및 §에서, 우리는 관련 있는 그리고 향후의 작업에 대해 논의한다. 몇 가지 추가 자료는 http://git.io/8K7IKA에서 익명으로 입수 가능하다. 이들 자료는: 연구된 정책에 대한 완전한 정의가 있는 부록인, 우리 실험의 소스 코드 및 익명화된 버전의 [7]을 포함한다.
2. 정책 프로그래밍 모델(POLICY PROGRAMMING MODEL)
PUMP 정책은 태그 값들의 세트와 함께 이러한 태그를 조작하여 어떤 원하는 추적 및 집행 메커니즘을 구현하는 규칙들의 모음으로 구성된다. 규칙은 시스템의 소프트웨어 계층(상징적 규칙) 또는 하드웨어 계층(구체적 규칙)에 관해 우리가 이야기하고 있는지에 따라 두 가지 형태로 나온다.
예제.
PUMP의 동작을 설명하려면, 프로그램 실행 동안 리턴 포인트를 제한하기 위한 간단한 예제 정책을 고려해 본다. 이 정책의 동기는 return-oriented programming(ROP)[39]로 알려진 공격 클래스에서 비롯되는데, 이 공격에서 공격자는 공격 받고 있는 프로그램의 이진 실행 파일에서 "가젯(gadget)들"의 세트를 식별하고 이를 사용하여 스택 프레임들 - 각각에는 어떤 가제트를 가리키는 리턴 어드레스가 포함되어 있음 - 의 적절한 시퀀스를 구축함으로써 복잡한 악의적 거동을 모으며; 그런 다음 버퍼 오버플로우 또는 다른 취약점이 스택의 상단을 원하는 시퀀스로 오버라이트하도록 이용되어, 스니핏을 순서대로 실행되게 한다.
ROP 공격을 제한하는 간단한 하나의 방법은 리턴 명령어의 타깃을 잘 정의된 리턴 포인트로 제한하는 것이다. 우리는 유효한 리턴 포인트인 태깅 명령어를 메타데이터 태그 타깃으로 태깅함으로써 PUMP를 사용하여 이를 수행할 수 있다. 우리가 리턴 명령어를 실행할 때마다, 우리는 PC에 메타데이터 태그를 설정하여 리턴이 방금 발생했음을 표시하는 것을 체크한다. 다음 명령어 때, 우리는 PC 태그가 check인 것을 통보 받고, 현재 명령어상의 태그가 타깃인지를 검증하고, 그렇지 않으면 보안 위반을 신호로 알린다. 우리는 메타데이터를 더 풍부하게 만듦으로써, 우리가 어떤 리턴 명령어가 어떤 리턴 포인트로 리턴할 수 있는지 정확하게 제어할 수 있음을 이 섹션의 뒷부분에서 보여줄 것이다. 이것을 더 풍부하게 함으로써, 우리는 본격적인 CFI 체킹 [2](§4. 3 참조)을 구현할 수 있다.
상징적 규칙. 정책 디자이너와 PUMP의 소프트웨어 부분의 관점에서, 정책은 작은 도메인-특정 언어로 작성된 상징적 규칙을 사용하여 간결하게 설명된다. 각각의 상징적 규칙의 형태는 다음과 같으며:
이것은 규칙이 프로그램 카운터(PC)상의 메타데이터 태그, 현재 명령어(CI), 레지스터 파일로부터의 최대 두 개의 오퍼랜드(OP1, OP2) 및 만일 있다면, 명령어(MR)에 의해 참조되는 메모리 위치와 함께 명령어 opcode들의 세트(opgroup)에서 매칭한다고 말한다. 규칙은 모든 관련 태그 표현이 매칭하고 guard? 술부가 홀드한다면 적용한다. 이 경우, 오른쪽은 PC(PC')상의 태그 및 동작의 결과(R')상의 태그를 업데이트하는 방법을 결정한다. 대부분의 정책에서 규칙이 동일한 opcode가 많이 있을 것이기 때문에, 우리는 opcodes 대신 opgroup을 사용한다. 우리는 무시되는 입력 또는 출력 필드("와일드 카드")를 나타내기 위해 "-"을 기입한다. guard? 조건이 참일 때, 우리는 이것을 삭제한다.
방금 개요 설명한 간단한 ROP 정책에 대해, 우리는 opcode를 두 개의 opgroup - return(단지 단일 opcode만 포함) 및 
(나머지 모두) - 으로 분할하며; 가능한 태그 값은 check, target 및 
이다. PC는 항상 check 또는 
로 태깅될 것이며, 각 명령어는 target 또는 
로 태깅될 것이다. (명령어 태그는 신뢰성 있는 로더에 의해 공급된다; §참조). 상징적 규칙은 다음과 같다:
규칙 1에 따르면, 현재 동작이 return일 때 (그리고 PC가 이미 태깅된 check가 아닐 때), 우리는 PC상의 태그를 check로 변경한다. 우리가 PC 태깅된 체크(규칙 2)로 명령어를 실행할 때, 우리는 명령어 태그, CI가 target인지 체크하고; 그렇다면, 우리는 동작을 허용하고 PC상의 태그를 클리어한다. 현재 동작이 return이 아니고 PC 태그가 1이면, 우리는 그냥 진행한다(규칙 3). 규칙 4는 return의 유효 타깃이 return 자체인 특수한 사례를 처리한다. 어느 규칙도 적용되지 않으면, 동작은 허용되지 않다(예를 들어, configuration PC=check 및 CI=
은 허용되지 않는다). 우리는 상징적 규칙이 겹치지 않는다고 가정한다.
다음으로, 이 정책의 보다 정밀한 변형을 생각해 보는데, 이 정책에서 우리는 모든 return이 어떤 유효한 리턴 타깃에 도달할 뿐만 아니라, 이것이 실제로 호출될 수 있는 코드 포인트를 타깃으로 한다는 것을 보장한다. 이 정책은 컴파일러가 리턴 포인트에 대해 완전한 지식을 가지고 있고, 각 리턴 포인트에 대해, 어느 호출 사이트에 리턴할 가능성 있는지를 분석할 수 있다고 가정한다. 이 정보를 사용하여, 우리는 고유 태그를 각각의 return 및 각각의 잠재적 리턴 타깃에 첨부할 수 있다. return을 만났을 때, PUMP는 (일반 태그 check 대신) 명령어상의 태그를 PC에 카피한다(규칙 1' 및 4'). 다음 단계에서, 실제 리턴 포인트가 예상한 포인트들 중에 있는지를 체크하는데 - 즉, PC에서 CI 로의 리턴이 허용되는지 체크한다(규칙 2' 및 4').
이들 규칙에서, 우리는 X(컴파일러에 의해 제공된 코드 위치 식별자 쌍들의 세트)를 사용하여 코드 내의 return을 통해 허용된 간접 제어 흐름을 나타낸다. 여기에 알 수 있는 바와 같이, 상징적 규칙 내의 태그를 설명하는 표현식은 상수 값으로 제한되지 않는다: 우리는 태그들의 대형 세트를 간결하게 설명하는 보다 일반적인 표현식을 작성할 수 있다.
구체적 규칙.
상징적 규칙은 각종 메타데이터 추적 메커니즘을 간결하게 인코딩할 수 있다. 그러나 하드웨어 레벨에서, 우리는 기본 계산의 속도 저하를 피하기 위해 효율적인 해석을 위해 조정된 규칙 표현이 필요하다. 이를 위해, 우리는 구체적 규칙이라 불리는 하위 레벨 규칙 포맷을 도입한다. 직관적으로, 주어진 정책에 대한 각각의 상징적 규칙은 동등한 구체적인 규칙 세트로 확장될 수 있다. 그러나 단일의 상징적 규칙은 일반적으로 무한한 수의 구체적 규칙을 만들어 낼 수 있기 때문에, 우리는 이렇게 애써 만든 것을 느리게 수행하여, 시스템을 실행하는 동안 필요에 따라 구체적 규칙을 만든다.
PUMP 하드웨어는 프로세서의 ALU 동작과 병행하여 참조될 수 있는 구체적인 규칙의 캐시를 포함한다. 명령어가 발행될 때, 규칙 캐시는 캐시 내의 모든 구체적 규칙에 대하여 현재 머신 상태(현재 PC 태그, 현재 명령어의 오퍼랜드상의 태그 등)으로부터의 태그의 연상 매치(associative match)를 수행한다. 매치가 발견되면, 캐시는 PC에 대한 새로운 태그 및 명령어의 결과에 대한 태그를 리턴한다. 그렇지 않으면, 프로세서는 규칙 미스 핸들러 - 정책의 상징적 규칙을 참조하고 결함 있는 머신 상태가 진행하도록 허용되어야 하는지를 결정하는 소프트웨어 루틴 - 에 결함을 지워주고; 만일 그렇다면, 적절한 구체적 규칙을 발생하고, 이를 캐시에 설치하고, 결함을 유도한 명령어를 다시 시작한다. 그렇지 않으면, 적합한 보안 결함 핸들러(security fault handler)를 호출한다. 구체적 규칙의 일반적인 포맷은 다음과 같으며:
여기서 입력 및 출력 필드는 고정 태그이다. "guard?" 필드는 상징적 규칙 포맷 내의 필드가 필요하지 않다는 것을 알아야 하는데, 왜냐하면 미스 핸들러는 임의의 구체적 규칙을 캐시에 추가하기 전에 대응하는 조건을 체크하기 때문이다.
하나의 편리한 인코딩 트릭은 구체적 규칙 수를 크게 줄인다. 우리는 주어진 opgroup에 대한 모든 상징적 규칙이 특정 입력 또는 출력을 "와일드카드"로 마킹하는 것이 매우 일반적이라는 것을 관찰한다. 예를 들어, ROP 정책에서, return 및 
opgroup에 대한 규칙은 OP1, OP2 및 MR 입력에 매칭시킬 필요가 없으며, R' 결과를 생성할 필요가 없다. 미사용 입력 필드의 모든 가능한 값에 대해 구체적 규칙을 생성하지 않기 위해, 우리는 각 opgroup 및 입력 필드에 대해 don't-care 비트를 포함하는 비트 벡터를 정의하는데, 이것은 대응하는 태그가 규칙 캐시 룩업에 실제로 사용되는지를 결정한다. 유사하게, don't-care 벡터는 디폴트 태그가 리턴된 미사용 출력을 마킹한다(아래에서는 이것을 위해 
를 사용한다).
예를 들어, ROP 정책의 경우, 
opgroup이 OP1, OP2, MR 및 R1'에 대해don't-care 비트 세트를 갖기 때문에, 컴파일러가 t1으로 태깅된 리턴 명령어가 코드의 유일한 리턴임을 알고 있고 t2 및 t3로 태깅된 리턴 타겟에만 리턴할 수 있다면, 규칙 2'는 단지 두 개의 구체적 규칙만 갖는다.
"don't-care" 위치는 
로 마스킹되었다. 다른 한편, 상징적 규칙 3'은 네 개의 구체적 규칙에 대응한다:
CI는 
에 대한 "don't-care" 위치가 아니기 때문에 (규칙 3''은 CI를 와일드카드로서 마킹하지만, 규칙 2'는 그렇지 않으며 두 규칙은 모두 동일한 opcode에 관한 규칙임), 우리는 각각의 가능한 값마다 각기 취할 수 상이한 구체적 규칙을 얻는다 - 
및 모든 식별자(이 예에서는 단지 t1, t2 및 t3).
opcode로부터 opgroups 및 don't-care 벡터로의 매핑은 프로그램 가능하다. ROP 정책은 두 개의 opgroup(return 및 
)만 사용하지만, 다른 정책은 더 많이 필요할 수 있는데; 예를 들면, 프리미티브 타입 정책(§4.1)은 열 개를 사용한다.
구조화된 태그. ROP보다 풍부한 메타데이터 태그를 갖는 정책의 경우, 상징적 규칙으로부터 구체적 규칙으로의 변환은 동일한 일반 라인을 따르지만 세부 사항은 조금 더 복잡해진다. 예를 들어, 테인트 추적 정책(§4. 4}은 태그를 메모리 데이터 구조체를 가리키는 포인터로 사용하며, 각각의 메모리 데이터 구조체는 (주어진 단편의 데이터에 기여했을 수 있는 데이터 소스 또는 시스템 컴포넌트를 나타내는) 임의의 크기의 테인트 세트를 서술한다. 로드 opgroup에 대한 상징적 규칙은 로드된 값 상의 테인트가 명령어 자체, 로드의 타깃 어드레스 및 그 어드레스에서의 메모리 상의 테인트들의 합집합이어야 한다고 말한다:
어떤 순간에, (i) 실행될 다음 명령어가 Id r0 r1이며 그의 태그가 tci이고, 레지스터 r0가 세로 태깅된 포인터 p 를 포함하며, 어드레스 p에서의 메모리가 
로 태깅된 값이고; (ii) tci가 집합{TA, TB}을 나타내는 데이터 구조체(이를 테면, 테인트 id의 어레이)를 가리키고; (iii) tp가 {TC, TD}의 표현을 가리키고; 및 (iv) 
가 비어 있는 세트를 가리킨다고 가정해 본다. 또한, 이전에 테인트 {TA, TB, TC, TD}가 발생하지 않았다고 - 즉, 우리가 로드의 결과를 테인트하는데 사용해야 하는 세트를 나타내는 데이터 구조체가 현재 메모리에 없다고 - 가정한다. 이 경우, 규칙 캐시 룩업은 미스일 것이고 실행은 규칙 미스 핸들러에 결함을 일으킬 것이며, 이것은 적절한 구체적 규칙을 발생하고 이를 캐시에 설치할 것이며, 아마도 다른 규칙을 없애버려 공간을 만들 것이다. 이렇게 하면 (예를 들어, 어드레스 tnew에서) 새로운 메모리를 할당해야 하고, 이를 초기화하여 {TA, TB, TC, TD}를 표현해 주어야 한다. 그러면 발생된 구체적 규칙은 다음과 같을 것이다:
명령어가 다시 시작된 후, 다음 캐시 룩업이 성공할 것이고, r1에 로드된 값은 tnew로 태깅될 것이다.
별개의 태그들의 수를 줄이기 위해 (그래서 규칙 캐시에 가해진 부담을 줄이기 위해), 메타데이터 구조체는 내부적으로 기본형으로 저장되고, 태그는 불변이기 때문에 공유는 완전히 활용된다(예를 들어, 세트의 원소들은 기본 순서로 제공되므로 세트는 공통의 프리픽스 서브세트를 공유하는 것으로 간결하게 표현된다). 더 이상 필요하지 않을 때, 이러한 구조체는 (예를 들어, 불요 정보 정리(garbage collection)에 의해) 되돌려질 수 있다.
복합 정책. 한 걸음 더 나아가서, 우리는 태그가 여러 컴포넌트 정책으로부터의 태그들의 튜플을 가리키는 포인터가 되도록 함으로써 복수의 직교 정책을 동시에 시행할 수 있다. (일반적으로, 복수의 정책은 직교하지 않을 수 있고; 우리는 §6의 이 시점으로 되돌아 간다.) 예를 들어, 방금 스케치한 테인트 추적 정책이 있는 제 1 ROP 정책을 구성하기 위해, 우리는 각 태그를 튜플{r, f}의 표현을 가리키는 포인터로 놓을 것이며, 여기서 r은 ROP 태그(코드 위치 식별자 또는 
)이고, t는 테인트 태그(테인트들의 세트를 가리키는 포인터)이다. 캐시 룩업 프로세스는 정확히 동일하지만, 미스가 발생할 때, 미스 핸들러는 튜플의 컴포넌트를 추출하고 상징적 규칙들 세트 모두를 평가하는 루틴으로 디스패치한다. 정책 모두가 적용되는 규칙이 있는 경우에만 동작이 허용되고; 이 경우 결과적인 태그는 두 서브-정책으로부터 생긴 결과를 포함하는 쌍을 가리키는 포인터이다.
명령어 수정자 및 임시 규칙. 일부 정책(예를 들어, 메모리 안전)에서는 새로운 태그가 동적으로 발생되어야 한다. 이 효과를 달성하는 하나의 방법은 수정자로서 무브(move)와 같은 명령어 상의 태그를 사용하여 새로운 태그의 요청을 정책 관리 시스템에 전달하는 것이다.
이것에 따르면 tpolicygen으로 태깅된 무브 명령어가 새로운 태그를 발생하라는 요청으로 해석된다. 결과인 tnewtag는 특정된 정책과 연관된 고유 태그이다. 명령어 상의 태그 tpolicygen은 이러한 서비스 요청에 대해 인가 또는 능력으로서도 또한 사용되고; 그 태그가 없으면, 호출하는 것이 불가능하며; 신뢰성 있는 로더는 특별히 지정된 코드 영역(예를 들어, §4.2 의 메모리 안전 정책에서 malloc 루틴)만이 이러한 태그로 주석을 달게 하는 것을 보장한다. "1"은 결과가 하드웨어 규칙 캐시에 영구적으로 저장되지 않는 임시 규칙을 나타낸다(모든 호출에서 변경되기 때문임).
태그를 초기화하기 위한 코드는 "정상 상태" 규칙을 무시해야 할 필요가 있을 수도 있다. 예를 들어, 메모리 안전 정책에서, malloc은 새로 할당된 메모리 영역의 태그를 초기화해야 한다. 표준 규칙은 포인터가 포인터와 매칭하도록 적절하게 태깅된 메모리 영역에만 기입될 수 있다는 것이다. 그러나 malloc은 새로 생겨난 태그를 새 영역의 각 워드에 기입하는 동안 이 규칙을 무시할 수 있게 해주어야 한다. 우리는 이것을 스토어 동작에 (malloc에서만 사용되는) 특수 수정자 태그를 제공함으로써 수행한다:
3. 정책 시스템 및 보호
정책 시스템은 각 사용자 프로세스 내에 별도의 메모리 영역으로 존재한다. 정책 시스템은 미스 핸들러, 정책 규칙 및 정책의 메타데이터 태그를 나타내는 데이터 구조체를 포함한다. 정책 시스템을 프로세스에 배치하면 기존의 유닉스 프로세스 모델(Unix process model)이 받는 침입을 최소화하고 정책 시스템과 사용자 코드 간의 가벼운 전환을 용이하게 한다. 정책 시스템은 다음에 설명되는 메커니즘을 사용하여 사용자 코드로부터 격리된다.
메타데이터 위협 모델. 분명히, 공격자가 메타데이터 태그를 다시 기입하거나 그 해석을 변경할 수 있다면, PUMP에 의해 제공되는 보호 기능은 쓸모가 없다. 우리의 시스템은 그러한 공격을 방지하도록 설계된다. 우리는 커널, 로더 및 (일부 정책의 경우) 컴파일러를 신뢰한다. 특히, 컴파일러에 따라 우리는 초기 태그를 워드에 할당하고, 필요한 경우, 정책 시스템에 규칙을 전달한다. 우리는 로더가 컴파일러에 의해 제공된 태그를 보존할 것이고, 컴파일러로부터 로더까지의 경로가 예를 들어, 암호화 서명을 사용하여 부당 변경하는 것(tempering)으로부터 보호되는 것으로 상정한다. 우리는 각 프로세스에 대해 초기 메모리 이미지를 설정하는 표준 유닉스 스타일 커널을 상정한다. (마이크로-정책을 사용하여 이러한 상정 중 일부를 없애고, 추가로 TCB의 크기를 줄이는 것이 가능할 수 있다 - §6.) 우리는 규칙-캐시-미스-처리 소프트웨어가 올바르게 구현되는 것으로 상정한다. 이것은 작으며, 그렇기 때문에 공식 검증을 위해서는 좋은 타깃이며; 최근의 저작물 [8]은 PUMP와 유사한 프로그래밍 모델에 대한 실행 가능성을 보여준다.
우리의 주된 관심사는 프로세스에서 실행 중인 사용자 코드가 프로세스의 정책에 의해 제공되는 보호를 훼손시키지 못하게 하는 것이다. 사용자 코드는 (i) 태그를 직접 조작할 수 없어야 하고 - 모든 태그 변경은 현재 적용되는 정책 규칙에 따라 수행되어야 하고; (ii) 미스 핸들러에 의해 사용된 데이터 구조체 및 코드를 조작할 수 없어야 하고; (iii) 규칙을 직접 하드웨어 규칙 캐시에 삽입할 수 없어야 한다.
어드레스 지정. 사용자 코드에 의한 태그의 직접 조작을 방지하기 위해, 모든 64b 워드에 첨부된 태그는 자체적으로 별도로 처리할 수 없다. 특히, 태그를 판독하거나 기입하기 위해 태그 또는 태그의 일부분에만 대응하는 어드레스를 특정하는 것은 불가능하다. 사용자가 접근 가능한 모든 명령어는 원자 단위로서 (데이터, 태그) 쌍 - 값 부분에 대해 동작하는 표준 ALU 및 태그 부분에 대해 동작하는 PUMP - 에 대해 동작한다.
미스 핸들러 아키텍처.
정책 시스템은 PUMP 캐시의 미스 시에만 활성화된다. 정책 시스템과 사용자 코드를 격리하기 위해, 우리는 미스(미스 핸들러) 동작 모드를 프로세서에 추가하고; 우리는 레지스터를 저장하고 복원하는 것을 피하기 위해, 미스 핸들러에만 이용 가능한 16 추가 레지스터로 정수 레지스터 파일을 또한 확장한다. 결함유도 명령어의 PC, 규칙 입력(opgroup 및 태그) 및 규칙 출력은 미스 핸들러 모드에 있는 동안 레지스터처럼 나타난다. 또한 우리는 캐시에 구체적 규칙을 설치하고 사용자 코드로 리턴하는 미스-핸들러-리턴 명령어를 추가한다.
프로세서가 미스-핸들러 모드에 있는 동안 PUMP의 정상 거동은 해제된다. 대신에, 단일의 하드와이어드 규칙이 적용된다: 미스 핸들러가 접촉한 모든 명령어 및 데이터는 모든 정책에 의해 사용된 태그와 구별되는 미리 정의된 미스-핸들러 태그로 태깅해야 한다. 이렇게 하면 동일한 어드레스 공간에서 미스 핸들러 코드와 데이터 및 사용자 코드 간의 격리가 보장된다. 사용자 코드는 정책 시스템 데이터 또는 코드를 접촉하거나 실행할 수 없고, 미스 핸들러는 우연히 사용자 데이터 및 코드를 접촉할 수 없다. 미스-핸들러-리턴 명령어는 미스-핸들러 모드에서만 발행될 수 있으므로, 사용자 코드가 규칙을 PUMP에 삽입하는 것이 방지된다.
4. 정책 및 실험
이 단원에서, 우리는 PUMP를 사용하여 다양한 세트의 보안 불변성을 시행하는 네 개의 정책 그룹을 구현하는 방법을 보여준다. 각 패밀리마다 우리는 먼저 위협 모델을 스케치한다. 그런 다음 우리는 이를 완화하는 정책 및 대응 규칙을 설명한다. 공개적인 취약성 모음 [10]의 예제를 사용하여, 우리는 각 정책이 전형적인 공격을 잡아내는 방법을 보여준다. 가장 중요한 것으로, 우리는 각 정책이 시스템에 가하는 부하를 설명한다. 우리는 문헌으로부터 유사한 정책과 비교함으로써 마감한다.
정책 부하를 평가하기 위해, 우리는 28 C, C++ 및 SPEC CPU2006 벤치마크 제품군의 Fortran 애플리케이션 [25]을 사용하고, 이를 64-비트 Alpha ISA [1]에 대해 gem5 시뮬레이션 환경 [9]에서 시뮬레이션한다(우리는 gem5가 실패한 tonto 및 xalancbmk 벤치마크를 제외한다). gem5 시뮬레이션은 PUMP를 직접 모델링하지 않고; 오히려 별도의 PUMP 시뮬레이터를 통해 실행되는 명령어 추적을 생성한다.
도 1:
정책 위반이 발생할 때 계산에 영향을 미칠 때만 실행을 중단하는 것이기 때문에, 이러한 단계적 시뮬레이션이면 여기서 설명된 정책에 충분하다. 우리는 4096-엔트리 프리-미스-핸들러(pre-miss-handler) 규칙 캐시를 시뮬레이션한다.
§2에서 설명된 추상 프로그래밍 모델은 소프트웨어 레벨에서 메타데이터를 표현하기 위해 사용된 고유 태그의 수, 구체적 규칙의 수 또는 데이터 구조체의 크기에 제한을 두지 않는다. PUMP가 실제로 어떻게 수행되는지 이해하기 위해, 다수의 문제가 고려되어야 한다. 고유 메타데이터 태그가 주어진 정책, 애플리케이션 및 데이터세트를 실제로 얼마나 많이 생성하는지? O opgroup 및 T 태그를 사용하면, 이론적으로 프로그램에 O＊T5 구체적 규칙이 필요할 수 있지만, 전형적인 사례에서는 얼마인가? 메타데이터 태그의 총 수 및 메타데이터 표현의 크기가 어떻게 성능에 영향을 주는지? 사용에 태깅하고 사용을 통제하는 지역성은 얼마나 되는지? 구체적 규칙 해결 결정에는 비용이 얼마나 들며, 규칙 캐시 미스가 성능에 얼마나 영향을 미치는지? 태그, 규칙, 메타데이터 크기 또는 규칙 해결 시간이 증가함에 따라 성능이 적절하게 저하되는지5?
이러한 결과의 이해를 시작하기 위해, 우리는 각 정책에 대해, 런타임 오버헤드 이외의 여러 특성을 측정한다 - 도 1 참조. Tag usage(태그 사용)은 태그가 정책 내의 임의의 규칙에 의해 사용되지 않는 것을 보여준다. Opgroups은 정책을 점하는데 필요한 opgroup의 최소 수이며; 우리가 사용하는 opgroup이 적을수록 구체적 규칙에 대해 우리가 얻는 압축은 더 크며 그래서 유효 PUMP 용량이 더 커진다. Symbolic rules(상징적 규칙)은 우리가 정책을 표현하기 위해 작성한 상징적 규칙의 수이다. Initial tags(초기 태그)는 실행을 시작하기 전 초기 메모리 이미지 내의 태그의 수이다. 실행 중에 더 많은 태그가 동적으로 할당된다(dyn.alloc.tags). 또한 테인트 추적과 같은 정책은 테인트 세트들의 합집합을 표현하는 태그를 생성할 것이며, 복합 정책은 개개의 정책 태그의 튜플을 형성할 것이다. Final tags(최종 태그)는 십억 명령어 시뮬레이션 기간의 종료시 존재하는 태그의 수를 식별한다; 이것은 정책 복잡성이라는 약간의 의미를 주며 태그 발생의 속도를 추론하는데 사용될 수 있다. Concrete rules(구체적 규칙), 이것은 시뮬레이션 기간 동안 생성된 고유한 구체적 규칙의 수로서, 상징적 규칙을 구체적 규칙으로 해결하는데 필요한 강제 미스 횟수 및 실질적으로는 강제 미스 레이트의 특징을 나타낸다. Metadata structure(메타데이터 구조체), 이것은 각 태그가 가리키는 데이터 구조체의 워드의 평균 크기로, 무한한 메타데이터를 갖는 값을 보여준다. Metadata space(메타데이터 공간), 이것은 메타데이터 태그가 가리키는 정책 관련 정보를 보유하는 모든 데이터 구조체에 필요한 워드의 수이며, 태그 자체를 초과하는 메모리 오버헤드의 특징을 나타낸다. Policy-depend instrs는 상징적 규칙을 구체적 규칙으로 해석하는 코드에 필요한 총 명령어 수이며; 이것은 정책의 복잡성을 이해하는데 유용하다. Policy-depend instrs(dynamic)은 상징적 규칙으로부터 구체적 규칙으로 해결하기 위해 실행되는 평균 수의 정책-종속적 명령어이고; 이것은 각 정책에 대한 미스 핸들러의 런타임 복잡성을 나타낸다. 정책-종속적 부분의 영향은 규칙의 복잡성, 메타데이터 데이터 구조체, 메타데이터 데이터 구조체의 지역성 및 새로운 결과 태그를 할당해야 할 필요성에 따라 달라진다. 미스 핸들러의 정책-독립적 부분은 수십 개의 명령어만을 필요로 한다(도 1의 열
참조). Runtime overhead(런타임 오버헤드)는 PUMP가 없는 베이스라인 Alpha와 비교하여 정책을 실행하는 애플리케이션의 벽시간(wall-clock) 런타임의 비율이다. 아무 정책도 사용되지 않더라도 태그 및 PUMP의 하드웨어 구조체의 추가 때문에 몇몇 런타임 오버헤드가 존재한다. 특히, 태그가 늘어난 프로세서상의 L1 캐시는 더 큰 태깅된 워드 폭을 수용하면서 동일한 사이클 시간을 달성하기 위해 PUMP없는 베이스라인 Alpha 유효 용량의 절반이다. 이로 인해 태그가 늘어난 프로세서의 L1 미스 레이트는 더 높아진다. 이러한 오버헤드는 제 1 열(
)에 담겨 있는데, 이 열에서 모든 태그는 디폴트이고, 단일 규칙이 존재하며, 미스 핸들러는 결코 효과적으로 호출되지 않는다.
도 1에서 평균 수치는 간결함을 위한 불가피한 단순화이다. 벤치마크는 다양한 결과를 보여준다. 결과는 SPEC CPU2006 벤치마크 세트에서 어플리케이션 전반의 특성 분포를 보여주기 위해 상자그림(boxplot)을 사용하는 도 3 내지 도 6에서 도시된다. 도 6은 
를 초과하는 런타임 오버헤드를 그래프로 도시한다.
우리는 다른 자명하지 않은 비용은 제쳐두고 런타임 성능만을 측정한다. 특히, 생무지의 구현에서, 워드-크기의 태그를 캐시 및 메모리의 모든 워드에 추가하면 최소 2x 배의 영역 오버헤드가 부과된다. PUMP 캐시의 영향과 더 큰 메모리의 영향을 추가하면, 에너지 오버헤드가 4x 배가 된다. 우리는 신중한 최적화를 통해 이러한 수치를 약 30 % 범위와 50 % 에너지로 줄이거나 심지어 더 낮게 줄일 수 있다고 낙관하며; 우리는 이 주장을 입증하기 위해 노력하고 있다.
4.1
프리미티브 타입
위협 모델.
데이터 오역은 프로세서가 의도하지 않은 동작을 수행하도록 하는 흔한 방법이다. 여기서 우리는 상대방을 대신하여 실행 중인 코드가 포인터로서 임의의 데이터 값을 사용하거나 명령어로서 워드를 실행하려고 시도할 수 있는 낮은-레벨 타입의 혼란(low-level type confusion)의 형태에 관심이 있다. 우리는 데이터가 실행될 수 없고 코드가 런타임에서 생성되거나 수정될 수 없게 시행한다(또한 §4.3참조).
정책 및 규칙. 정책(C)에서, 우리는 명령어(태깅된 insn), 어드레스(addr) 및 기타 모든 데이터(기타)를 분리하기 위해 태그를 사용한다. 명령어는 생성되거나 수정될 수 없고, 명령어만이 실행될 수 있다. 어드레스만이 메모리 액세스 명령어로 사용될 수 있다. 다른 타입 태그는 명령어 또는 어드레스가 아닌 워드의 포괄적 표현(catch-call)으로 사용된다. 다음의 규칙은 (예를 들면) nop가 실행되기 전에 실제로 태깅된 insn임을 입증한다:
어드레스 산술은 허용된다 - 예를 들어, 가산할 인수 중 하나가 어드레스일 때 결과는 어드레스이다:
또한 우리는 로드 및 스토어 명령어가 포인터만을 역참조하는 것을 시행하고 명령어를 판독하거나 기입하지 않는다:
리턴 어드레스가 (예를 들어, 스택 스매싱(stack smashing)을 통해) 오버라이트된 공격을 방지하기 위해, 우리는 리턴 어드레스에 제 4 태그(retaddr)를 추가하는 확장된 정책(D)을 고려한다. 우리는 이것을 호출의 리턴 어드레스에 태깅하는데 사용한다(규칙 9). Alpha ISA에서 호출은 리턴 어드레스를 reg26에 넣고, 반면에 리턴은 이 레지스터에 있는 어드레스로 제어를 이전한다(레지스터는 또 다른 호출시 스택으로 유출된다). 규칙 10은 리턴 명령어가 실행될 때 reg26 내의 값이 입력된 retaddr인지를 체크한다.
계기화된(instrumented) 컴파일러는 이러한 타입 태그를 추론하고 이를 초기의 이진 메모리 이미지에 적용할 수 있다 - 발생된 모든 명령어는 태깅된 insn를 갖고, 스택-할당된 메모리를 가리키는 포인터는 태깅된 addr을 갖고, 다른 것들은 달리 태깅되며; 새로운 addr이 타이핑된 워드가 동적 어드레스 할당을 통해 생긴다. 그러나 현재 우리는 이러한 컴파일러가 없기 때문에, 우리는 시뮬레이션 및 분석을 위해 이러한 태그를 추론하는 다른 방법을 사용한다. 먼저, 우리는 이진 실행 파일 insn에 있는 모든 명령어에 태깅한다. addr를 태깅해야 하는 워드를 추론하기 위해, 우리는 실행 추적에 대한 사후 분석을 사용하여, 언제 그리고 어디서 각 레지스터가 로드되고 이것이 나중에 로드 또는 스토어를 가리키는 포인터 오퍼랜드로서 사용되는지를 추적한다. 다른 모든 것은 달리 태깅된다. 초기 태그를 획득하는 이 방법은 우리에게 SPEC 벤치마크에서 타이핑 정책의 런타임 영향을 측정할 수 있게 해준다. 그러나 이 설정으로 우리는 우리의 타이핑 정책이 불필요한 경보를 발생시키지 않고 모든 벤치마크를 수용할 수 있을 만큼 충분한지에 대해서는 어떠한 주장도 할 수 없다. 이것은 타이핑에 필요한 타이트한 컴파일러 통합으로 인해 유발되며 우리가 아래에서 제시하는 다른 정책에서는 발생하지 않는다.
보호 데모.
우리는 프로그래머가 정수를 함수 포인터에 타입캐스트(typecast)하고 나중에 이 함수를 호출하는 CWE-843의 인스턴스(타입 혼동) [30]의 인스턴스를 사용한다. 이것은 다른 것으로 태깅된 즉치 값(immediate value)을 레지스터에 로드하고, 나중 시점에 그 레지스터가 가리키는 어드레스로 점프하는 것으로 변환한다. 정책(C)을 사용하여, 우리는 정책이 addr 태깅된 값으로 간접 점프만을 허용하기 때문에 결함유도 명령어를 잡아낼 수 있다.
특성. 정책(C) 및 (D)는 새로운 태그를 발생하지 않는다. (C)는 단지 17개의 구체적 규칙을 만드는 15개의 상징적 규칙을 가지고 인코딩될 수 있는 반면, (D)는 16개 상징적 규칙 및 19개 구체적 규칙을 필요로 한다. 규칙의 총 수가 적기 때문에, 우리는 미스-핸들러 없는 정책(A)와 비교하여 (0.01 % 미만의) 무시할만한 런타임 오버헤드만을 보여준다. 따라서, PUMP는 정책을 하드웨어로 굽지 않으면서, 간단하고 하드와이어드 타입의 태그 성능을 제공한다.
관련 저작물. 컴퓨터 아키텍처에서 태그의 제 1 용도 중 하나는 머신 내의 워드의 타입을 구별하는 것이었다 [34, 23]. Symbolics L1SP Machines [31]에서는 명령어, 포인터의 여러 플레이버(flaver), 정수, 부동 소수점 및 초기화되지 않은 값을 비롯한 한 세트의 프리미티브 타입을 구별하기 위해 36b 프리미티브 워드 중에서 태깅을 위한 2 내지 8b를 할당했고; Berkeley SPUR [43]에서는 6b 객체 타입 태그를 사용했다.
4.2 공간적 및 시간적 메모리 안전
위협 모델.
다음의 정책 그룹은 힙-할당된 데이터의 메모리 안전을 타깃으로 하여, 공격자가 객체의 경계(object's bound)(공간적 위반)를 넘어 참조하는 것, 영역이 프리로 만들어진 이후 포인터를 통해 참조하는 것 또는 유효하지 않은 포인터를 프리로 만드는 것(시간적 위반)과 같은 프로그래밍 오류를 악용하는 것을 방지한다. 이것은 힙 스매싱(heap smashing) 및 포인터 위조(point forging)와 같은 전형적인 힙 기반 공격을 포함한다. 여기서 우리가 연구하는 정책은 malloc 및 free로의 호출이 어떻게 메모리 영역을 설정하고 해체하는지를 알려주는 힙-할당된 데이터만을 보호하며; 우리는 스택 할당 또는 박스화되지 않은 데이터 구조(struct)는 다루지 않다. 이것들은 원칙적으로 일부 컴파일러 지원을 가정하여 처리될 수도 있다 ([32] 참조).
정책 및 규칙. 직관적으로, 각각의 새로운 할당에 대해, 우리는 새로운 블록 id, 소위 ("컬러"를 위한) c를 만들고, (memset와 같은 식으로) c를 새로이 생성된 메모리 블록의 각 메모리 위치상의 태그로서 기입한다. 새로운 블록을 가리키는 포인터는 또한 c로 태깅된다. 나중에, 우리가 포인터를 역참조할 때, 우리는 그 태그가 가리키는 메모리 셀상의 태그와 동일한지를 체크한다. 블록이 프리로 될 때, 블록의 모든 셀상의 태그는 프리 메모리임을 나타내는 상수 F로 변경된다.
우리는 비-포인터(non-pointer)에 대해 추가 태그 
를 사용하고, 태그에 대해 컬러 c 또는 
중 하나인 t를 기입한다. 우리는 하나의 부가적인 세부 사항을 처리한다 - 메모리 셀은 포인터를 포함할 수 있다. 그러므로 메모리 내의 워드는 두 개의 태그와 연관되어야 한다. 우리는 이것을 각 메모리 셀상의 태그를 쌍(c, t)을 가리키는 포인터로 만들어서 처리하며, 여기서 c는 이 셀이 할당된 메모리 블록의 id이고, t는 셀에 저장된 워드상의 태그이다. 로드 및 스토어에 대한 규칙은 각 메모리 액세스가 유효한지를 (즉, 액세스된 셀이 이 포인터가 가리키는 블록 내에 있는지를) 체크하는 것과 함께, 이들 쌍을 패킹 및 언패킹하는 일을 처리한다.
어드레스 산술 연산은 포인터 태그를 보존한다:
포인터 상의 태그가 할당에 의해서만 발생한다는 불변성을 유지하기 위해, 스크래치(scratch)로부터 데이터를 생성하는 (상수를 로딩하는 것과 같은) 동작은 태그를 
로 설정한다.
우리는 §2의 끝 부분에서 설명된 명령어 수정자 및 임시 규칙을 사용하여 메모리 영역에 태깅하는 malloc 및 free를 늘릴 수 있다. malloc에서, 우리는 임시 규칙을 통해 새로운 영역을 가리키는 포인터에 대한 새로운 태그를 발생한다. 그런 다음 우리는 태깅된 포인터를 리턴하기 전에 새로 태깅된 포인터를 사용하여 특수 스토어 규칙을 사용하여 할당된 영역 내의 모든 워드에 0을 기입한다.
반대로, free는 메모리 영역을 프리 리스트에 리턴하기 전에 수정된 스토어 명령어를 사용하여 영역을 할당되지 않은 것으로 다시 태깅한다:
우리는 이 정책의 몇 가지 변형예를 구현하여, 성능/보안의 상쇄관계를 설명한다. 제 1 (E)에서, 우리는 주어진 소스 모듈에 의해 할당된 모든 메모리 영역에 단일 컬러를 할당한다. 이러한 샌드박싱 정책은 소프트웨어 기반 결함 격리(software-based fault isolation) [46]와 유사한, 프로세스 내에서 모듈 별 격리를 제공한다. 다음 변형예에서, 우리는 - 그저 단일 컬러 (F)로 된 - malloc으로의 연속 호출에 의해 리턴되는 영역에 태깅하기 위해 상이한 수의 컬러를 사용하는데 - 이것은 가장 약한 형태의 공간적 및 시간적 메모리 안전을 제공하여, 할당되지 않은 메모리로부터 할당된 것을 - 8 (G) 및 32 (H) 컬러까지만 구분할 뿐이다. 컬러 수를 늘리면 컬러의 재사용으로 인해 발생하는 앨리어싱 효과가 줄어든다. 마지막으로 우리는 컬러에 필요한 전체 64-비트 태그 공간을 사용하여, 정확한 전체 메모리 안전 정책(I)을 구현한다.
보호 데모. 우리는 Juliet 제품군 [10]로부터의 두 개의 공격을 사용한다. 제 1공격은 CWE-416(Use After Free) [28]의 사례이며, 이 경우 애플리케이션은 정책 (I)를 사용하여 메모리 위치 태깅된 F로부터 로드하려는 시도를 잡아낸다. 제 2공격은 버퍼가 할당되고 나중에 (strcpy를 사용하여) 그의 경계를 넘어 기입하여, 유효한 영역을 오버라이트하는 CWE-122(Heap-Based Buffer Overflow) [27]의 사례이다. (I)를 사용하여, PUMP는 문자를 태깅된 F의 메모리 위치에 넣으려 시도하는 명령어를 중지시킨다.
특성.
샌드박싱(E) 및 컬러 수가 적은 정책 (F), (G) 및 (H)은 소수의 태그만을 할당하고 적은 수의 규칙(32 컬러의 경우 600 미만)만을 만든다. 이것들은 런타임 오버헤드를 추가하지 않다 - 규칙은 모두 캐시에 딱 맞는다. 전체 메모리 안전 (I)은 더 비싸다: 이것은 메모리 할당 당 하나의 태그를 할당하는 것이고, 이 때문에 새로운 규칙이 캐시에 추가되어야 한다. 이것은 미스 핸들러를 통해 더 많은 트립을 필요로 하며 일부 벤치마크에서, 구체적 규칙 세트가 캐시보다 크다는 것을 의미한다. 그럼에도 불구하고 규칙 지역성은 높으며(도 7 참조), 평균 런타임 오버헤드는 13 %에 불과하다. 우리는 GemsFDTD에 대해 약 130 %의 최대 오버헤드를 목격할 수 있다.
관련 저작물. Clause 등 [16]은 처음으로 메타데이터 테인팅을 사용하는 공간적 및 시간적 메모리 보호를 실증하였다. Deng 등 [19, 20]은 이러한 테인팅을 하드웨어 태그 관리로 지원했다. HardBound [21]는 모니터링된 코드와 모니터링되지 않은 코드 사이의 데이터 구조체 레이아웃 호환성을 유지하기 위해 경계 정보를 그림자 공간에 배치하는 공간 메모리 안전에 대한 접근법이다. HardBound의 런타임 오버헤드는 10 내지 20 %이다. Watchdog [32]은 각 할당에 대해 고유 식별자를 생성함으로써 시간적 위반을 부가적으로 방지하는 HardBound의 후속 조치이고; 평균 런타임 오버헤드가 24 %이다. SoftBound [33]는 HardBound처럼, C에 대한 공간 메모리 안전을 제공하는 소프트웨어 접근법이지만, 런타임 오버헤드의 비용이 증가한다(SPEC 및 Olden 벤치마크에서 67 %). Baggy Bounds [3]는 또한 공간 위반만을 타깃으로 하며 SPEC2000에서 60 % 런타임 오버헤드를 달성한다.
4.3 제어-흐름 무결성
위협 모델. 이 정책 그룹은 코드-재사용(code-reuse) 공격을 타깃으로 한다. 우리는 공격자가 데이터를 실행하거나 코드를 주입 또는 수정할 수 없다는 표준 가정 [2]을 만든다. (우리는 우리의 작성된 정책을 가지고 §5에서 하는 것과 같이, §1의 프리미티브 타입 정책을 사용하여 이 가정을 시행할 수 있다). 그 대신, 공격자는 악의적 거동을 유도하기 위해 기존 코드 스니핏(가젯)들을 함께 묶으려 시도한다.
정책 및 규칙. 모든 코드-재사용 공격의 공통 요소는 원래의 이진 파일에 존재하지 않는 제어 흐름을 도입하는 것이다. 우리는 각각의 간접 제어 흐름(계산된 점프)을 프로그램의 제어 흐름 그래프에 대해 입증하는 CFI 정책 패밀리를 구현한다. 코드가 고정되어 있기 때문에, 직접 점프를 동적으로 검사 할 필요가 없다 [2]. 먼저 우리는 [2, 51] (J), (K) 및 (L)의 저급의 CFI 정책을 구현한다. (J)는 모든 간접 호출, 간접 점프 및 리턴 명령어와 이들의 잠재적 타깃을 단일 태그{f}로 태깅한다. 간접 제어 흐름의 소스인 명령어를 실행하면, 우리는 이 태그를 PC로 이전한다.
다른 모든 명령어는 Ø로 태깅된다. PC가 {f}로 태깅될 때마다, 현재 명령어는 동일한 태그를 가져야 한다:
정책 (K)는 리턴(이들의 태그에는 r이 포함되어 있음)로부터 비롯하는 제어 흐름을 간접 호출 및 점프(이들의 태그에는 c가 포함되어 있음)로부터 비롯하는 제어 흐름으로부터 분리하여 추적하기 위해 더 많은 태그(Ø, {r}, {c} 및 {r, c})를 사용한다. 정책 (L)은 권한이 있는 코드(이들의 태그에는 p가 포함되어 있음)로 리턴하기 위한 두 개의 추가 태그 ({p}및 {p, c})를 가진 (K)로 확장하여, 중요한 코드 스니핏에 대해 추가 보호를 가능하게 한다 [51].
Goktas 등 [22]에서 볼 수 있는 바와 같이, 이러한 느슨한 CFI 정책은 정교한 코드-재사용 공격에 대해 충분한 보호를 제공하지 못한다. 우리는 또한 Goktas 등이 "이상적인 CFI"라고 설명했던, 한 세트의 미세 세밀화된 CFI 정책을 구현했다. 우리는 두 개의 직교 정책: 간접 점프 및 호출과 이들의 타깃 간의 연관을 정밀하게 추적하는 PUMP JOP (M); 및 §2(규칙 1'-4')에서 제시된 바와 같이, 리턴에 대해 동일하게 수행하는 PUMP ROP (M)을 처음 소개한다. 우리는 마지막으로 이 두 정책을 PUMP CFI (O)로 병합한다 - 단일 정책은 모든 간접 제어 흐름을 정확하게 추적하고 입증해준다. 이러한 모든 정책에서, 컴파일러 또는 링커는 간접 제어 흐름 및 태그 명령어의 사운드 과도근사(sound overapproximation)를 계산한다고 추정된다.
보호 데모. 우리는 이들 정책을 "무해한" 기능으로의 단일 호출로 구성된 특수하게 제작된 프로그램에 대해 테스트하였다. 코드에는 또한 실행 경로의 일부가 아니고 의도하지 않은 거동을 유발하도록 악용될 수 있는 휴면 가젯을 모방하는, 결코 호출되지 않는 "나쁜" 함수가 포함되어 있다. 리턴-지향(return-oriented) 공격을 시뮬레이션하기 위해, 무해한 함수의 줄지은 어셈블리는 스택 포인터를 나쁜 함수의 어드레스로 오버라이팅하여, 실행을 속여 나쁜 함수에 리턴시킨다. 정책 (N)은 나쁜 리턴이 유효한 제어 흐름 세트에 없음을 알려줌으로써 이와 같이 시뮬레이션된 공격을 검출한다.
특성. 위의 각 CFI 정책은 2 내지 4개의 상징적 규칙만으로 매우 간결하게 인코딩될 수 있다. 더 간단한 정책 (J), (K) 및 (L)은 또한 매우 적은 수의 태그 및 구체적 규칙을 필요로 한다. 도 1에서 도시된 바와 같이, 이들 중 가장 큰 (L)은 6 개의 상수 태그를 사용하고 21 이하의 구체적 규칙을 필요로 한다. 이렇게 작은 작업 세트 크기로 인해, 이러한 정책은 비어 있는 정책보다 런타임 오버헤드를 유발하지 않는다. SPEC 벤치마크에 보다 강력한 CFI 정책 (M), (N), (O)을 적용하면 이러한 정책에 대해 최대 수천 개의 구체적 규칙을 생성하며, 이는 4096 개 엔트리, 프리-미스-핸들러 PUMP 캐시에 완전히 들어 맞는다. 결과적으로, 우리는 추가적인 런타임 오버헤드 없이 이상적인 부가된 보호를 획득한다. 완전한 CFI (O) 정책은 어플리케이션에 대한 제어 흐름 그래프를 저장하는 평균 28K 워드가 필요하다(이 시뮬레이션의 경우, 우리는 이것을 gem5에 의해 생성된 명령어 트레이스에서 추출한다; 실제로 이것은 우리의 시뮬레이션에서 결코 발휘되지 않는 허용된 제어 흐름 경로를 포함하는 것으로 표시된 것보다 많은 공간이 필요하다).
관련 저작물. CFI [2]는 일반적인 코드-재사용 공격에 대한 매력적인 방어책을 제공하지만 종종 너무 비싸다고 여겨져 왔다. 최근의 저작물 [51]은 브랜치 타깃 체킹을 제공하며 가제트를 성공적으로 구성하는 것에 대한 추가 방어책으로서 무작위화하는 "발판(springboard)"을 사용하는 낮은 오버헤드 CFI 체계를 실증하였다. 그러나, 이 저작물은 정책 (N), (M) 및 (O)가 수행하는 것처럼 특정 타깃을 가진 특정 리턴 포인트가 아닌, §2로부터의 규칙 1 내지 4에 있는 단일-타깃 예제와 유사한, 허용된 호출 및 리턴 타깃만을 제재할 뿐이어서, 공격에 취약한 채로 방치하며; 우리의 (M) 및 (O)가 수행하는 것처럼 절차 내 CFI를 다루지도 않는다.
4.4 테인트 추적
위협 모델.
이 정책은 공격자가 의도하지 않거나 악의적인 거동(예를 들어, SQL 또는 OS 명령어 주입)을 유발하는, 입력 위생 처리(input sanitization)를 하지 않는 프로그램에 기형 데이터를 입력하는 사례를 다룬다.
정책 및 규칙. 테인트 추적은 신뢰성 없는 데이터가 민감한 동작으로 유입될 수 있는 때를 검출함으로써 이러한 위협을 완화한다. PUMP는 무한한 수의 소스, 소스 당 별도의 테인트 및 각 데이터 조각상의 다수의 테인트를 사용하여 미세 세밀화된 테인트 추적을 용이하게 하여, 각 태그가 한 세트의 소스 id를 가리키는 포인터가 될 수 있게 한다. 값 상의 테인트는 이를 계산하는데 사용된 값상의 테인트들의 합집합이다. 전형적인 테인트 전파 규칙은 다음을 포함한다:
우리가 연구하는 모든 정책은 초기 테인트의 수와 소스만 다른 동일한 세트의 상징적 규칙을 사용한다. 우리는 두 개의 상이한 방식: 입력 소스 (P 및 Q)에 의한 방식 및 코드 영역((R), (S) 및 (T))에 의한 방식으로 테인트를 소개한다. (P)에서, 우리는 모든 입력 소스(즉, SPEC 프로그램의 경우, 표준 I/O 스트림 및 입력 파일)에 대해 단일 테인트를 사용한다. 이것은 신뢰성 없는 소스로부터 임의의 데이터가 t로 태깅된 값을 계산할 때 사용되었는지를 단일-비트 테인트 t가 단순히 표시하는 대부분의 이전의 연구 [41]와 유사하다. 정책 (Q)는 각 입력 스트림에 고유한 테인트 id를 할당함으로써 (P)를 확장하며; 스트림 수에는 제한이 없다. 프로그램 코드에 의한 테인팅은 신뢰성 없는 라이브러리 및 버그가 있는 컴포넌트에 대해 보호한다. 우리는 (i) 각각의 라이브러리 (R), (ii) 포함된 각각의 헤더 파일 (S) 또는 (iii) 코드의 각 기능 (T)에 대해 고유 테인트를 사용함으로써 세분성을 변경한다. 이들 정책은 컴파일러가 명령어를 관련된 테인트 식별자로 태깅할 것을 필요로 한다. 마지막으로, 우리는 (Q) 및 (R)을 조합하여 정책 (U)를 만든다.
보호 데모. 우리는 CWE-78(OS Command Injection) [29]의 사례를 고려해 볼 수 있는데, 여기서 사용자는 system 시스템 호출에 넘겨진 Is 명령어의 인수를 파라미터화하는 것을 허용 받았을 뿐이다. 악의적인 사용자는 임의의 명령어와 함께 명령어 종료 문자로 시작하는 파라미터 문자열을 추가한다. 이것은 "신뢰성 없음"으로 태깅되어 execve 시스템 호출에 인수로서 넘겨진 데이터를 사후 위생처리된 데이터로 변환한다. 정책 (U)를 사용하여, PUMP는 신뢰성 없음을 시스템-호출 테인트와 막 조합하려는 것을 보았을 때 실행을 중지시킨다.
특성. 이러한 모든 정책은 7개의 opgroup의 관점에서 정의된 동일한 8 개의 상징적 규칙을 사용한다. 처음 두 개 (P 및 Q)는 입력 스트림을 테인트 소스로서 사용한다. (Q)의 경우, 모든 SPEC 프로그램에 걸쳐, 우리는 평균적으로 2 개 소스만 볼 수 있고, 10 개 및 14 개의 구체적 규칙만 필요하다. 결과적으로 이러한 정책은 눈에 띄는 런타임 오버헤드를 초래하지 않는다. 정책 (R) 내지 (U)의 경우, 우리는 더 큰 작업 세트를 목격한다.
함수 실험 (T)에 의한 테인트는 의도적으로 메커니즘을 극단적으로 밀어 넣어, 실제 유용할 것보다 미세 세밀화된 태깅을 제공한다. 많은 수의 테인트는 PUMP 캐시가 한 번에 보유할 수 있는 것보다 더 많은 정도의 규칙을 초래한다. 또한, 태그-처리 오버헤드는 커진다(4110 명령어). 이러한 요소로 인해 314 %의 평균 런타임 오버헤드가 발생한다. 이것은 PUMP 메커니즘이 복잡한 정책 하에서 무리를 주지만 여전히 정책을 지원할 수 있음을 보여준다. 파일 당 테인트 (S)는 또한 유용할 가능성이 있는 것보다 미세 세밀화되고 규칙 세트가 더 작고 미스 핸들러 해결이 더 엄격해지기 때문에 런타임 오버헤드를 9 %로 낮게 달성한다.
우리가 전체 라이브러리에 테인트를 할당하는 정책 (R) 및 (Q)는 보다 합리적인 용법을 나타낸다. 여기서, 평균 런타임 오버헤드는 미스-핸들러가 없는 사례와 구별할 수 없다. 이것은 PUMP가 또한 (1b-테인트 또는 4b-테인트를 사용하는 이전의 연구와 비교하여) 본질적으로 추가 런타임 오버헤드 없이 훨씬 더 풍부한 모델을 표현하고 지원할 수 있음을 보여준다. 그뿐만 아니라, 이러한 다양한 테인트 사례에 걸쳐, 최종 태그는 초기 및 동적으로 할당된 태그의 2 내지 3X배에 불과하며; 이것은 우리가 비-싱글톤(non-singleton) 태그 세트를 생성하는 동안, 우리가 이론적인 최악 사례의 거듭 제곱 효과와 근접하는게 없음을 안다는 것을 보여준다.
관련 저작물. 테인트 추적을 사용하여 해결된 취약성은 포맷 문자열(format string) 공격 [48, 17, 41, 18, 12], 교차 사이트 스크립팅(cross-site scripting) [48, 18, 12], 메모리 악용(memory exploits) [48, 17, 41, 14, 18, 36, 12], 코드 주입(code injection) [48, 17, 18, 12] 및 기타 [49, 18]를 포함한다. 기존의 대부분의 저작물은 프로그램이 계기화된 소프트웨어 기술에 중점을 둔다. 전형적으로, 이러한 기술은 다른 장애(예를 들어, 동적 이진 변환(dynamic binary translations) [15]에서 경쟁 조건 처리) 외에, 의미있는 런타임 오버헤드(종종 2x 배이상, 일부 20x 배까지)를 도입한다.
DIFT [41], Minos [17], 및 SIFT [35]와 같은 하드웨어 접근법은 단일 테인트 비트를 사용한다. Raksha - 온-코어 [18] 및 전용 코프로세서 [26] 변형 둘 모두 - 는 4-비트 태그를 사용하여 최대 네 개의 동시 정책을 지원한다. 대조적으로, 우리는 아마도 신뢰성 레벨이 상이한 다수의 신뢰성 있는 소스에 대응하는 임의의 테인트 세트를 허용한다. 보다 유연한 태깅 체계는 §5에서 논의된다.
4.5 복합 정책
이러한 정책 각각은 잠재적으로 유용하지만, 한 번에 시행할 단일 정책만을 선택해야 한다면 - 예를 들면, 버퍼 오버플로우 또는 명령어 주입 취약성에 대비하여 보호하는 것 중 선택한다면 - 부끄러운 일이 될 것이다. 대신에, 우리는 일반적으로 다수의 정책을 작성하여 보호를 원한다. 실제로, 우리의 개별 정책 중 일부는 모든 위협에 대해 보호하는 상호 보호가 필요하다 (CFI는 데이터가 실행될 수 없고 코드가 생성되거나 수정될 수 없음을 보장하기 위해 타입 보호에 의존한다).
복합은 잠재적으로 태그 수와 생성된 규칙 수를 증가시켜 성능을 상당히 저하시킨다. 조합의 효과를 특성화하기 위해, 우리는 두 개의 복합 정책을 구현한다. 첫째 우리는 3 프리미티브 타입 (C), 간단한 메모리 안전 (F), CCFIR (L) 및 단일-비트 입력-테인트 (P)의 네 개 보호 부류 각각의 가장 단순한 인스턴스를 기반으로 상당히 작은 것을 구현한다. 둘째, 우리는 4 프리미티브 타입 (D), 전체 공간적 및 시간적 메모리 안전 (I), PUMP CFI (O), 스트림 입력 테인트 별 및 라이브러리 별의 복합 (U)의 복합인 보다 복합적이고 강력한 보호 기능을 구현한다.
특성. 간단한 복합 정책 (V)는 캐시에 적합하며 구성성분들 정책과 동일한 성능을 갖는다. 더 큰 복합 정책 (W)의 경우, 모든 정책을 해결해야 하므로 미스 핸들러의 규칙 해결에 필요한 명령어 수가 상당히 증가하여, 38 내지 710으로 올라간다. 최종 태그의 증가는 2.5x 배에 불과하여, 복합 태그로부터 일부 제품 세트 효과가 있지만, 최악의 시나리오에는 거의 나타나지 않음을 암시한다. 또한, 구체적 규칙은 더 많은 태그 세트 및 부가적인 opgroup으로 인해 약 3x배 증가할 뿐이다. 더 큰 구체적 규칙 세트(이제는 PUMP 캐시 용량보다 훨씬 큼) 및 증가된 미스 핸들러 비용의 조합은 38 %의 평균 오버헤드를 초래하여 최악의 오버헤드는 280 %만큼 높아진다(GemsFDTD). 이것은 PUMP가 성능에 미치는 영향을 희생하여 복합이 초래하는 더 많은 수의 규칙을 처리할 수 있음을 보여준다. 많은 애플리케이션의 경우, 오버헤드는 그다지 중요하지 않지만, 일부의 경우 지나치게 커진다. 이것은 함수 실험 (T)에 의한 테인트와 함께, 우리의 진행중인 연구의 초점인 이와 같은 풍부한 복합에서 대해 합리적인 성능을 얻기 위해 미스 핸들러 서비스 시간을 줄이는 추가 소프트웨어 및 마이크로아키텍처적 최적화의 필요성을 지적한다.
4.6 논의
전체 규칙 수는 규칙의 지역성 및 결과적으로 효과적인 작업 세트 크기를 완전히 점하지 못한다. 도 7은 gcc 벤치마크에 대한 10 억 명령어 시뮬레이션 내에서 백만 명령어 시퀀스 내에서 사용된 고유 규칙의 수의 누적 분포 함수(cumulative distribution function)(CDF)를 도시한다. 이것은 전체 메모리 안전 (I)이 매우 빽빽한 작업 세트(대부분 3000 미만)를 가지고 있음을 보여주며; 이것은 비-복합 정책의 구체적 규칙의 수가 최대이기 때문에 중요하다. 이러한 지역성은 규칙 세트가 훨씬 더 큼에도 불구하고 성능 오버헤드가 왜 낮은지에 대한 이유를 설명하는데 도움이 된다. 복합 CFI (O)는 더 큰 작업 세트를 갖지만, 복합 규칙 세트는 4096 엔트리 캐시에 완전히 들어 맞고, 그래서 퇴출이 없다.
이전 저작물에서는 안전 및 보안 정책(예를 들어, [42])을 간결하게 표현하거나 비슷하게 하기 위해 기발한 체계를 사용했지만, 이것은 종종 의도된 정책에 대한 절충안이며 복잡성을 간결함으로 바꾸어줄 수 있다. 우리는 런타임 오버헤드가 거의 없거나 추가되지 않으면서 보다 완벽하고 보다 자연스럽게 보안 정책의 요구 사항을 받아주는 풍부한 메타데이터를 포함할 수 있음을 보여준다. 메타데이터 표현 및 정책 복잡성에 고정된 경계를 부과하는 대신, PUMP는 적절히 성능을 저하시킨다. 이로 인해 정책은 일반적인 경우의 성능 및 크기에 영향을 주지 않으면서 필요한 곳에 더 많은 데이터를 사용할 수 있게 한다. 복잡한 정책이라도 쉽게 표현되고 실행될 수 있기 때문에, 정책의 점진적 세분화 및 성능 조정이 추가로 가능하다.
4.7 기타 마이크로-정책
우리는 우리의 프로그래밍 모델이 다수의 다른 정책을 인코딩할 수 있다고 생각한다. 정보-흐름 제어(예를 들어, [6, 37, 40, 24, 8])는 여기서 간단한 테인트 추적 모델보다 더 풍부하지만, 암묵적 흐름을 추적하는 것은 RIFLE-스타일 이진 변환(RIFLE-style binary translation) [44]을 사용하여 또는 컴파일러로부터 일부 지원되는 PC 태그의 사용에 의해 지원될 수 있다. 마이크로-정책은 경량의 액세스 제어 및 구획화 [47]를 지원할 수 있다. 태그는 위조할 수 없는 자원 [50]을 구별하는데 사용될 수 있다. 고유의 생성된 토큰은 데이터를 봉인하고 보증하는데 핵심 역할을 할 수 있고, 결국 강력한 추상화에 사용할 수 있으므로 - 데이터가 인가된 코드 컴포넌트에 의해서만 생성되고 파괴되는 것을 보장한다. 마이크로-정책 규칙은 불변성 및 선형성과 같은 데이터 불변성을 시행할 수 있다. 마이크로-정책은 데이터 또는 선물(예를 들어, [5])의 차있는/비어있는 비트와 같은 동기화 프리미티브에 대한 대역외로서 또는 잠금(lock)에 대한 경쟁 조건을 감지하는 상태로서 병행성을 지원할 수 있다(예를 들어, [38, 52]). 시스템 설계자는 모든 라인을 감사 또는 다시 작성하지 않으면서 기존의 코드에 특정 마이크로-정책을 적용할 수 있다.
5. 관련 저작물
우리의 예제 정책과 관련 저작물은 §4에서 다루었다. 여기에서 우리는 하드웨어 태그 체킹 및 전파에 일반적으로 더 관련 저작물에 대해 설명한다. 아래에 언급되는 몇 가지 예외를 제외하고, 대부분의 이전 저작물은 하드 와이어되거나 매우 제한적인 정책을 가지고 작은 태그 비트 세트를 사용한다(도 2 참조). 테인트 하드웨어의 첫번째 물결은 하드와이어된 테인트 전파 로직을 사용하여 각 워드에 첨부된 단일 테일 비트를 지원했다. 최신 시스템은 다수의 독립 테인트 태그(예를 들어, [18]), 다중 비트 태그(예를 들어, [45]) 및 보다 유연한 정책(예를 들어, [19])을 처리할 수 있는 기능을 추가했다. 한 번에 하나 이상의 정책을 지원하는 유일한 설계인 Raksha는 최대 네 개의 테인트 추적 정책 [18]을 지원했다.
우리에게 가장 가까운 이전 시스템은 Aries [11], FleX1Taint [45], Log-Based Architecture (LBA) [13], Harmoni [20]이며, 이들은 모두 소프트웨어 핸들러에 의해 뒷받침되는 프로그램 가능 규칙 캐시를 제안한다. FleX1Taint 및 LBA만이 프로그램 가능 규칙 캐시를 사용하는 특정의 예시적인 보안 정책을 상세화하고 있다. LBA를 제외한 모든 사례에서, 규칙 캐시는 연산의 두 오퍼랜드에 대한 두 개의 입력을 기초로 하고 단일 출력을 생성하지만, PUMP는 잠재적으로 다섯 입력을 가져와서 두 개의 출력을 생성한다: 도 1은 이러한 태그 소스 및 목적지가 우리의 보안 정책에 사용되는 방법을 요약한다.
도 2: 하드웨어 태깅 접근법
LBA는 잠재적으로 여러 입력을 갖지만, 하드웨어에서 메타데이터 생성을 처리하지 않는다. LBA의 혁신 중 일부(예를 들어, 테인트 조합의 포기를 포함하는 단항의 상속 추적(unary inheritance tracking)으로 일반적인 전파 추적의 제한)은 우리의 해결책이 제공하는 일반성을 특히 신속하게 포기하도록 만들었다. 이러한 제한된 정책이 있더라도, LBA는 대부분 단일 정책의 8 %의 평균 오버헤드에 비해 ~50 % 런타임 오버헤드를 갖는다. 우리가 여기서 보여준 정책은 여분의 태그 입력 및 출력과 더 풍부한 태그 메타데이터 때문에 FleXiTaint에 의해 지원되는 정책보다 더 풍부하다.
6. 향후 연구
PUMP 설계는 융통성 및 성능의 매력적인 조합을 제공하여, 대부분의 경우 전용 메커니즘에 필적하는 단일 정책 성능으로 다양한 저레벨, 미세 세밀화된 보안 정책의 모음을 지원하면서, 규칙 복잡성이 커짐에 따라 대부분 적절히 성능이 저하되는 보다 풍부하고 복합적인 정책을 지원한다. 이러한 설계 공간을 더 철저히 이해하기 위해, 많은 문제가 추가로 조사하는 것이 필요하다. 첫째, 우리가 실행중인 하드웨어 구현을 갖는다면, PUMP 하드웨어 및 하위 레벨 소프트웨어를 호스트 오퍼레이팅 시스템 및 소프트웨어 툴체인(예를 들어, 컴파일러, 링커 및 로더)과 통합해야 할 것이다. 둘째, 우리는 PUMP에 의해 제공되는 메커니즘이 자체 소프트웨어 구조체를 보호하는데 사용될 수 있는지 궁금해 하고 있다. 우리는 PUMP를 사용하는 "구획화" 마이크로-정책을 구현하고 이를 미스-핸들러 코드를 보호하는데 사용함으로써 특수한 미스-핸들러 작동 모드를 대체할 수 있다고 믿는다. 마지막으로, 각 정책에 의해 제공되는 보호가 다른 정책과 완전히 독립적인, 정책들의 직교 세트를 조합하는 것이 쉽다는 것을 알았다. 그러나 정책은 종종 상호 작용한다: 예를 들어, 정보-흐름 정책은 메모리 안전 정책에 의해 할당되는 새로운 영역에 태그를 배치해야 할 수 있다. 정책 구성은 표현에 있어서 그리고 효율적인 하드웨어 지원에 있어서 더 많은 연구가 필요하다.
도 3: 초기 태그의 분포
도 4: 최종 태그의 분포
도 5: 구체적 규칙의 분포
도 6: (위의 정책 A의) 런타임 오버헤드의 분포
도 7: gcc에 대한 작업 세트 크기의 CDF
7. 참고 문헌
[I ] Alpha Architecture Handbook. Digital Equipment Corporation, 1992.
[2] M. Abadi, M. Budiu, LJ Erlingsson, and J. Ligatti. Control-flow integrity. In Proc. ACM CCS, pages 340-353, 2005.
[3] P. Akritidis, M. Costa, M. Castro, and S. Hand. Baggy bounds checking: an efficient and backwards-compatible defense against out-of- bounds errors. In Proc. USENIX Security, pages 51-66, 2009.
[4] D. Arora, S. Ravi, A. Raghunathan, and N. K. Jha. Architectural support for run-time validation of program data properties. IEEE Trans. VLSI Sys., 15(5):546-559, May 2007.
[5] Arvind, R. S. Nikhil, and K. K. Pingali. l-structures: Data structures for parallel computing. In Proc. Wkshp on Graph Reduction (Springer- Verlag LNCS 279), Sept. 1986.
[6] T. H. Austin and C. Flanagan. Efficient purely-dynamic information flow analysis. In Workshop on Programming
Languages and Analysis for Security (PLAS), PLAS, pages 1 13- 124. ACM, 2009.
[7] (authors removed for anonymity). PUMP - A Programmable Unit for Metadata Processing, 2014. To appear.
[8] A. Azevedo de Amorim, N. Collins, A. DeHon, D. Demange, C. Hrij:cu, D. Pichardie, B. C. Pierce, R. Pollack, and A. Tolmach. A verified information-flow architecture. In POPL, pages 165-178. ACM, Jan. 2014.
[9] N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D. R. Hower, T. Krishna, S. Sardashti, R. Sen, K. Sewell, M. Shoaib, N. Vaish, M. D. Hill, and D. A. Wood. The gem5 simulator.
SIGARCH Comput. Archil News, 39(2): 1-7, Aug. 201 1.
[10] T. Boland and P. E. Black. Juliet 1 .1 C/C++ and Java test suite.
Computer, pages 88-90, 2012.
[11] J. Brown and T. F. Knight, Jr. A minimally trusted computing base for dynamically ensuring secure information flow. Technical Report 5, MIT CSAIL, November 2001, Aries Memo No. 15.
[12] H. Chen, X. Wu, L. Yuan, B. Zang, P.-c. Yew, and F. T. Chong. From Speculation to Security: Practical and Efficient Information Flow Tracking Using Speculative Hardware. In
Proc. ISCA, pages 401-412, 2008.
[13] S. Chen, M. Kozuch, T. Strigkos, B. Falsafi, P. B. Gibbons, T. C.
Mowry, V. Ramachandran, O. Ruwase, M. P. Ryan, and E. Vlachos.
Flexible Hardware Acceleration for Instruction-Grain Program Monitoring. In Proc. ISCA, pages 377-388, 2008.
[14] S. Chen, J. Xu, N. Nakka, Z. Kalbarczyk, and R. Iyer. Defeating memory corruption attacks via pointer taintedness detection. In Proc. IEEE DSN, pages 378-387, 2005.
[15] J. Chung, M. Dalton, H. Kannan, and C. Kozyrakis. Thread-safe dynamic binary translation using transactional memory. In HPCA, pages 279-289. IEEE, 2008.
[16] J. A. Clause, I. Doudalis, A. Orso, and M. Prvulovic. Effective memory protection using dynamic tainting. In Proc. ASE, pages 284-292. ACM, 2007.
[17] J. R. Crandall and F. T. Chong. Minos: Control data attack prevention orthogonal to memory model. In Proc. IEEE MICRO, pages 221-232, 2004.
[18] M. Dalton, H. Kannan, and C. Kozyrakis. Raksha: a flexible information flow architecture for software security. In Proc. ISCA, pages 482-493, 2007.
[19] D. Y. Deng, D. Lo, G. Malysa, S. Schneider, and G. E. Suh. Flexible and Efficient Instruction-Grained Run-Time Monitoring Using On-Chip Reconfigurable Fabric. In Proc. IEEE MICRO, pages 137-148, 2010.
[20] D. Y. Deng and G. E. Suh. High-performance parallel accelerator for flexible and efficient run-time monitoring. In Proc. IEEE DSN, pages 1- 12, 2012.
[21] J. Devietti, C. Blundell, M. M. K. Martin, and S. Zdancewic.
HardBound: Architectural support for spatial safety of the C programming language. In S. J. Eggers and J. R. Lams, editors, ASPLOS, pages 103-1 14. ACM, 2008.
[22] E. Goktap, E. Athanasopoulos, H. Bos, and G. Portokalidis. Out Of Control: Overcoming Control-Flow Integrity. In Proc. IEEE S&P, 2014. [23] C. J. Haley, S. M. Luera, M. D. Schanken, and W. B. Geer. Final evaluation report unisys a series mcp/as release 3.7. Technical Report CSC-EPL-871003, Library No. S-228,515, National Computer Security Center, Fort Meade, MD, August 5 1987.
[24] D. Hedin and A. Sabelfeld. Information-flow security for a core of JavaScript. In 25th IEEE Computer Security Foundations Symposium (CSF), CSF, pages 3-18. IEEE, 2012.
[25] J. L. Henning. SPEC CPU2006 benchmark descriptions. SIGARCH Comput. Archil News, 34(4):1-17, Sept. 2006.
[26] H. Kannan, M. Dalton, and C. Kozyrakis. Decoupling Dynamic Information Flow Tracking with a Dedicated Coprocessor. In Proc. IEEE
DSN, pages 105-1 14, 2009.
[27] MITRE Corp. CWE-122: Heap-based buffer overflow. [28] MITRE Corp. CWE-416: Use after free.
[29] MITRE Corp. CWE-78: Improper neutralization of special elements used in an OS command (OS command injection).
[30] MITRE Corp. CWE-843: Access of resource using incompatible type (type confusion).
[31] D. A. Moon. Architecture of the Symbolics 3600. In Proc. ISCA, pages 76-83, Los Alamitos, CA, USA, 1985. IEEE Computer Society. [32] S. Nagarakatte, M. M. K. Martin, and S. Zdancewic. Hardware-Enforced Comprehensive Memory Safety. IEEE Micro, 33(3):38-47, May-June 2013.
[33] S. Nagarakatte, J. Zhao, M. M. K. Martin, and S. Zdancewic. SoftBound: highly compatible and complete spatial memory safety for C. In Proc. PLDI, pages245-258. ACM, 2009.
[34] E. I. Organick. Computer System Organization: The B5700/B6700
Series. Academic Press, 1973.
[35] M. Ozsoy, D. Ponomarev, N. B. Abu-Ghazaleh, and T. Suit SIFT: a low-overhead dynamic information flow tracking architecture for SMT processors. In Conf. Computing Frontiers, page 37, 201 1.
[36] F. Qin, C. Wang, Z. Li, H. Kim, Y. Zhou, and Y. Wu. LIFT: A low-overhead practical information flow tracking system for detecting security attacks. In Proc. IEEE MICRO, pages 135-148, 2006.
[37] A. Russo and A. Sabelfeld. Dynamic vs. static flow-sensitive security analysis. In Proc. CSF, pages 186-199, 2010.
[38] S. Savage, M. Burrows, G. Nelson, P. Sobalvarro, and T. Anderson. Eraser: A dynamic race detector for multi-threaded programs. ACM Trans. Comp. Sys. , 15(4), 1997.
[39] H. Shacham. The Geometry of Innocent Flesh on the Bone: Return- into-libc without Function Calls (on the x86). In Proc. ACM CCS, pages 552-561 , Oct. 2007.
[40] D. Stefan, A. Russo, J. C. Mitchell, and D. Mazieres. Flexible dynamic information flow control in Haskell. In 4th Symposium on Haskell, pages 95- 106. ACM, 2011.
[41] G. E. Suh, J. W. Lee, D. Zhang, and S. Devadas. Secure Program Execution via Dynamic Information Flow Tracking. In Proc. ASPLOS, pages 85-96, 2004.
[42] L. Szekeres, M. Payer, T. Wei, and D. Song. SoK: Eternal war in memory. In Proc. IEEE S&P, pages 48-62, 2013.
[43] G. S. Taylor, P. N. Hilfinger, J. R. Larus, D. A. Patterson, and B. G.
Zorn. Evaluation of the SPUR lisp architecture. In Proc. ISCA, pages 444-452, 1986.
[44] N. Vachharajani, M. J. Bridges, J. Chang, R. Rangan, G. Ottoni, J. A. Blome, G. A. Reis, M. Vachharajani, and D. I. August. RIFLE: An architectural framework for user-centric information-flow security. In Proc. IEEE MICRO, 2004.
[45] G. Venkataramani, I. Doudalis, Y. Solihin, and M. Prvulovic. FlexiTaint: A programmable accelerator for dynamic taint propagation. In Proc. HPCA, pages 173-184, Feb. 2008.
[46] R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham. Efficient software-based fault isolation. In SOSP, pages 203-216, 1993.
[47] E. Witchel, J. Cates, and K. Asanovi c. ondrian memory protection. In Proc. ASPLOS, pages 304-316, New York, NY, USA, 2002. ACM.
[48] W. Xu, S. Bhatkar, and R. Sekar. Taint-enhanced policy enforcement: a practical approach to defeat a wide range of attacks. In Proc. USENIX Security, Berkeley, CA, USA, 2006.
[49] H. Yin, D. X. Song, M. Egele, C. Kruegel, and E. Kirda. Panorama: capturing system-wide information flow for malware detection and analysis. In Proc. CCS, pages 1 16-127. ACM, 2007.
[50] N. Zeldovich, H. Kannan, M. Dalton, and C. Kozyrakis. Hardware enforcement of application security policies using tagged memory. In Proceedings of the 8th USENIX conference on Operating systems design and implementation, OSDI, pages 225-240. USENIX Association, 2008.
[51 ] C. Zhang, T. Wei, Z. Chen, L. Duan, L. Szekeres, S. McCamant, D. Song, and W. Zou. Practical Control Flow Integrity & Randomization for Binary Executables. In Proc. IEEE S&P, 2013.
[52] P. Zhou, R. Teodorescu, and Y. Zhou. HARD: Hardware-assisted lockset-based race recording. In Proc. HPCA, 2007.
8. 상징적 규칙
8.1 프리미티브 타입
리턴 어드레스를 체크하기 위한 대안의 규칙
8.2 메모리 안전
전체 메모리 안전을 위해 N=264-k로 N-컬러화. 우리는 컬러를 c로 작성하고, 이를 힙을 가리키는 포인터에 태깅하는데 사용한다. 우리는 컬러와 상이한 특수 태그 
을 가정하는데, 이는 힙을 가리키는 포인터가 아닌 모든 데이터에 태깅하는데 사용된다. 레지스터에 대한 태그는 컬러 또는 
(t로 작성됨)이다. 메모리에 대한 태그는 컬러와 컬러 또는 
((c1, t2)로 작성됨) 또는 F (할당되지 않음)의 쌍이다. 힙은 처음에 모두 F로 태깅된다. 마지막으로 명령어상의 태그는 세트: {tmalloc, tmal loci nit, tfreeinit, tsomething}로부터 작성된다.
8.3 CFI
8.3.1
CFI-1ID [2]
우리는 세트: ø 및 {f}로서 기입된 2 태그를 사용한다. 태그{f}는 모든 간접적 통제 흐름뿐만 아니라 이들의 모든 잠재적 목적지에 태깅하기 위해 사용된다. 태그 ø는 다른 모든 것에 사용된다.
8.3.2
CFI-2ID [2]
이 정책에서, r은 리턴 및 리턴의 잠재적 타깃을 마킹하기 위해 사용되며, c는 간접 호출 및 점프와 점프의 잠재 타깃에 사용된다. 이 두 경우가 겹칠 수 있기 때문에, 우리는 세트: ø{r}, {c} 및 {r, c}로서 작성된 4 태그를 사용하고 있다.
8.3.3
CCFIR [51]
r은 return-id, c는 cal1-id, p는 return-into-privileged-code-id이다. 세트: ø, {r}, {p}, {c}, {r, c} 및 {p, c}로 작성된 6 태그를 가정한다.
8.3.4
CFI-ROP
우리는 리턴 ID 및 가능한 목적지 ID의 쌍을 포함하는 허용된 제어-흐름 그래프 χ를 가정한다. 우리는 아래에 id를 ci 또는 pc로서 기입한다. 태그는 유효한 ID 또는 
이다.
8.3.5
CFI-JOP
허용된 제어-흐름 그래프, X를 가정한다.
8.3.6
완전한 CFI
우리는 허용된 제어-흐름 그래프 x를 가정한다.
8.4 테인트 추적
8.5 서브워드 연산
우리가 우리의 실험에서 사용한 위의 규칙은 서브워드 연산을 감안하지 않는다. 서브워드 연산을 적절히 지원하기 위해, 우리는 로드 및 스토어 opgroup을 워드 연산(wload 및 wstore) 및 두 opgroup 바이트 연산(bload 및 bstore)을 위한 두 opgroup으로 나누어야 했을 것이다.
명시적으로 로드 또는 스토어에 대해 이야기하는 모든 정책에 대한 규칙은 변경해야 한다(간단한 타입, 메모리 안전 및 테인트 추적). 여기서는 간단한 타입 정책(의 retaddr 변형이 없음)을 변경하는 방법이다 (w opgroup는 이전의 규칙에 대응한다).
여기서는 메모리 안전에 대한 b 규칙이다.
여기서는 테인트 추적에 대한 bstore 규칙이다.
Claims (81)
- 메모리 영역에 대한 태그 값을 저장하는 방법으로서,
상기 메모리 영역 내의 복수의 메모리 위치에 대한 하나 이상의 태그 값을 수신하는 단계; 및
상기 메모리 영역의 상기 복수의 메모리 위치에 대한 상기 하나 이상의 태그 값의 계층적 표현을 생성하는 단계를 포함하며,
상기 계층적 표현은 하나 이상의 메모리 위치와 각각 연관된 하나 이상의 노드를 포함하고, 상기 계층적 표현의 각각의 노드는 상기 각각의 노드와 연관된 하나 이상의 메모리 위치의 서브 범위에 대한 태그 값을 나타내거나, 그렇지 않으면 상기 계층적 표현의 특정 레벨에서의 상기 각각의 노드가 상기 각각의 노드와 연관된 상기 하나 이상의 메모리 위치의 서브 범위에 대한 태그 값을 특정하지 않음을 나타내고, 이에 따라 상기 특정 레벨보다 낮은 하나 이상의 레벨에서의 하나 이상의 다른 노드는 상기 각각의 노드와 연관된 상기 하나 이상의 메모리 위치의 서브 범위에 대한 하나 이상의 태그 값을 특정하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 1 항에 있어서,
상기 메모리 영역의 제 1 메모리 위치에 대한 현재 태그 값으로서 저장될 제 1 태그 값을 수신하는 단계; 및
상기 계층적 표현을 업데이트하여 상기 제 1 태그 값이 상기 제 1 메모리 위치에 대한 현재 태그 값임을 나타내는 단계를 더 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 2 항에 있어서,
상기 업데이트 단계를 수행하기 전에, 기존 태그 값이 상기 제 1 메모리 위치에 대한 상기 현재 태그 값으로서 저장되며, 상기 방법은 상기 현재의 태그 값을 상기 기존 태그 값으로부터 상기 제 1 태그 값으로 업데이트하는 처리를 수행하는 단계를 포함하고,
상기 처리는:
상기 제 1 메모리 위치를 포함하는 메모리 위치들의 제 1 서브 범위와 연관된 상기 계층적 표현의 제 1 노드를 결정하는 단계 - 상기 제 1 노드는 상기 기존 태그 값을 상기 메모리 위치들의 제 1 서브 범위에 대한 동질의 태그 값으로서 나타내고, 이에 따라 상기 제 1 서브 범위 내의 각 메모리 위치는 상기 기존 태그 값을 가짐 -;
상기 제 1 노드의 제 1 자식 노드를 생성하는 단계 - 상기 제 1 자식 노드는 상기 제 1 태그 값을 상기 제 1 서브 범위의 상기 제 1 메모리 위치에 대한 상기 현재 태그 값으로서 나타냄 -;
상기 제 1 노드의 하나 이상의 다른 자식 노드를 생성하는 단계 - 상기 하나 이상의 다른 자식 노드는 상기 제 1 메모리 위치 이외의 상기 제 1 서브 범위의 메모리 위치에 대한 상기 기존 태그 값을 나타냄 -; 및
상기 제 1 노드가 상기 제 1 노드와 연관된 상기 하나 이상의 메모리 위치들의 서브 범위에 대한 태그 값을 특정하지 않음을 표시하도록 상기 제 1 노드를 업데이트하는 단계를 포함하고,
이에 따라 상기 제 1 노드의 레벨보다 낮은 상기 계층적 표현의 하나 이상의 레벨에서, 상기 제 1 노드의 하나 이상의 다른 자손 노드가 상기 제 1 서브 범위에 대한 하나 이상의 태그 값을 특정하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 1 항에 있어서,
상기 메모리 영역의 제 1 메모리 위치에 대한 현재 태그 값을 결정하는 제 1 처리를 수행하는 단계를 더 포함하고,
상기 제 1 처리는:
상기 계층적 표현을 횡단하여(traversing) 상기 메모리 영역의 하나 이상의 메모리 위치들의 제 1 서브 범위와 연관된 상기 계층적 표현의 제 1 노드를 찾는 단계를 포함하고,
상기 서브 범위는 상기 제 1 메모리 위치를 포함하고, 상기 제 1 노드는 상기 하나 이상의 메모리 위치들의 제 1 서브 범위에 대한 기존 태그 값을 나타내고, 이에 따라 상기 제 1 서브 범위 내의 각각의 메모리 위치는 기존 태그 값을 갖고, 상기 기존 태그 값은 상기 제 1 메모리 위치에 대한 상기 현재 태그 값인,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 4 항에 있어서,
상기 횡단은 상기 계층적 표현의 루트 노드로부터 시작하여 상기 계층적 표현의 리프 노드를 향해 상기 계층적 표현의 하위 레벨로 아래쪽으로 진행하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 4 항에 있어서,
상기 계층적 표현은 복수의 캐싱 레벨에 저장된 상기 복수의 레벨의 노드를 갖는 복수의 레벨을 포함하고, 상기 복수의 레벨 각각으로부터의 노드는 상기 복수의 캐싱 레벨 중의 상이한 대응하는 캐싱 레벨에 저장되는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 6 항에 있어서,
상기 제 1 처리는 상기 캐싱 레벨 각각이 상기 제 1 메모리 위치에 대한 상기 현재 태그 값을 정의하는 노드를 포함하는지를 결정하기 위해 상기 복수의 캐싱 레벨 각각에서의 상기 제 1 메모리 위치를 룩업하는(looking up) 단계를 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 7 항에 있어서,
상기 룩업하는 단계는 상기 복수의 캐싱 레벨 중 어느 것이 상기 제 1 메모리 위치에 대한 상기 현재 태그 값을 정의하는지를 결정하기 위해 상기 복수의 캐싱 레벨의 병렬 룩업을 수행하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 8 항에 있어서,
상기 복수의 캐싱 레벨 중 제 1 캐싱 레벨은 상기 제 1 메모리 위치에 대한 상기 현재 태그 값을 특정하고, 상기 제 1 노드는 상기 제 1 캐싱 레벨에 포함되는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 9 항에 있어서,
상기 제 1 캐싱 레벨은 상기 제 1 메모리 위치에 대한 태그 값을 정의하는 상기 계층의 상기 복수의 레벨 중의 최고 레벨인,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 1 항에 있어서,
상기 계층적 표현은 트리(tree)인,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 11 항에 있어서,
상기 트리는 상기 메모리 영역의 상기 복수의 메모리 위치에 대한 현재 태그 값을 특정하는 하나 이상의 리프 노드(leaf node)를 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 11 항에 있어서,
상기 트리는 2진 트리인,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 11 항에 있어서,
상기 트리의 각각의 노드는 제로의 더 많은 자식 노드들을 최대 허용 가능한 수의 자식 노드까지 갖는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 1 항에 있어서,
상기 계층적 표현은 복수의 캐싱 레벨에 저장된 상기 복수의 레벨의 노드를 갖는 복수의 레벨을 포함하고, 상기 복수의 레벨 각각으로부터의 노드는 상기 복수의 캐싱 레벨 중 대응하는 상이한 캐싱 레벨에 저장되며,
상기 방법은:
상기 메모리 영역의 제 1 메모리 위치에 대한 데이터 캐시 히트 또는 데이터 캐시 미스가 있는지를 결정하는 단계;
상기 제 1 메모리 위치에 대한 데이터 캐시 미스를 결정하는 것에 응답하여, 상기 복수의 캐싱 레벨에서 상기 제 1 메모리 위치에 대한 캐싱된 태그 값을 룩업하는 것을 포함하는 제 1 처리를 수행하는 단계; 및
상기 제 1 메모리 위치에 대한 데이터 캐시 히트를 결정하는 것에 응답하여, 제 2 처리를 수행하는 단계를 더 포함하고,
상기 제 2 처리는:
상기 제 1 메모리 위치에 대한 상기 데이터 캐시에 저장된 제 1 캐싱된 태그 값이 상기 제 1 메모리 위치에 대한 상기 계층적 표현에 저장된 현재 태그 값과 매칭하는지를 결정하는 단계; 및
상기 제 1 캐싱된 태그 값과 상기 현재 태그 값과 매칭하지 않는다고 결정되면, 상기 데이터 캐시에 저장된 상기 제 1 캐싱된 태그 값을 업데이트하는 단계를 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 15 항에 있어서,
상기 데이터 캐시에 저장된 상기 제 1 캐싱된 태그 값을 업데이트하는 단계는:
상기 데이터 캐시의 상기 제 1 캐싱된 태그 값을 상기 계층적 표현에 저장된 상기 제 1 메모리 위치에 대한 상기 현재 태그 값으로 대체하는 단계; 및
상기 복수의 캐싱 레벨 중 어느 것이 상기 제 1 메모리 위치에 대한 상기 현재 태그 값을 포함하는지를 나타내는 상기 데이터 캐시 내에 유지되는 추가 정보를 업데이트하는 단계를 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 15 항에 있어서,
상기 제 1 처리는 상기 복수의 캐싱 레벨을 병렬로 검색함으로써 상기 복수의 캐싱 레벨에서 상기 제 1 메모리 위치에 대한 상기 캐싱된 태그 값을 룩업하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 17 항에 있어서,
상기 제 1 메모리 위치에 대한 상기 캐싱된 태그 값을 룩업할 때 태그 캐시 미스에 응답하여 - 상기 태그 캐시 미스는 상기 복수의 캐싱 레벨 중 특정 캐싱 레벨에서 있고, 상기 복수의 캐싱 레벨 중 상기 특정 캐싱 레벨은 제 1 메모리 위치에 대한 태그 값을 포함하지 않음 -, 수행되는 처리는:
계층적 표현을 횡단하여 제 1 메모리 위치에 대한 태그 값을 특정하는 노드를 찾는 단계; 및
상기 횡단에 따라 상기 계층적 표현의 노드에 대한 하나 이상의 태그 값을 상기 복수의 캐싱 레벨 중 적절한 캐싱 레벨에 삽입하는 단계를 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 15 항에 있어서,
상기 제 1 처리는 상기 캐싱 레벨 중 최고 캐싱 레벨로부터 상기 캐싱 레벨 중 최저 캐싱 레벨까지 상기 복수의 캐싱 레벨을 횡단함으로써 상기 복수의 캐싱 레벨에서 상기 제 1 메모리 위치에 대한 상기 캐싱된 태그 값을 룩업하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 19 항에 있어서,
상기 제 1 메모리 위치에 대한 상기 캐싱된 태그 값을 검색할 때 태그 캐시 미스에 응답하여 - 상기 태그 캐시 미스는 상기 복수의 캐싱 레벨 중 특정 레벨에서 있고, 상기 복수의 캐싱 레벨 중 상기 특정 레벨은 상기 제 1 메모리 위치에 대한 태그 값을 포함하지 않음 -, 수행되는 처리는:
상기 계층적 표현을 횡단하여 상기 제 1 메모리 위치에 대한 태그 값을 특정하는 노드를 찾는 단계; 및
상기 횡단에 따라 상기 계층적 표현의 노드에 대한 하나 이상의 태그 값을 상기 복수의 캐싱 레벨 중 적절한 캐싱 레벨에 삽입하는 단계를 포함하는,
메모리 영역에 대한 태그 값을 저장하는 방법. - 제 1 항에 있어서,
상기 태그 값은 메타데이터 처리에 사용되는 메타데이터 태그인,
메모리 영역에 대한 태그 값을 저장하는 방법. - 시스템으로서,
프로세서; 및
실행될 때, 메모리 영역에 대한 태그 값을 저장하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고,
메모리 영역에 대한 태그 값을 저장하는 상기 방법은:
상기 메모리 영역 내의 복수의 메모리 위치에 대한 하나 이상의 태그 값을 수신하는 단계; 및
상기 메모리 영역의 상기 복수의 메모리 위치에 대한 상기 하나 이상의 태그 값의 계층적 표현을 생성하는 단계를 포함하며,
상기 계층적 표현은 하나 이상의 메모리 위치와 각각 연관된 하나 이상의 노드를 포함하고, 상기 계층적 표현의 각각의 노드는 상기 각각의 노드와 연관된 하나 이상의 메모리 위치의 서브 범위에 대한 태그 값을 나타내거나, 그렇지 않으면 상기 계층적 표현의 특정 레벨에서의 상기 각각의 노드가 상기 각각의 노드와 연관된 상기 하나 이상의 메모리 위치의 서브 범위에 대한 태그 값을 특정하지 않음을 나타내고, 이에 따라 상기 특정 레벨보다 낮은 하나 이상의 레벨에서의 하나 이상의 다른 노드는 상기 각각의 노드와 연관된 상기 하나 이상의 메모리 위치의 서브 범위에 대한 하나 이상의 태그 값을 특정하는,
시스템. - 실행될 때, 메모리 영역에 대한 태그 값을 저장하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독가능한 매체로서,
메모리 영역에 대한 태그 값을 저장하는 상기 방법은:
상기 메모리 영역 내의 복수의 메모리 위치에 대한 하나 이상의 태그 값을 수신하는 단계; 및
상기 메모리 영역의 상기 복수의 메모리 위치에 대한 상기 하나 이상의 태그 값의 계층적 표현을 생성하는 단계를 포함하며,
상기 계층적 표현은 하나 이상의 메모리 위치와 각각 연관된 하나 이상의 노드를 포함하고, 상기 계층적 표현의 각각의 노드는 상기 각각의 노드와 연관된 하나 이상의 메모리 위치의 서브 범위에 대한 태그 값을 나타내거나, 그렇지 않으면 상기 계층적 표현의 특정 레벨에서의 상기 각각의 노드가 상기 각각의 노드와 연관된 상기 하나 이상의 메모리 위치의 서브 범위에 대한 태그 값을 특정하지 않음을 나타내고, 이에 따라 상기 특정 레벨보다 낮은 하나 이상의 레벨에서의 하나 이상의 다른 노드는 상기 각각의 노드와 연관된 상기 하나 이상의 메모리 위치의 서브 범위에 대한 하나 이상의 태그 값을 특정하는,
비일시적 컴퓨터 판독가능한 매체. - 명령어를 처리하는 방법으로서,
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행됨 -; 및
상기 대응하는 메타데이터 태그에 따라 상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 제 1 메모리 위치의 다수의 데이터 부분 중 적어도 하나를 사용하는 동작을 수행하는 것을 허용할지를 결정하는 단계를 포함하고,
상기 제 1 메모리 위치는 단일 메타데이터 태그와 연관되고, 상기 다수의 데이터 부분은 연관된 메타데이터 태그를 갖고, 상기 다수의 데이터 부분 각각에 대해, 상기 단일 메타데이터 태그는 상기 각각의 다수의 데이터 부분에 대해 상기 연관된 메타데이터 태그 중 특정 메타데이터 태그를 획득하거나 결정하기 위해 사용되는,
명령어를 처리하는 방법. - 제 24 항에 있어서,
상기 제 1 메모리 위치는 다수 바이트의 데이터를 포함하는,
명령어를 처리하는 방법. - 제 25 항에 있어서,
상기 제 1 메모리 위치는 단일 워드이고, 상기 다수의 바이트 각각은 상기 다수의 데이터 부분 중 상이한 데이터 부분에 대응하며, 상기 메타데이터 처리에 의해 사용되는 레지스터는 상기 단일 워드에 저장된 상기 다수의 바이트 중 어느 바이트가 상기 현재 명령어에 의해 판독되는 것인지 기입되는 것인지를 표시하는 바이트-인에이블 레지스터(byte-enable register)를 포함하고, 이에 의해 상기 바이트-인에이블 레지스터는 하나 이상의 연관된 메타데이터 태그의 하나 이상 중 어느 것이 상기 현재 명령어의 상기 메타데이터 처리에서 사용되는지를 식별하는,
명령어를 처리하는 방법. - 제 25 항에 있어서,
상기 제 1 메모리 위치는 단일 워드이며, 상기 메타데이터 처리에 의해 사용되는 레지스터는 상기 단일 워드에 저장된 상기 다수의 데이터 부분 중 하나 이상이 상기 현재 명령어에 의해 판독되는 것인지 기입되는 것인지를 표시하는 레지스터를 포함하고, 이에 의해 상기 레지스터는 하나 이상의 관련 메타데이터 태그의 하나 이상 중의 어느 것이 상기 현재 명령어의 상기 메타데이터 처리에서 사용되는지를 식별하는,
명령어를 처리하는 방법. - 제 25 항에 있어서,
상기 단일 메타데이터 태그는 상기 다수 바이트의 데이터에 대한 상기 연관된 메타데이터 태그를 포함하는 제 2 메모리 위치를 가리키는 포인터인,
명령어를 처리하는 방법. - 제 28 항에 있어서,
상기 제 2 메모리 위치는 가변 길이 구조체의 다수의 후속 태그 필드를 나타내는 제 1 필드를 포함하는 상기 가변 길이 구조체를 포함하고, 상기 후속 태그 필드는 상기 다수 바이트의 데이터와 연관된 상기 연관된 메타데이터 태그를 특정하는,
데이터 명령어를 처리하는 방법. - 제 25 항에 있어서,
상기 단일 메타데이터 태그는 상기 다수 바이트의 데이터에 대한 상기 연관된 메타데이터 태그를 포함하는 계층적 구조체를 가리키는 포인터인,
명령어를 처리하는 방법. - 시스템으로서,
프로세서; 및
실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행됨 -; 및
상기 대응하는 메타데이터 태그에 따라 상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 제 1 메모리 위치의 다수의 데이터 부분 중 적어도 하나를 사용하는 동작을 수행하는 것을 허용할지를 결정하는 단계를 포함하고,
상기 제 1 메모리 위치는 단일 메타데이터 태그와 연관되고, 상기 다수의 데이터 부분은 연관된 메타데이터 태그를 갖고, 상기 다수의 데이터 부분 각각에 대해, 상기 단일 메타데이터 태그는 상기 각각의 다수의 데이터 부분에 대해 상기 연관된 메타데이터 태그 중 특정 메타데이터 태그를 획득하거나 결정하기 위해 사용되는,
시스템. - 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독가능한 매체로서,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행됨 -; 및
상기 대응하는 메타데이터 태그에 따라 상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 제 1 메모리 위치의 다수의 데이터 부분 중 적어도 하나를 사용하는 동작을 수행하는 것을 허용할지를 결정하는 단계를 포함하고,
상기 제 1 메모리 위치는 단일 메타데이터 태그와 연관되고, 상기 다수의 데이터 부분은 연관된 메타데이터 태그를 갖고, 상기 다수의 데이터 부분 각각에 대해, 상기 단일 메타데이터 태그는 상기 각각의 다수의 데이터 부분에 대해 상기 연관된 메타데이터 태그 중 특정 메타데이터 태그를 획득하거나 결정하기 위해 사용되는,
비일시적 컴퓨터 판독가능한 매체. - 명령어를 처리하는 방법으로서,
메타데이터 처리를 위해, 연관된 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행됨 -;
상기 메타데이터 처리 도메인에서 상기 현재 명령어 및 상기 현재 명령어와 연관된 메타데이터 태그에 따라, 상기 현재 명령어에 대해 규칙이 규칙 캐시 내에 존재하는지를 결정하는 단계 - 상기 규칙 캐시는 허용된 동작을 정의하는 상기 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙을 포함함 -; 및
상기 현재 명령어에 대해 어떠한 규칙도 상기 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 상기 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 단계를 포함하고,
상기 규칙 캐시 미스 처리는 하드웨어-구현된(hardware-implemented) 규칙 캐시 미스 핸들러인 제 1 규칙 캐시 미스 핸들러를 사용하여 하나 이상의 규칙들의 제 1 세트에 대해 제 1 규칙 캐시 미스를 수행하는 단계를 포함하고, 상기 하드웨어-구현된 규칙 캐시 미스 핸들러는 상기 하드웨어의 출력을 발생하고, 상기 출력은 상기 규칙 캐시 미스 처리를 트리거하는 현재 명령어에 대한 새로운 규칙을 형성하는데 사용되는 메타데이터 태그를 포함하는,
명령어를 처리하는 방법. - 제 33 항에 있어서,
복합 정책은 상기 메타데이터 처리에 의해 상기 현재 명령어에 대해 동시에 시행되는 다수의 정책을 포함하고, 상기 복합 정책은 제 1 정책 및 제 2 정책을 포함하고, 상기 제 1 정책은 상기 하나 이상의 규칙들의 제 1 세트를 포함하며 상기 제 2 정책은 하나 이상의 규칙들의 제 2 세트를 포함하는,
명령어를 처리하는 방법. - 제 34 항에 있어서,
상기 규칙 캐시 미스 처리는 상기 메타데이터 처리 도메인에서 프로세서 상에서 소프트웨어-구현된(software-implemented) 규칙 캐시 미스 핸들러의 코드를 실행함으로써 하나 이상의 규칙들의 제 2 세트에 대해 상기 제 2 규칙 캐시 미스 처리를 수행하는 상기 소프트웨어-구현된 규칙 캐시 미스 핸들러인 제 2 규칙 캐시 미스 핸들러를 사용하여 상기 제 2 규칙 세트에 대한 상기 제 2 규칙 캐시 미스 처리를 수행하는 단계를 포함하는,
명령어를 처리하는 방법. - 제 35 항에 있어서,
상기 제 1 규칙 캐시 미스 처리는 제 1 출력 메타데이터 태그를 포함하는 제 1 출력을 발생하는 상기 하드웨어-구현된 규칙 캐시 미스 핸들러를 포함하며, 상기 제 2 규칙 캐시 미스 처리는 제 2 출력 메타데이터 태그를 포함하는 제 2 출력을 발생하는 상기 소프트웨어-구현된 규칙 캐시 미스 핸들러를 포함하는,
명령어를 처리하는 방법. - 제 36 항에 있어서,
상기 규칙 캐시 미스 처리는 상기 제 1 출력 및 상기 제 2 출력에 따라 합성 결과를 발생하는 단계를 포함하고, 상기 합성 결과는 합성 메타데이터 태그를 포함하는,
명령어를 처리하는 방법. - 제 37 항에 있어서,
상기 규칙 캐시 미스 처리는:
상기 현재 규칙에 대한 상기 새로운 규칙을 발생하는 단계 - 상기 새로운 규칙은 상기 현재 규칙에 따른 입력 메타데이터 태그, 상기 현재 명령어의 opcode 및 상기 복합 메타데이터 태그를 포함하고, 상기 복합 메타데이터 태그는 상기 새로운 규칙에 대한 출력 태그임 -; 및
상기 새로운 규칙을 상기 규칙 캐시에 삽입하는 단계를 포함하는,
명령어를 처리하는 방법. - 제 38 항에 있어서,
상기 입력 메타데이터 태그 및 상기 현재 명령어의 opcode는 상기 제 1 규칙 캐시 미스 처리에서 사용하기 위한 상기 하드웨어-구현된 규칙 캐시 미스 핸들러로의 입력으로서 제공되며 상기 제 2 규칙 캐시 미스 처리에서 사용하기 위한 상기 소프트웨어-구현된 규칙 캐시 핸들러로의 입력으로서 제공되는,
명령어를 처리하는 방법. - 제 33 항에 있어서,
상기 하드웨어-구현된 규칙 캐시 미스 핸들러는 전용 하드웨어를 사용하여 상기 제 1 규칙 캐시 미스 처리를 수행하는,
명령어를 처리하는 방법. - 제 33 항에 있어서,
상기 하나 이상의 규칙들의 제 1 세트는: 메모리 안전 정책(memory safety policy), 제어 플로우 무결성 정책(control flow integrity policy) 및 스택 보호 정책(stack protection policy) 중 임의의 하나 이상에 대한 규칙을 포함하는,
명령어를 처리하는 방법. - 제 34 항에 있어서,
상기 복합 정책은 하드웨어를 사용하여 인코딩되고 시행되는 하드웨어-특정된 규칙을 갖는 적어도 하나의 정책을 포함하며,
상기 방법은 상기 현재 명령어에 대해 어떠한 규칙도 상기 규칙 캐시 내에 존재하지 않거나 또는 하드웨어-특정된 규칙이라고 결정하는 것에 응답하여 상기 규칙 캐시 미스 처리를 수행하는 단계를 포함하는,
명령어를 처리하는 방법. - 제 33 항에 있어서,
태그들의 캐시는 복수의 태그를 포함하며, 상기 제 1 규칙 캐시 미스 처리는 상기 태그들의 캐시로부터 적어도 하나의 새로운 태그를 할당하는 상기 하드웨어-구현된 규칙 캐시 미스 핸들러를 포함하며, 상기 방법은 상기 메타데이터 처리 도메인에서 코드를 주기적으로 실행하여 상기 하드웨어-구현된 규칙 캐시 미스 핸들러에 의한 할당에 이용 가능한 새로운 추가 태그로 상기 태그들의 캐시를 다시 채우는 단계를 포함하는,
명령어를 처리하는 방법. - 시스템으로서,
프로세서; 및
실행될 때 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 연관된 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행됨 -;
상기 메타데이터 처리 도메인에서 상기 현재 명령어 및 상기 현재 명령어와 연관된 메타데이터 태그에 따라, 상기 현재 명령어에 대해 규칙이 규칙 캐시 내에 존재하는지를 결정하는 단계 - 상기 규칙 캐시는 허용된 동작을 정의하는 상기 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙을 포함함 -; 및
상기 현재 명령어에 대해 어떠한 규칙도 상기 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 상기 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 단계를 포함하고,
상기 규칙 캐시 미스 처리는 하드웨어-구현된(hardware-implemented) 규칙 캐시 미스 핸들러인 제 1 규칙 캐시 미스 핸들러를 사용하여 하나 이상의 규칙들의 제 1 세트에 대해 제 1 규칙 캐시 미스를 수행하는 단계를 포함하고, 상기 하드웨어-구현된 규칙 캐시 미스 핸들러는 상기 하드웨어의 출력을 발생하고, 상기 출력은 상기 규칙 캐시 미스 처리를 트리거하는 현재 명령어에 대한 새로운 규칙을 형성하는데 사용되는 메타데이터 태그를 포함하는,
시스템. - 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독가능한 매체로서,
명령어를 처리하는 방법은:
메타데이터 처리를 위해, 연관된 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행됨 -;
상기 메타데이터 처리 도메인에서 상기 현재 명령어 및 상기 현재 명령어와 연관된 메타데이터 태그에 따라, 상기 현재 명령어에 대해 규칙이 규칙 캐시 내에 존재하는지를 결정하는 단계 - 상기 규칙 캐시는 허용된 동작을 정의하는 상기 메타데이터 처리에 의해 사용되는 메타데이터에 관한 규칙을 포함함 -; 및
상기 현재 명령어에 대해 어떠한 규칙도 상기 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 상기 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 단계를 포함하고,
상기 규칙 캐시 미스 처리는 하드웨어-구현된(hardware-implemented) 규칙 캐시 미스 핸들러인 제 1 규칙 캐시 미스 핸들러를 사용하여 하나 이상의 규칙들의 제 1 세트에 대해 제 1 규칙 캐시 미스를 수행하는 단계를 포함하고, 상기 하드웨어-구현된 규칙 캐시 미스 핸들러는 상기 하드웨어의 출력을 발생하고, 상기 출력은 상기 규칙 캐시 미스 처리를 트리거하는 현재 명령어에 대한 새로운 규칙을 형성하는데 사용되는 메타데이터 태그를 포함하는,
비일시적 컴퓨터 판독가능한 매체. - 명령어를 처리하는 방법으로서,
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되고, 메타데이터에 관한 규칙을 포함하는 규칙 캐시는 허용된 동작을 정의하는 메타데이터 처리 도메인에 의해 사용됨 -; 및
상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 동작을 수행하는 것을 허용할지를 결정하는 단계 - 상기 결정하는 단계는 상기 대응하는 메타데이터 태그를 포함하는 하나 이상의 메타데이터 태그에 따라 수행되며 상기 코드 실행 도메인은 제 1 물리적 처리 서브시스템이며 상기 메타데이터 처리 도메인은 제 1 물리적 처리 서브시스템과 별개인 제 2 물리적 처리 서브시스템인,
명령어를 처리하는 방법. - 제 46 항에 있어서,
상기 코드 실행 도메인은 상기 현재 명령어를 포함하는 사용자 프로그램을 실행하는 것과 관련하여 사용되는 제 1 메모리 및 제 1 프로세서를 포함하는,
명령어를 처리하는 방법. - 제 47 항에 있어서,
상기 메타데이터 처리 도메인은 상기 현재 명령어에 대한 메타데이터 처리를 수행하는 것과 관련하여 사용되는 제 2 프로세서를 포함하는,
명령어를 처리하는 방법. - 제 48 항에 있어서,
상기 메타데이터 처리 도메인은 상기 현재 명령어에 대한 상기 메타데이터 처리를 수행하는 것과 관련하여 사용되는 제 2 메모리를 포함하는,
명령어를 처리하는 방법. - 제 49 항에 있어서,
상기 하나 이상의 메타데이터 태그 중 적어도 제 1 메타데이터 태그는 상기 제 2 메모리 내의 제 1 위치의 어드레스를 나타내는 포인터이고, 상기 제 1 위치는 상기 현재 명령어의 메타데이터 처리와 관련하여 사용되는 제 1 메타데이터를 포함하는,
명령어를 처리하는 방법. - 제 49 항에 있어서,
상기 메타데이터 처리 도메인에서, 상기 현재 명령어에 대해 상기 규칙이 상기 규칙 캐시 내에 존재하는지를 결정하는 단계; 및
상기 현재 명령어에 대해 어떠한 규칙도 상기 규칙 캐시 내에 존재하지 않는다고 결정하는 것에 응답하여, 상기 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 단계를 더 포함하고,
상기 규칙 캐시 미스 처리는 상기 제 2 프로세서상에서, 규칙 캐시 미스 핸들러의 코드를 실행하여, 상기 현재 명령어에 대한 새로운 규칙을 발생하는 단계를 포함하는,
명령어를 처리하는 방법. - 제 51 항에 있어서,
상기 새로운 규칙은 상기 메타데이터 처리 도메인의 상기 제 2 프로세서에 의해 수행되는 처리에 응답하여 상기 규칙 캐시에 삽입되는,
명령어를 처리하는 방법. - 제 50 항에 있어서,
상기 현재 명령어에 대한 메타데이터 처리와 관련하여 사용되는 상기 하나 이상의 메타데이터 태그는 상기 메타데이터 처리 도메인 및 상기 규칙 캐시로의 하나 이상의 제 1 입력으로서 제공되고, 상기 하나 이상의 제 1 입력은 상기 메타데이터 처리 도메인에서 동작되는 데이터인,
명령어를 처리하는 방법. - 제 53 항에 있어서,
하나 이상의 결과 메타데이터 태그는 상기 규칙 캐시 및 상기 메타데이터 처리 도메인에 의한 하나 이상의 출력으로서 발생되는,
명령어를 처리하는 방법. - 제 54 항에 있어서,
상기 하나 이상의 메타데이터 결과 태그는 상기 제 1 메모리 내의 메모리 위치에 대한 태그 값으로서 저장된 제 1 결과 태그를 포함하는,
명령어를 처리하는 방법. - 제 54 항에 있어서,
상기 하나 이상의 메타데이터 결과 태그는 상기 코드 실행 도메인의 다음 명령어의 프로그램 카운터에 대한 태그 값으로서 저장되는 제 1 결과 태그를 포함하는,
명령어를 처리하는 방법. - 제 53 항에 있어서,
상기 메타데이터 처리 도메인으로의 하나 이상의 제 1 입력으로서 제공되는 상기 하나 이상의 메타데이터 태그는: 상기 현재 명령어의 오퍼랜드에 대한 하나 이상의 오퍼랜드 메타데이터 태그, 상기 현재 명령어의 프로그램 카운터에 대한 프로그램 카운터 메타데이터 태그, 상기 현재 명령어의 명령어 메타데이터 태그, 상기 현재 명령어에 대한 opgroup에 관한 opgroup 메타데이터 태그, 상기 현재 명령어의 임의의 추가 opcode 비트를 식별하는 상기 현재 명령어의 확장된 opcode와 함께 사용되는 제 1 opcode 정보 메타데이터 태그, 동일한 명령어 워드 내의 다수의 명령어 중 어느 것이 상기 현재 명령인지를 식별하는 제 2 opcode 정보 메타데이터 태그, 및 상기 메타데이터 처리 도메인으로의 상기 하나 이상의 제 1 입력 중 어느 것인지 그리고 상기 메타데이터 처리 도메인의 하나 이상의 출력이 상기 현재 명령어에 대해 무시되거나 사용되지 않는 것을 식별하는 care 비트 메타데이터 태그 중 하나 이상을 포함하는,
명령어를 처리하는 방법. - 제 53 항에 있어서,
상기 현재 명령어에 대해 상기 메타데이터 처리 도메인으로의 하나 이상의 제 1 입력들로서 제공되는 상기 하나 이상의 메타데이터 태그는 상기 제 1 프로세서 상에서 상기 현재 명령어를 실행할 때 상기 코드 실행 도메인에서 사용된 현재 명령어 입력과 연관된 메타데이터 태그인,
명령어를 처리하는 방법. - 제 49 항에 있어서,
상기 메타데이터 처리 도메인은 메타데이터 처리를 수행하는 것과 관련하여 상기 코드 실행 도메인의 상기 제 1 프로세서 및 상기 제 1 메모리에 액세스할 필요가 없는,
명령어를 처리하는 방법. - 제 46 항에 있어서,
메타데이터 처리는 제 1 규칙을 사용하여 수행되는 메타데이터 처리의 결과로서 발생된 제 1 값을 리턴하는,
명령어를 처리하는 방법. - 제 60 항에 있어서,
상기 제 1 값은 사용자 프로세스 어드레스 공간에서 실행되는 코드에 의해 상기 코드 실행 도메인에서 데이터로서 액세스 가능한 제 1 레지스터에 저장되는,
명령어를 처리하는 방법. - 제 61 항에 있어서,
상기 제 1 규칙은 상기 현재 명령어에 의해 트리거되는 상기 하나 이상의 규칙에 포함되는,
명령어를 처리하는 방법. - 제 62 항에 있어서,
상기 현재 명령어는 상기 제 1 규칙에 의해 사용되는 특수 코드 태그로 태깅되며, 상기 특수 코드 태그는 상기 현재 명령어가 실행되어 상기 제 1 레지스터에 저장된 상기 제 1 값을 상기 현재 명령어의 메타데이터 처리로부터 리턴된 것으로서 획득하는 것이 허용된 것임을 나타내는,
명령어를 처리하는 방법. - 제 63 항에 있어서,
상기 현재 명령어는 상기 현재 명령어가 상기 특수 코드 태그로 태깅될 때 메타데이터 처리가 값을 리턴하며, 그렇지 않으면 상기 현재 명령어가 상기 특수 코드 태그로 태깅되지 않을 때 상기 메타데이터 처리가 값을 리턴하지 않는 opcode를 포함하는,
명령어를 처리하는 방법. - 시스템으로서,
프로세서; 및
실행될 때 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되고, 메타데이터에 관한 규칙을 포함하는 규칙 캐시는 허용된 동작을 정의하는 메타데이터 처리 도메인에 의해 사용됨 -; 및
상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 동작을 수행하는 것을 허용할지를 결정하는 단계 - 상기 결정하는 단계는 상기 대응하는 메타데이터 태그를 포함하는 하나 이상의 메타데이터 태그에 따라 수행되며 상기 코드 실행 도메인은 제 1 물리적 처리 서브시스템이며 상기 메타데이터 처리 도메인은 제 1 물리적 처리 서브시스템과 별개의 제 2 물리적 처리 서브시스템인,
시스템. - 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독가능한 매체로서,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되고, 메타데이터에 관한 규칙을 포함하는 규칙 캐시는 허용된 동작을 정의하는 메타데이터 처리 도메인에 의해 사용됨 -; 및
상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 동작을 수행하는 것을 허용할지를 결정하는 단계 - 상기 결정하는 단계는 상기 대응하는 메타데이터 태그를 포함하는 하나 이상의 메타데이터 태그에 따라 수행되며 상기 코드 실행 도메인은 제 1 물리적 처리 서브시스템이며 상기 메타데이터 처리 도메인은 제 1 물리적 처리 서브시스템과 별개인 제 2 물리적 처리 서브시스템인,
비일시적 컴퓨터 판독가능한 매체. - 메타데이터 규칙-기반 중재된 데이터 이전(rule-based mediated data transfer)을 수행하기 위한 방법으로서,
제 1 디바이스로부터 제 1 직접 메모리 액세스 명령어를 발행하는 단계 - 상기 제 1 직접 메모리 액세스 명령어는 제 1 메타데이터 태그를 갖는 제 1 메모리 위치에 저장된 제 1 데이터에 액세스하고, 상기 제 1 메모리 위치는 제 1 인터커넥트 패브릭에 연결된 제 1 메모리에 포함되고, 상기 제 1 디바이스는 신뢰성 없는 디바이스이며 제 2 인터커넥트 패브릭에 연결됨 -; 및
상기 제 2 인터커넥트 패브릭으로부터 상기 제 1 인터커넥트 패브릭으로 발행된 상기 제 1 직접 메모리 액세스 명령어를 중재하는 처리를 수행하는 단계를 포함하고,
상기 처리는:
직접 메모리 액세스 명령어에 대한 메타데이터 규칙을 포함하는 제 1 규칙 캐시를 사용하며 상기 제 1 직접 메모리 액세스 명령어에 사용되는 하나 이상의 메타데이터 태그에 따라, 상기 제 1 직접 메모리 액세스 명령어의 실행을 허용할지를 결정하는 단계를 포함하고, 상기 제 1 규칙 캐시는 허용된 직접 메모리 액세스 동작을 정의하기 위해 사용되는 직접 메모리 액세스 명령어에 대한 메타데이터 규칙을 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법. - 제 67 항에 있어서,
제 2 규칙 캐시의 메타데이터 규칙을 사용하는 메타데이터 처리 도메인에서, 상기 메타데이터 처리 도메인으로부터 격리된 코드 실행 도메인에서 제 2 명령어의 실행을 허용할지를 결정하는 메타데이터 처리를 수행하는 단계를 더 포함하고, 상기 제2 명령어는 상기 코드 실행 도메인의 프로세서 상에서 실행되는 사용자 코드에 포함되는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 68 항에 있어서,
상기 처리는:
상기 제 1 직접 메모리 액세스 명령어에 사용된 상기 하나 이상의 메타데이터 태그에 따라, 상기 제 1 직접 메모리 액세스 명령어에 대해 규칙이 제 1 규칙 캐시에 존재하는지를 결정하는 단계;
상기 제 1 직접 메모리 액세스 명령어에 대해 어떠한 규칙도 상기 제 1 규칙 캐시에 존재하지 않는다는 결정에 응답하여, 상기 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 단계를 더 포함하고,
상기 메타데이터 처리 도메인에서 규칙 캐시 미스 처리를 수행하는 상기 단계는;
상기 제 1 직접 메모리 액세스 명령어의 실행이 허용되는지를 결정하는 단계;
상기 제 1 직접 메모리 액세스 명령어가 허용된 것으로 결정하는 것에 응답하여, 상기 제 1 직접 메모리 액세스 명령어에 대한 새로운 규칙을 발생하는 단계; 및
상기 새로운 규칙을 상기 제 1 규칙 캐시에 삽입하는 단계를 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 67 항에 있어서,
상기 제 1 명령어는 상기 제 1 메모리 위치로부터 임의의 판독하는 것 및 상기 제 1 메모리 위치에 기입하는 것 중 하나를 포함하는 동작을 수행하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 67 항에 있어서,
상기 제 2 인터커넥트 패브릭은 상기 제 1 디바이스를 포함하는 복수의 신뢰성 없는 디바이스를 포함하고, 상기 복수의 디바이스에 의해 발행된 직접 메모리 액세스 명령어는 상기 제 1 메모리의 메모리 위치에 액세스하려는 신뢰성 없는 요청인,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 67 항에 있어서,
상기 처리는:
상기 제 1 메모리로부터 상기 제 1 메모리 위치에 대한 상기 제 1 메타데이터 태그를 획득하는 단계;
상기 제 1 직접 메모리 액세스 명령어의 실행을 허용할지를 결정하기 위해 사용되는 상기 하나 이상의 메타데이터 태그 중 제 1 메타데이터 태그로서 상기 제 1 메타데이터 태그를 제공하는 단계를 더 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 72 항에 있어서,
상기 제 1 직접 메모리 액세스 명령어의 실행을 허용할지를 결정하기 위해 사용되는 상기 하나 이상의 메타데이터 태그는 상기 제 1 메타데이터 태그를 비롯한 그리고 추가적으로 상기 제 1 디바이스를 고유하게 식별하는 디바이스 식별자를 나타내는 상기 제 1 직접 메모리 액세스 명령어에 대한 현재 명령어 메타데이터 태그를 비롯한 복수의 메타데이터 태그를 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 73 항에 있어서,
상기 복수의 메타데이터 태그는 상기 제 1 디바이스의 현재 상태를 표시하며 그리고 상기 제 1 디바이스로부터의 직접 메모리 액세스 명령어가 인에이블 또는 디스에이블되는지를 표시하는 프로그램 카운터 메타데이터 태그를 더 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 74 항에 있어서,
상기 복수의 메타데이터 태그는 상기 제 1 메모리 위치의 어느 하나 이상의 바이트가 상기 제 1 직접 메모리 액세스 명령어에 의해 액세스되고 있음을 식별하는 바이트 인에이블 메타데이터 태그를 더 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 75 항에 있어서,
상기 제 1 직접 메모리 액세스 명령어의 실행을 허용할지를 결정하기 위해 사용되는 상기 복수의 메타데이터 태그는 레지스터들의 제 1 세트에 상기 제 1 규칙 캐시로의 입력으로서 제공되며, 레지스터들의 제 2 세트는 제 1 규칙 캐시의 출력을 저장하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 76 항에 있어서,
상기 제 2 레지스터 세트는 다음 명령어에 대한 프로그램 카운터의 다음 태그를 포함하는 제 1 출력 레지스터를 포함하고, 상기 다음 태그는 상기 제 1 직접 메모리 액세스를 수행한 후 상기 제 1 디바이스의 상태를 나타내는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법 - 제 77 항에 있어서,
상기 제 2 레지스터 세트는 상기 제 1 직접 메모리 액세스 명령어가 상기 제 1 메모리 위치를 저장하거나 상기 제 1 메모리 위치에 기입하는 것이면 메모리 결과에 놓이는 태그를 포함하는 제 2 출력 레지스터를 포함하는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법. - 제 69 항에 있어서,
현재 트랜잭션 식별자가 트랜잭션 식별자 레지스터에 저장되며, 커밋 레지스터에 기입하는 것은 상기 커밋 레지스터의 현재 내용과 상기 트랜잭션 식별자 레지스터의 현재 내용 사이의 비교를 초래하고, 이에 의해 상기 커밋 레지스터의 상기 현재 내용이 상기 트랜잭션 식별자 레지스터의 상기 현재 내용과 매칭한다고 결정하는 것에 응답하여, 상기 새로운 규칙이 상기 제 1 규칙 캐시에 기입되는,
메타데이터 규칙-기반 중재된 데이터 이전을 수행하기 위한 방법. - 시스템으로서,
프로세서; 및
실행될 때 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 메모리를 포함하고,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되고, 메타데이터에 관한 규칙을 포함하는 규칙 캐시는 허용된 동작을 정의하는 메타데이터 처리 도메인에 의해 사용됨 -; 및
상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 동작을 수행하도록 허용할지를 결정하는 단계를 포함하고,
상기 결정하는 단계는 상기 대응하는 메타데이터 태그를 포함하는 하나 이상의 메타데이터 태그에 따라 수행되며 상기 코드 실행 도메인은 제 1 물리적 처리 서브시스템이며 상기 메타데이터 처리 도메인은 상기 제 1 물리적 처리 서브시스템과 별개의 제 2 물리적 처리 서브시스템인,
시스템. - 실행될 때, 명령어를 처리하는 방법을 수행하는 저장된 코드를 포함하는 비일시적 컴퓨터 판독가능한 매체로서,
명령어를 처리하는 상기 방법은:
메타데이터 처리를 위해, 대응하는 메타데이터 태그를 갖는 현재 명령어를 수신하는 단계 - 상기 메타데이터 처리는 상기 현재 명령어를 포함하는 코드 실행 도메인으로부터 격리된 메타데이터 처리 도메인에서 수행되고, 메타데이터에 관한 규칙을 포함하는 규칙 캐시는 허용된 동작을 정의하는 메타데이터 처리 도메인에 의해 사용됨 -; 및
상기 현재 명령어에 의해 트리거되는 하나 이상의 규칙을 사용하는 상기 메타데이터 처리 도메인에서, 상기 현재 명령어가 동작을 수행하도록 허용할지를 결정하는 단계를 포함하고,
상기 결정하는 단계는 상기 대응하는 메타데이터 태그를 포함하는 하나 이상의 메타데이터 태그에 따라 수행되며 상기 코드 실행 도메인은 제 1 물리적 처리 서브시스템이며 상기 메타데이터 처리 도메인은 상기 제 1 물리적 처리 서브시스템과 별개의 제 2 물리적 처리 서브시스템인,
비일시적 컴퓨터 판독가능한 매체.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020217036219A KR102514351B1 (ko) | 2015-12-17 | 2016-12-12 | 메타데이터 처리 기술 |
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201562268639P | 2015-12-17 | 2015-12-17 | |
| US62/268,639 | 2015-12-17 | ||
| US201562270187P | 2015-12-21 | 2015-12-21 | |
| US62/270,187 | 2015-12-21 | ||
| US15/168,689 | 2016-05-31 | ||
| US15/168,689 US10235176B2 (en) | 2015-12-17 | 2016-05-31 | Techniques for metadata processing |
| PCT/US2016/066194 WO2017106103A1 (en) | 2015-12-17 | 2016-12-12 | Techniques for metadata processing |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020217036219A Division KR102514351B1 (ko) | 2015-12-17 | 2016-12-12 | 메타데이터 처리 기술 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20190029501A true KR20190029501A (ko) | 2019-03-20 |
| KR102572262B1 KR102572262B1 (ko) | 2023-08-30 |
Family
ID=57708815
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020187020288A KR102572262B1 (ko) | 2015-12-17 | 2016-12-12 | 메타데이터 프로세싱 기술 |
| KR1020187020285A KR102610802B1 (ko) | 2015-12-17 | 2016-12-12 | 메타데이터 프로세싱 기술 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020187020285A KR102610802B1 (ko) | 2015-12-17 | 2016-12-12 | 메타데이터 프로세싱 기술 |
Country Status (7)
| Country | Link |
|---|---|
| US (14) | US10235176B2 (ko) |
| EP (2) | EP3387577B1 (ko) |
| JP (2) | JP7053486B2 (ko) |
| KR (2) | KR102572262B1 (ko) |
| CN (2) | CN108885660B (ko) |
| SG (2) | SG11201804733YA (ko) |
| WO (2) | WO2017106103A1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20220068355A (ko) * | 2020-11-19 | 2022-05-26 | 주식회사 올리브텍 | 스토리지 운영체제의 커널 수준에서 파일에 지정된 열람제한시간 동안 파일 내용 읽기 및 쓰기를 원천적으로 방지하는 데이터 보호 방법 |
Families Citing this family (81)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3195178B1 (en) * | 2014-07-23 | 2019-02-20 | GrammaTech, Inc. | Systems and/or methods for automatically protecting against memory corruption vulnerabilities |
| US10078763B2 (en) | 2014-11-19 | 2018-09-18 | BAE Systems Information and Electronic Systems Integration Incc | Programmable unit for metadata processing |
| EP4131199A1 (en) | 2015-07-07 | 2023-02-08 | Ilumi Solutions, Inc. | Wireless communication methods |
| US11978336B2 (en) | 2015-07-07 | 2024-05-07 | Ilumi Solutions, Inc. | Wireless control device and methods thereof |
| US10339796B2 (en) | 2015-07-07 | 2019-07-02 | Ilumi Sulutions, Inc. | Wireless control device and methods thereof |
| US9916141B2 (en) * | 2015-10-15 | 2018-03-13 | International Business Machines Corporation | Modifying execution flow in save-to-return code scenarios |
| US10936713B2 (en) | 2015-12-17 | 2021-03-02 | The Charles Stark Draper Laboratory, Inc. | Techniques for metadata processing |
| US10235176B2 (en) | 2015-12-17 | 2019-03-19 | The Charles Stark Draper Laboratory, Inc. | Techniques for metadata processing |
| US20200175451A1 (en) * | 2016-02-29 | 2020-06-04 | Dimensional Insight Incorporated | Hospital operations measurement and performance analysis factory instance of a measure factory |
| GB2547912B (en) * | 2016-03-02 | 2019-01-30 | Advanced Risc Mach Ltd | Register access control |
| US9928128B2 (en) * | 2016-04-01 | 2018-03-27 | International Business Machines Corporation | In-pipe error scrubbing within a processor core |
| US20180024751A1 (en) * | 2016-07-19 | 2018-01-25 | Western Digital Technologies, Inc. | Metadata management on a storage device |
| US10346625B2 (en) * | 2016-10-31 | 2019-07-09 | International Business Machines Corporation | Automated mechanism to analyze elevated authority usage and capability |
| US10896267B2 (en) * | 2017-01-31 | 2021-01-19 | Hewlett Packard Enterprise Development Lp | Input/output data encryption |
| US10289555B1 (en) * | 2017-04-14 | 2019-05-14 | EMC IP Holding Company LLC | Memory read-ahead using learned memory access patterns |
| CN108733311B (zh) * | 2017-04-17 | 2021-09-10 | 伊姆西Ip控股有限责任公司 | 用于管理存储系统的方法和设备 |
| US10650156B2 (en) | 2017-04-26 | 2020-05-12 | International Business Machines Corporation | Environmental security controls to prevent unauthorized access to files, programs, and objects |
| US10567384B2 (en) * | 2017-08-25 | 2020-02-18 | Hewlett Packard Enterprise Development Lp | Verifying whether connectivity in a composed policy graph reflects a corresponding policy in input policy graphs |
| US10396944B2 (en) | 2017-09-19 | 2019-08-27 | International Business Machines Corporation | Low latency corrupt data tagging on a cross-chip link |
| EP3460709B1 (en) * | 2017-09-26 | 2022-02-09 | Secure-IC SAS | Devices and methods for secured processors |
| CN107864139B (zh) * | 2017-11-09 | 2020-05-12 | 北京科技大学 | 一种基于动态规则的密码学属性基访问控制方法与系统 |
| US10719722B2 (en) | 2017-11-12 | 2020-07-21 | Bendix Commercial Vehicle Systems Llc | Driving oriented digital video recorder system |
| US11698964B2 (en) * | 2017-12-13 | 2023-07-11 | Intel Corporation | Malware detection in memory |
| US10552162B2 (en) * | 2018-01-22 | 2020-02-04 | International Business Machines Corporation | Variable latency flush filtering |
| SG11202007272QA (en) * | 2018-02-02 | 2020-08-28 | Charles Stark Draper Laboratory Inc | Systems and methods for policy execution processing |
| TW201935305A (zh) * | 2018-02-02 | 2019-09-01 | 美商多佛微系統公司 | 用於後快取互鎖之系統和方法 |
| WO2019152792A1 (en) | 2018-02-02 | 2019-08-08 | Dover Microsystems, Inc. | Systems and methods for policy linking and/or loading for secure initialization |
| EP3788488A1 (en) | 2018-04-30 | 2021-03-10 | Dover Microsystems, Inc. | Systems and methods for checking safety properties |
| US11573800B2 (en) | 2018-07-05 | 2023-02-07 | Marvell Asia Pte, Ltd. | Complex I/O value prediction for multiple values with physical or virtual addresses |
| US11216432B2 (en) * | 2018-07-06 | 2022-01-04 | Cfph, Llc | Index data structures and graphical user interface |
| US11030149B2 (en) * | 2018-09-06 | 2021-06-08 | Sap Se | File format for accessing data quickly and efficiently |
| CN110018848B (zh) * | 2018-09-29 | 2023-07-11 | 广州安凯微电子股份有限公司 | 一种基于risc-v的混合混算系统及方法 |
| US10545850B1 (en) | 2018-10-18 | 2020-01-28 | Denso International America, Inc. | System and methods for parallel execution and comparison of related processes for fault protection |
| US11108674B2 (en) | 2018-10-30 | 2021-08-31 | Bank Of America Corporation | Data management system and method |
| TW202022678A (zh) | 2018-11-06 | 2020-06-16 | 美商多佛微系統公司 | 用於停滯主處理器的系統和方法 |
| US20220012329A1 (en) * | 2018-11-12 | 2022-01-13 | Dover Microsystems, Inc. | Systems and methods for metadata encoding |
| US11741196B2 (en) * | 2018-11-15 | 2023-08-29 | The Research Foundation For The State University Of New York | Detecting and preventing exploits of software vulnerability using instruction tags |
| CN109710312A (zh) * | 2018-12-13 | 2019-05-03 | 华东计算技术研究所（中国电子科技集团公司第三十二研究所） | 基于risc-v指令集的实时中断处理方法、装置及工控处理器 |
| WO2020132012A1 (en) * | 2018-12-18 | 2020-06-25 | Dover Microsystems, Inc. | Systems and methods for data lifecycle protection |
| CN109729158B (zh) * | 2018-12-19 | 2021-09-28 | 深圳市酷开网络科技股份有限公司 | 一种设备id标识信息的生成方法、系统及存储介质 |
| CN109672892A (zh) * | 2018-12-25 | 2019-04-23 | 广东浪潮大数据研究有限公司 | 一种图像压缩装置、方法和fpga板卡 |
| WO2020150351A1 (en) * | 2019-01-18 | 2020-07-23 | Dover Microsystems, Inc. | Systems and methods for metadata classification |
| US11232208B2 (en) | 2019-02-26 | 2022-01-25 | The Trustees Of The University Of Pennsylvania | Methods, systems, and computer readable media for adaptive metadata architecture |
| US11868466B2 (en) | 2019-03-12 | 2024-01-09 | Huawei Technologies Co., Ltd. | Apparatus and method for enforcing hardware-assisted memory safety |
| CN110007964A (zh) * | 2019-03-15 | 2019-07-12 | 芯来科技(武汉)有限公司 | 用于risc-v架构的中断系统 |
| US11782816B2 (en) * | 2019-03-19 | 2023-10-10 | Jens C. Jenkins | Input/output location transformations when emulating non-traced code with a recorded execution of traced code |
| US11194764B1 (en) * | 2019-03-21 | 2021-12-07 | Amazon Technologies, Inc. | Tag policies for tagging system |
| US11068269B1 (en) | 2019-05-20 | 2021-07-20 | Parallels International Gmbh | Instruction decoding using hash tables |
| TWI722496B (zh) * | 2019-06-20 | 2021-03-21 | 慧榮科技股份有限公司 | 使用者資料的加解密方法及裝置 |
| US11580234B2 (en) | 2019-06-29 | 2023-02-14 | Intel Corporation | Implicit integrity for cryptographic computing |
| US11645425B2 (en) | 2019-07-03 | 2023-05-09 | Beyond Semiconductor, d.o.o. | Systems and methods for data-driven secure and safe computing |
| CN110472388B (zh) * | 2019-07-22 | 2023-07-04 | 吉林大学 | 一种设备管控系统及其用户权限控制方法 |
| US11275840B2 (en) * | 2019-07-29 | 2022-03-15 | Sap Se | Management of taint information attached to strings |
| CN110443214B (zh) * | 2019-08-12 | 2022-03-01 | 山东浪潮科学研究院有限公司 | 一种基于risc-v的人脸识别加速电路系统及加速方法 |
| US11947663B2 (en) * | 2019-09-24 | 2024-04-02 | The Trustees Of Columbia University In The City Of New York | Control flow protection based on phantom addressing |
| US10956135B1 (en) * | 2019-10-11 | 2021-03-23 | International Business Machines Corporation | Enforcing policy in dataflows |
| US11362997B2 (en) * | 2019-10-16 | 2022-06-14 | International Business Machines Corporation | Real-time policy rule evaluation with multistage processing |
| WO2021076871A1 (en) * | 2019-10-18 | 2021-04-22 | Dover Microsystems, Inc. | Systems and methods for updating metadata |
| CN110866492B (zh) * | 2019-11-13 | 2022-12-13 | 广州品唯软件有限公司 | 一种基线分支的识别方法、装置及计算机系统 |
| CN110889147B (zh) * | 2019-11-14 | 2022-02-08 | 中国人民解放军国防科技大学 | 一种利用填充缓存抵御Cache边信道攻击的方法 |
| CN110806719B (zh) * | 2019-12-04 | 2021-08-27 | 深圳市英威腾电气股份有限公司 | 一种plc系统及其控制方法 |
| US20220121738A1 (en) * | 2020-02-27 | 2022-04-21 | The Trustees Of The University Of Pennsylvania | Methods, systems, and computer readable media for main memory tag compression |
| KR102338774B1 (ko) * | 2020-06-01 | 2021-12-14 | 주식회사 올리브텍 | 스토리지 운영체제의 커널 수준에서 파일 내용 읽기 및 쓰기를 방지하여 데이터 유출 및 훼손을 방지하는 데이터 보호 방법 |
| CN111857831B (zh) * | 2020-06-11 | 2021-07-20 | 成都海光微电子技术有限公司 | 一种存储体冲突优化方法、并行处理器及电子设备 |
| US11550715B2 (en) * | 2020-08-16 | 2023-01-10 | Mellanox Technologies, Ltd. | Virtual splitting of memories |
| US11714897B2 (en) * | 2020-09-02 | 2023-08-01 | Mobileye Vision Technologies Ltd. | Secure distributed execution of jobs |
| CN112181529A (zh) * | 2020-10-12 | 2021-01-05 | Oppo广东移动通信有限公司 | 应用程序控制方法、装置以及电子设备 |
| US20220129343A1 (en) * | 2020-10-22 | 2022-04-28 | Dover Microsystems, Inc. | Systems and methods for reducing exception latency |
| US11790085B2 (en) * | 2020-10-29 | 2023-10-17 | Electronics And Telecommunications Research Institute | Apparatus for detecting unknown malware using variable opcode sequence and method using the same |
| CN112256330B (zh) * | 2020-11-03 | 2021-11-09 | 中国人民解放军军事科学院国防科技创新研究院 | 用于加速数字信号处理的risc-v指令集扩展方法 |
| US11669625B2 (en) | 2020-12-26 | 2023-06-06 | Intel Corporation | Data type based cryptographic computing |
| US11599625B2 (en) | 2021-01-28 | 2023-03-07 | Qualcomm Incorporated | Techniques for instruction perturbation for improved device security |
| US20220391525A1 (en) * | 2021-05-10 | 2022-12-08 | Beyond Semiconductor, d.o.o. | Inter system policy federation in a data-driven secure and safe computing environment |
| US11379468B1 (en) * | 2021-05-12 | 2022-07-05 | International Business Machines Corporation | Control flow graph refining via execution data |
| US11630670B2 (en) | 2021-07-21 | 2023-04-18 | Apple Inc. | Multi-table signature prefetch |
| CN113687971B (zh) * | 2021-08-24 | 2023-06-27 | 杭州迪普科技股份有限公司 | 内存映象文件的生成方法及装置 |
| CN113835927B (zh) * | 2021-09-23 | 2023-08-11 | 武汉深之度科技有限公司 | 一种指令执行方法、计算设备及存储介质 |
| KR20230106427A (ko) * | 2022-01-06 | 2023-07-13 | 부산대학교 산학협력단 | 분기 태그 지정 확장을 위한 리스크 파이브 아키텍처 명령어 확장을 위한 장치 및 방법 |
| US20230305845A1 (en) * | 2022-03-22 | 2023-09-28 | Nvidia Corporation | Techniques to selectively store data |
| US20240143432A1 (en) * | 2022-10-28 | 2024-05-02 | Nxp B.V. | Data processing system with tag-based queue management |
| CN115687538B (zh) * | 2022-11-14 | 2023-04-25 | 深圳标普云科技有限公司 | 一种企业信息采集分析方法及系统 |
Family Cites Families (271)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US1054576A (en) | 1909-07-16 | 1913-02-25 | Isaiah B Libbey | Unloading device. |
| US1073977A (en) | 1913-03-07 | 1913-09-23 | Ralph P Fox | Safety-support for flying-machines. |
| US5201056A (en) * | 1990-05-02 | 1993-04-06 | Motorola, Inc. | RISC microprocessor architecture with multi-bit tag extended instructions for selectively attaching tag from either instruction or input data to arithmetic operation output |
| US5778423A (en) | 1990-06-29 | 1998-07-07 | Digital Equipment Corporation | Prefetch instruction for improving performance in reduced instruction set processor |
| EP0463965B1 (en) | 1990-06-29 | 1998-09-09 | Digital Equipment Corporation | Branch prediction unit for high-performance processor |
| US5287467A (en) | 1991-04-18 | 1994-02-15 | International Business Machines Corporation | Pipeline for removing and concurrently executing two or more branch instructions in synchronization with other instructions executing in the execution unit |
| US7095783B1 (en) * | 1992-06-30 | 2006-08-22 | Discovision Associates | Multistandard video decoder and decompression system for processing encoded bit streams including start codes and methods relating thereto |
| US5628021A (en) * | 1992-12-31 | 1997-05-06 | Seiko Epson Corporation | System and method for assigning tags to control instruction processing in a superscalar processor |
| JPH06332664A (ja) | 1993-03-23 | 1994-12-02 | Toshiba Corp | 表示制御システム |
| US5485455A (en) | 1994-01-28 | 1996-01-16 | Cabletron Systems, Inc. | Network having secure fast packet switching and guaranteed quality of service |
| US5664223A (en) | 1994-04-05 | 1997-09-02 | International Business Machines Corporation | System for independently transferring data using two independently controlled DMA engines coupled between a FIFO buffer and two separate buses respectively |
| US5655100A (en) | 1995-03-31 | 1997-08-05 | Sun Microsystems, Inc. | Transaction activation processor for controlling memory transaction execution in a packet switched cache coherent multiprocessor system |
| US5684977A (en) | 1995-03-31 | 1997-11-04 | Sun Microsystems, Inc. | Writeback cancellation processing system for use in a packet switched cache coherent multiprocessor system |
| US5848433A (en) | 1995-04-12 | 1998-12-08 | Advanced Micro Devices | Way prediction unit and a method for operating the same |
| US5764946A (en) | 1995-04-12 | 1998-06-09 | Advanced Micro Devices | Superscalar microprocessor employing a way prediction unit to predict the way of an instruction fetch address and to concurrently provide a branch prediction address corresponding to the fetch address |
| US5664197A (en) | 1995-04-21 | 1997-09-02 | Intel Corporation | Method and apparatus for handling bus master channel and direct memory access (DMA) channel access requests at an I/O controller |
| US7301541B2 (en) * | 1995-08-16 | 2007-11-27 | Microunity Systems Engineering, Inc. | Programmable processor and method with wide operations |
| JPH0969047A (ja) * | 1995-09-01 | 1997-03-11 | Sony Corp | Ｒｉｓｃ型マイクロプロセッサおよび情報処理装置 |
| US5864707A (en) | 1995-12-11 | 1999-01-26 | Advanced Micro Devices, Inc. | Superscalar microprocessor configured to predict return addresses from a return stack storage |
| US6058466A (en) | 1997-06-24 | 2000-05-02 | Sun Microsystems, Inc. | System for allocation of execution resources amongst multiple executing processes |
| US6035374A (en) | 1997-06-25 | 2000-03-07 | Sun Microsystems, Inc. | Method of executing coded instructions in a multiprocessor having shared execution resources including active, nap, and sleep states in accordance with cache miss latency |
| US5890008A (en) | 1997-06-25 | 1999-03-30 | Sun Microsystems, Inc. | Method for dynamically reconfiguring a processor |
| US6240502B1 (en) | 1997-06-25 | 2001-05-29 | Sun Microsystems, Inc. | Apparatus for dynamically reconfiguring a processor |
| US5941981A (en) | 1997-11-03 | 1999-08-24 | Advanced Micro Devices, Inc. | System for using a data history table to select among multiple data prefetch algorithms |
| US6321297B1 (en) | 1998-01-05 | 2001-11-20 | Intel Corporation | Avoiding tag compares during writes in multi-level cache hierarchy |
| US6157955A (en) | 1998-06-15 | 2000-12-05 | Intel Corporation | Packet processing system including a policy engine having a classification unit |
| US6351784B1 (en) | 1998-12-28 | 2002-02-26 | International Business Machines Corp. | System for determining whether a subsequent transaction may be allowed or must be allowed or must not be allowed to bypass a preceding transaction |
| US6324599B1 (en) | 1999-01-11 | 2001-11-27 | Oak Technology | Computer system and method for tracking DMA transferred data within a read-ahead local buffer without interrupting the host processor |
| US6247097B1 (en) | 1999-01-22 | 2001-06-12 | International Business Machines Corporation | Aligned instruction cache handling of instruction fetches across multiple predicted branch instructions |
| US6636523B1 (en) | 1999-01-27 | 2003-10-21 | Advanced Micro Devices, Inc. | Flow control using rules queue monitoring in a network switching system |
| US7941647B2 (en) * | 1999-01-28 | 2011-05-10 | Ati Technologies Ulc | Computer for executing two instruction sets and adds a macroinstruction end marker for performing iterations after loop termination |
| US8127121B2 (en) | 1999-01-28 | 2012-02-28 | Ati Technologies Ulc | Apparatus for executing programs for a first computer architechture on a computer of a second architechture |
| US7065633B1 (en) | 1999-01-28 | 2006-06-20 | Ati International Srl | System for delivering exception raised in first architecture to operating system coded in second architecture in dual architecture CPU |
| US8065504B2 (en) | 1999-01-28 | 2011-11-22 | Ati International Srl | Using on-chip and off-chip look-up tables indexed by instruction address to control instruction execution in a processor |
| US6549903B1 (en) * | 1999-02-17 | 2003-04-15 | Elbrus International Limited | Integrity of tagged data |
| US6625146B1 (en) | 1999-05-28 | 2003-09-23 | Advanced Micro Devices, Inc. | Method and apparatus for operating a network switch in a CPU-less environment |
| US6549959B1 (en) | 1999-08-30 | 2003-04-15 | Ati International Srl | Detecting modification to computer memory by a DMA device |
| US6438673B1 (en) | 1999-12-30 | 2002-08-20 | Intel Corporation | Correlated address prediction |
| US7213247B1 (en) | 2000-01-10 | 2007-05-01 | Wind River Systems, Inc. | Protection domains for a computer operating system |
| US6925549B2 (en) | 2000-12-21 | 2005-08-02 | International Business Machines Corporation | Asynchronous pipeline control interface using tag values to control passing data through successive pipeline stages |
| US7062638B2 (en) | 2000-12-29 | 2006-06-13 | Intel Corporation | Prediction of issued silent store operations for allowing subsequently issued loads to bypass unexecuted silent stores and confirming the bypass upon execution of the stores |
| US6560690B2 (en) | 2000-12-29 | 2003-05-06 | Intel Corporation | System and method for employing a global bit for page sharing in a linear-addressed cache |
| GB0102515D0 (en) | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Network adapter management |
| GB0102518D0 (en) | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Trusted operating system |
| GB0102516D0 (en) | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Trusted gateway system |
| GB0109722D0 (en) | 2001-04-20 | 2001-06-13 | Koninkl Philips Electronics Nv | Extendible instruction system |
| US20030014466A1 (en) | 2001-06-29 | 2003-01-16 | Joubert Berger | System and method for management of compartments in a trusted operating system |
| US6785776B2 (en) | 2001-07-26 | 2004-08-31 | International Business Machines Corporation | DMA exclusive cache state providing a fully pipelined input/output DMA write mechanism |
| US7599369B2 (en) | 2001-09-27 | 2009-10-06 | Broadcom Corporation | Apparatus and methods for hardware payload header suppression, expansion, and verification in a DOCSIS network |
| US20030196108A1 (en) | 2002-04-12 | 2003-10-16 | Kung Kenneth C. | System and techniques to bind information objects to security labels |
| US8017816B2 (en) | 2002-04-22 | 2011-09-13 | The Curators Of The University Of Missouri | Method of producing lower alcohols from glycerol |
| US7487264B2 (en) | 2002-06-11 | 2009-02-03 | Pandya Ashish A | High performance IP processor |
| US7631107B2 (en) | 2002-06-11 | 2009-12-08 | Pandya Ashish A | Runtime adaptable protocol processor |
| US7254696B2 (en) | 2002-12-12 | 2007-08-07 | Alacritech, Inc. | Functional-level instruction-set computer architecture for processing application-layer content-service requests such as file-access requests |
| US7594111B2 (en) | 2002-12-19 | 2009-09-22 | Massachusetts Institute Of Technology | Secure execution of a computer program |
| US6976147B1 (en) | 2003-01-21 | 2005-12-13 | Advanced Micro Devices, Inc. | Stride-based prefetch mechanism using a prediction confidence value |
| US7467414B2 (en) | 2003-03-17 | 2008-12-16 | Intel Corporation | Entitlement security and control for information system entitlement |
| US7403925B2 (en) | 2003-03-17 | 2008-07-22 | Intel Corporation | Entitlement security and control |
| US6922740B2 (en) | 2003-05-21 | 2005-07-26 | Intel Corporation | Apparatus and method of memory access control for bus masters |
| US20050108518A1 (en) | 2003-06-10 | 2005-05-19 | Pandya Ashish A. | Runtime adaptable security processor |
| US7168063B2 (en) | 2003-06-10 | 2007-01-23 | Microsoft Corporation | Systems and methods for employing tagged types in a dynamic runtime environment |
| US7437718B2 (en) * | 2003-09-05 | 2008-10-14 | Microsoft Corporation | Reviewing the security of trusted software components |
| US7580914B2 (en) * | 2003-12-24 | 2009-08-25 | Intel Corporation | Method and apparatus to improve execution of a stored program |
| US7526757B2 (en) * | 2004-01-14 | 2009-04-28 | International Business Machines Corporation | Method and apparatus for maintaining performance monitoring structures in a page table for use in monitoring performance of a computer program |
| US7114036B2 (en) * | 2004-01-14 | 2006-09-26 | International Business Machines Corporation | Method and apparatus for autonomically moving cache entries to dedicated storage when false cache line sharing is detected |
| CN1558388A (zh) | 2004-01-16 | 2004-12-29 | 孙亚非 | 酒文化结合防伪技术在酒水促销中的应用方法 |
| CA2459004A1 (en) | 2004-02-20 | 2005-08-20 | Ibm Canada Limited - Ibm Canada Limitee | Method and system to control data acces using security label components |
| US7340469B1 (en) | 2004-04-16 | 2008-03-04 | George Mason Intellectual Properties, Inc. | Implementing security policies in software development tools |
| US7243193B2 (en) * | 2004-05-27 | 2007-07-10 | Silverbrook Research Pty Ltd | Storage of program code in arbitrary locations in memory |
| US7430650B1 (en) | 2004-06-17 | 2008-09-30 | Richard Ross | Generating a set of pre-fetch address candidates based on popular sets of address and data offset counters |
| US7657756B2 (en) | 2004-10-08 | 2010-02-02 | International Business Machines Corporaiton | Secure memory caching structures for data, integrity and version values |
| JP2006113689A (ja) | 2004-10-12 | 2006-04-27 | Fujitsu Ltd | バスブリッジ装置およびデータ転送方法 |
| US7688838B1 (en) | 2004-10-19 | 2010-03-30 | Broadcom Corporation | Efficient handling of work requests in a network interface device |
| US8332653B2 (en) | 2004-10-22 | 2012-12-11 | Broadcom Corporation | Secure processing environment |
| US7496735B2 (en) | 2004-11-22 | 2009-02-24 | Strandera Corporation | Method and apparatus for incremental commitment to architectural state in a microprocessor |
| US20060143689A1 (en) | 2004-12-21 | 2006-06-29 | Docomo Communications Laboratories Usa, Inc. | Information flow enforcement for RISC-style assembly code |
| US7831570B2 (en) | 2004-12-30 | 2010-11-09 | Oracle International Corporation | Mandatory access control label security |
| US8732856B2 (en) | 2004-12-30 | 2014-05-20 | Oracle International Corporation | Cross-domain security for data vault |
| US7574536B2 (en) | 2005-04-22 | 2009-08-11 | Sun Microsystems, Inc. | Routing direct memory access requests using doorbell addresses |
| US7707387B2 (en) * | 2005-06-01 | 2010-04-27 | Microsoft Corporation | Conditional execution via content addressable memory and parallel computing execution model |
| US20070006294A1 (en) | 2005-06-30 | 2007-01-04 | Hunter G K | Secure flow control for a data flow in a computer and data flow in a computer network |
| JP4519738B2 (ja) | 2005-08-26 | 2010-08-04 | 株式会社東芝 | メモリアクセス制御装置 |
| US8166404B2 (en) | 2005-10-04 | 2012-04-24 | Disney Enterprises, Inc. | System and/or method for authentication and/or authorization |
| US8516193B1 (en) | 2006-03-30 | 2013-08-20 | Pegasystems Inc. | Techniques for content-based caching in a computer system |
| US7581064B1 (en) * | 2006-04-24 | 2009-08-25 | Vmware, Inc. | Utilizing cache information to manage memory access and cache utilization |
| US7434002B1 (en) * | 2006-04-24 | 2008-10-07 | Vmware, Inc. | Utilizing cache information to manage memory access and cache utilization |
| JP4899616B2 (ja) | 2006-04-28 | 2012-03-21 | ソニー株式会社 | 変調装置および方法、プログラム、並びに記録媒体 |
| US8245199B2 (en) * | 2006-05-05 | 2012-08-14 | International Business Machines Corporation | Selectively marking and executing instrumentation code |
| US20080052488A1 (en) | 2006-05-10 | 2008-02-28 | International Business Machines Corporation | Method for a Hash Table Lookup and Processor Cache |
| US20080016547A1 (en) | 2006-07-11 | 2008-01-17 | International Business Machines Corporation | System and method for security planning with hard security constraints |
| US8301870B2 (en) * | 2006-07-27 | 2012-10-30 | International Business Machines Corporation | Method and apparatus for fast synchronization and out-of-order execution of instructions in a meta-program based computing system |
| WO2008035660A1 (fr) | 2006-09-20 | 2008-03-27 | Mitsubishi Rayon Co., Ltd. | Stratifié de résine, procédé de fabrication de celui-ci et film de transfert destiné à être utilisé dans la fabrication d'un stratifié de résine |
| US7594079B2 (en) * | 2006-09-29 | 2009-09-22 | Mips Technologies, Inc. | Data cache virtual hint way prediction, and applications thereof |
| US20080083298A1 (en) | 2006-10-10 | 2008-04-10 | Chu-Fu Lin | Counter weight flywheel |
| US8266702B2 (en) | 2006-10-31 | 2012-09-11 | Microsoft Corporation | Analyzing access control configurations |
| US7793166B2 (en) * | 2006-11-27 | 2010-09-07 | Emc Corporation | Methods and systems for recovering meta-data in a cache memory after a corruption event |
| US8132259B2 (en) | 2007-01-04 | 2012-03-06 | International Business Machines Corporation | System and method for security planning with soft security constraints |
| US8677457B2 (en) | 2007-02-09 | 2014-03-18 | Marvell World Trade Ltd. | Security for codes running in non-trusted domains in a processor core |
| US7945921B2 (en) | 2007-03-01 | 2011-05-17 | Microsoft Corporation | Cross application domain late binding to non-local types |
| US8364910B2 (en) | 2007-03-08 | 2013-01-29 | Daniel Shawcross Wilkerson | Hard object: hardware protection for software objects |
| JP5100176B2 (ja) | 2007-03-29 | 2012-12-19 | 株式会社東芝 | マルチプロセッサシステム |
| US7813342B2 (en) | 2007-03-26 | 2010-10-12 | Gadelrab Serag | Method and apparatus for writing network packets into computer memory |
| US7640420B2 (en) | 2007-04-02 | 2009-12-29 | Intel Corporation | Pre-fetch apparatus |
| GB2448149B (en) * | 2007-04-03 | 2011-05-18 | Advanced Risc Mach Ltd | Protected function calling |
| US7644044B2 (en) | 2007-04-04 | 2010-01-05 | Sony Corporation | Systems and methods to distribute content over a network |
| NO326590B1 (no) | 2007-04-16 | 2009-01-19 | Kubekit As | Fremgangsmate og anordning for verifikasjon av informasjonstilgang i IKT-system med flere sikkerhetsdimensjoner og sikkerhetsniva. |
| US8001390B2 (en) | 2007-05-09 | 2011-08-16 | Sony Computer Entertainment Inc. | Methods and apparatus for secure programming and storage of data using a multiprocessor in a trusted mode |
| US8423720B2 (en) | 2007-05-10 | 2013-04-16 | International Business Machines Corporation | Computer system, method, cache controller and computer program for caching I/O requests |
| US8561061B2 (en) * | 2007-05-14 | 2013-10-15 | Vmware, Inc. | Adaptive dynamic selection and application of multiple virtualization techniques |
| US7933889B2 (en) | 2007-05-15 | 2011-04-26 | Palo Alto Research Center Incorporated | Method and system for metadata-driven document management and access control |
| US7975109B2 (en) | 2007-05-30 | 2011-07-05 | Schooner Information Technology, Inc. | System including a fine-grained memory and a less-fine-grained memory |
| US20080301471A1 (en) | 2007-05-31 | 2008-12-04 | Marc Demarest | Systems and methods in electronic evidence management for creating and maintaining a chain of custody |
| EP2160734A4 (en) | 2007-06-18 | 2010-08-25 | Synergy Sports Technology Llc | SYSTEM AND METHOD FOR EDITING, MARKING AND INDEXING DISTRIBUTED AND PARALLEL VIDEOS |
| US7975107B2 (en) | 2007-06-22 | 2011-07-05 | Microsoft Corporation | Processor cache management with software input via an intermediary |
| US20090006519A1 (en) | 2007-06-29 | 2009-01-01 | Microsoft Corporation | Managing a computing environment |
| US7913172B2 (en) | 2007-09-01 | 2011-03-22 | International Business Machines Corporation | Fine-grained, label-based, XML access control model |
| US8131663B1 (en) | 2007-10-12 | 2012-03-06 | Bonamy Taylor | Apparatus for generating software logic rules by flowchart design |
| US7921260B2 (en) * | 2007-10-24 | 2011-04-05 | International Business Machines Corporation | Preferred write-mostly data cache replacement policies |
| US7793049B2 (en) | 2007-10-30 | 2010-09-07 | International Business Machines Corporation | Mechanism for data cache replacement based on region policies |
| US20090144388A1 (en) * | 2007-11-08 | 2009-06-04 | Rna Networks, Inc. | Network with distributed shared memory |
| US8782384B2 (en) * | 2007-12-20 | 2014-07-15 | Advanced Micro Devices, Inc. | Branch history with polymorphic indirect branch information |
| US8880483B2 (en) | 2007-12-21 | 2014-11-04 | Sandisk Technologies Inc. | System and method for implementing extensions to intelligently manage resources of a mass storage system |
| US20090178102A1 (en) | 2008-01-04 | 2009-07-09 | Khaled Alghathbar | Implementing Security Policies in Software Development Tools |
| US8306987B2 (en) | 2008-04-03 | 2012-11-06 | Ofer Ber | System and method for matching search requests and relevant data |
| GB0811422D0 (en) * | 2008-06-20 | 2008-07-30 | Symbian Software Ltd | Efficient caching |
| US8196213B2 (en) | 2008-07-11 | 2012-06-05 | Microsoft Corporation | Verification of un-trusted code for consumption on an insecure device |
| EP2148212B1 (en) | 2008-07-24 | 2019-08-21 | Toshiba Medical Systems Corporation | Magnetic resonance imaging apparatus for contrast enhancement of images |
| KR101171554B1 (ko) | 2008-07-31 | 2012-08-06 | 스미토모 덴키 고교 가부시키가이샤 | 차동 전송 케이블 및 그것을 포함하는 복합 케이블 |
| US9317708B2 (en) | 2008-08-14 | 2016-04-19 | Teleputers, Llc | Hardware trust anchors in SP-enabled processors |
| US8181005B2 (en) * | 2008-09-05 | 2012-05-15 | Advanced Micro Devices, Inc. | Hybrid branch prediction device with sparse and dense prediction caches |
| US8332909B2 (en) | 2008-12-16 | 2012-12-11 | Microsoft Corporation | Automated software restriction policy rule generation |
| DE102009058346A1 (de) | 2008-12-24 | 2010-07-22 | Johnson Electric S.A. | Universalmotor |
| US8806101B2 (en) * | 2008-12-30 | 2014-08-12 | Intel Corporation | Metaphysical address space for holding lossy metadata in hardware |
| US8190832B2 (en) * | 2009-01-29 | 2012-05-29 | International Business Machines Corporation | Data storage performance enhancement through a write activity level metric recorded in high performance block storage metadata |
| US8335754B2 (en) | 2009-03-06 | 2012-12-18 | Tagged, Inc. | Representing a document using a semantic structure |
| US8176282B2 (en) * | 2009-03-11 | 2012-05-08 | Applied Micro Circuits Corporation | Multi-domain management of a cache in a processor system |
| US20100250729A1 (en) | 2009-03-30 | 2010-09-30 | Morris Robert P | Method and System For Providing Access To Metadata Of A Network Accessible Resource |
| US8332350B2 (en) | 2009-04-08 | 2012-12-11 | Titus Inc. | Method and system for automated security access policy for a document management system |
| US8370577B2 (en) * | 2009-06-26 | 2013-02-05 | Microsoft Corporation | Metaphysically addressed cache metadata |
| US8225030B2 (en) | 2009-09-30 | 2012-07-17 | Dell Products L.P. | Systems and methods for using a page table in an information handling system comprising a semiconductor storage device |
| US8635415B2 (en) | 2009-09-30 | 2014-01-21 | Intel Corporation | Managing and implementing metadata in central processing unit using register extensions |
| JP2011095852A (ja) * | 2009-10-27 | 2011-05-12 | Toshiba Corp | キャッシュメモリ制御回路 |
| EP2507966A1 (en) | 2009-11-30 | 2012-10-10 | BAE Systems Plc. | Processing network traffic |
| US9087200B2 (en) | 2009-12-22 | 2015-07-21 | Intel Corporation | Method and apparatus to provide secure application execution |
| US8627042B2 (en) | 2009-12-30 | 2014-01-07 | International Business Machines Corporation | Data parallel function call for determining if called routine is data parallel |
| JP5387757B2 (ja) | 2010-03-05 | 2014-01-15 | 日本電気株式会社 | 並列データ処理システム、並列データ処理方法及びプログラム |
| US20110219424A1 (en) | 2010-03-05 | 2011-09-08 | Microsoft Corporation | Information protection using zones |
| US8954418B2 (en) | 2010-05-14 | 2015-02-10 | Sap Se | Performing complex operations in a database using a semantic layer |
| US8271447B1 (en) | 2010-06-18 | 2012-09-18 | Emc International Company | Mirroring metadata in a continuous data protection environment |
| US8732697B2 (en) | 2010-08-04 | 2014-05-20 | Premkumar Jonnala | System, method and apparatus for managing applications on a device |
| GB2483907A (en) * | 2010-09-24 | 2012-03-28 | Advanced Risc Mach Ltd | Privilege level switching for data processing circuitry when in a debug mode |
| US8738860B1 (en) | 2010-10-25 | 2014-05-27 | Tilera Corporation | Computing in parallel processing environments |
| US8819225B2 (en) | 2010-11-15 | 2014-08-26 | George Mason Research Foundation, Inc. | Hardware-assisted integrity monitor |
| JP5717864B2 (ja) * | 2010-11-16 | 2015-05-13 | インテル・コーポレーション | データ記憶システムに用いるエンドポイントキャッシュ |
| US20120151184A1 (en) * | 2010-12-10 | 2012-06-14 | Daniel Shawcross Wilkerson | Hard object: constraining control flow and providing lightweight kernel crossings |
| US9934166B2 (en) * | 2010-12-10 | 2018-04-03 | Daniel Shawcross Wilkerson | Hard object: constraining control flow and providing lightweight kernel crossings |
| US9218278B2 (en) * | 2010-12-13 | 2015-12-22 | SanDisk Technologies, Inc. | Auto-commit memory |
| US9047178B2 (en) * | 2010-12-13 | 2015-06-02 | SanDisk Technologies, Inc. | Auto-commit memory synchronization |
| US20120239860A1 (en) | 2010-12-17 | 2012-09-20 | Fusion-Io, Inc. | Apparatus, system, and method for persistent data management on a non-volatile storage media |
| US9792472B1 (en) | 2013-03-14 | 2017-10-17 | Impinj, Inc. | Tag-handle-based authentication of RFID readers |
| US8966182B2 (en) | 2011-02-08 | 2015-02-24 | International Business Machines Corporation | Software and hardware managed dual rule bank cache for use in a pattern matching accelerator |
| US8996807B2 (en) | 2011-02-15 | 2015-03-31 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a multi-level cache |
| US9003104B2 (en) | 2011-02-15 | 2015-04-07 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a file-level cache |
| US8875170B1 (en) | 2011-02-18 | 2014-10-28 | Isaac S. Daniel | Content roaming system and method |
| US8949270B2 (en) | 2011-03-10 | 2015-02-03 | Salesforce.Com, Inc. | Methods and systems for processing social media data |
| US20180107591A1 (en) | 2011-04-06 | 2018-04-19 | P4tents1, LLC | System, method and computer program product for fetching data between an execution of a plurality of threads |
| US10114477B2 (en) | 2011-07-14 | 2018-10-30 | Samsung Electronics Co., Ltd. | Display device and method thereof |
| US8955111B2 (en) | 2011-09-24 | 2015-02-10 | Elwha Llc | Instruction set adapted for security risk monitoring |
| US9219752B2 (en) | 2011-08-26 | 2015-12-22 | Hewlett-Packard Development Company, L.P. | Data leak prevention systems and methods |
| US9329869B2 (en) * | 2011-10-03 | 2016-05-03 | International Business Machines Corporation | Prefix computer instruction for compatibily extending instruction functionality |
| US9753858B2 (en) * | 2011-11-30 | 2017-09-05 | Advanced Micro Devices, Inc. | DRAM cache with tags and data jointly stored in physical rows |
| US20130160775A1 (en) | 2011-12-21 | 2013-06-27 | University Of Technology, Sidney | Method and apparatus for lower back pain relief |
| US10102117B2 (en) | 2012-01-12 | 2018-10-16 | Sandisk Technologies Llc | Systems and methods for cache and storage device coordination |
| US9251052B2 (en) | 2012-01-12 | 2016-02-02 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for profiling a non-volatile cache having a logical-to-physical translation layer |
| TWI453608B (zh) | 2012-02-03 | 2014-09-21 | Chunghwa Telecom Co Ltd | System and method for managing a large number of multiple data |
| US8966204B2 (en) | 2012-02-29 | 2015-02-24 | Hewlett-Packard Development Company, L.P. | Data migration between memory locations |
| US9208082B1 (en) * | 2012-03-23 | 2015-12-08 | David R. Cheriton | Hardware-supported per-process metadata tags |
| WO2013147865A1 (en) | 2012-03-30 | 2013-10-03 | Intel Corporation | A mechanism for saving and retrieving micro-architecture context |
| US9075710B2 (en) * | 2012-04-17 | 2015-07-07 | SanDisk Technologies, Inc. | Non-volatile key-value store |
| US10474584B2 (en) * | 2012-04-30 | 2019-11-12 | Hewlett Packard Enterprise Development Lp | Storing cache metadata separately from integrated circuit containing cache controller |
| US8874850B1 (en) | 2012-05-10 | 2014-10-28 | Netapp, Inc. | Hierarchically tagged cache |
| JP5832954B2 (ja) * | 2012-05-18 | 2015-12-16 | 日本電信電話株式会社 | タグ付与装置及びタグ付与方法 |
| US8898376B2 (en) * | 2012-06-04 | 2014-11-25 | Fusion-Io, Inc. | Apparatus, system, and method for grouping data stored on an array of solid-state storage elements |
| US8909879B2 (en) | 2012-06-11 | 2014-12-09 | International Business Machines Corporation | Counter-based entry invalidation for metadata previous write queue |
| US8826391B2 (en) | 2012-07-02 | 2014-09-02 | Freescale Semiconductor, Inc. | Virtualized trusted descriptors |
| US8572410B1 (en) | 2012-07-18 | 2013-10-29 | Freescale Semiconductor, Inc. | Virtualized protected storage |
| US10305937B2 (en) | 2012-08-02 | 2019-05-28 | CellSec, Inc. | Dividing a data processing device into separate security domains |
| US20140047183A1 (en) * | 2012-08-07 | 2014-02-13 | Dell Products L.P. | System and Method for Utilizing a Cache with a Virtual Machine |
| US9367480B2 (en) * | 2012-08-07 | 2016-06-14 | Dell Products L.P. | System and method for updating data in a cache |
| US9961651B2 (en) | 2012-08-17 | 2018-05-01 | Intel Corporation | Multi-channel power control |
| US20140109176A1 (en) | 2012-10-15 | 2014-04-17 | Citrix Systems, Inc. | Configuring and providing profiles that manage execution of mobile applications |
| US9098417B2 (en) | 2012-12-13 | 2015-08-04 | Advanced Micro Devices, Inc. | Partitioning caches for sub-entities in computing devices |
| US9183055B2 (en) | 2013-02-07 | 2015-11-10 | Advanced Micro Devices, Inc. | Selecting a resource from a set of resources for performing an operation |
| US9965502B2 (en) | 2013-02-27 | 2018-05-08 | Hitachi Vantara Corporation | Content class for object storage indexing system |
| US9569612B2 (en) | 2013-03-14 | 2017-02-14 | Daniel Shawcross Wilkerson | Hard object: lightweight hardware enforcement of encapsulation, unforgeability, and transactionality |
| US8959657B2 (en) | 2013-03-14 | 2015-02-17 | Appsense Limited | Secure data management |
| US9165078B2 (en) | 2013-03-14 | 2015-10-20 | International Business Machines Corporation | Row-based data filtering at a database level |
| US9298911B2 (en) * | 2013-03-15 | 2016-03-29 | Intel Corporation | Method, apparatus, system, and computer readable medium for providing apparatus security |
| US9037811B2 (en) | 2013-03-15 | 2015-05-19 | International Business Machines Corporation | Tagging in memory control unit (MCU) |
| KR101501462B1 (ko) | 2013-06-10 | 2015-03-11 | 이용재 | 통합 데이터 객체 관리 시스템 및 그 방법 |
| US9734080B2 (en) * | 2013-08-08 | 2017-08-15 | Nxp Usa, Inc. | Cache organization and method |
| CN105981027A (zh) | 2013-08-12 | 2016-09-28 | 哥莱菲特软件公司 | 安全认证并切换至加密域 |
| US10185584B2 (en) * | 2013-08-20 | 2019-01-22 | Teleputers, Llc | System and method for self-protecting data |
| US9680738B2 (en) | 2013-09-15 | 2017-06-13 | Nicira, Inc. | Tracking prefixes of values associated with different rules to generate flows |
| US9244827B2 (en) | 2013-09-25 | 2016-01-26 | Intel Corporation | Store address prediction for memory disambiguation in a processing device |
| CN105579955A (zh) | 2013-09-27 | 2016-05-11 | 慧与发展有限责任合伙企业 | 应用控制流模型 |
| GB201318723D0 (en) | 2013-10-23 | 2013-12-04 | Avecto Ltd | Computer device and method for isolating untrusted content |
| US9507589B2 (en) | 2013-11-07 | 2016-11-29 | Red Hat, Inc. | Search based content inventory comparison |
| GB2518022B (en) | 2014-01-17 | 2015-09-23 | Imagination Tech Ltd | Stack saved variable value prediction |
| US9411747B2 (en) * | 2014-02-04 | 2016-08-09 | Freescale Semiconductor, Inc. | Dynamic subroutine stack protection |
| US10320676B2 (en) | 2014-02-28 | 2019-06-11 | Cisco Technology, Inc. | Smarter policy decisions based on metadata in data flows |
| US9323684B2 (en) | 2014-03-21 | 2016-04-26 | Intel Corporation | Dynamic cache and memory allocation for memory subsystems |
| US9245123B1 (en) | 2014-05-07 | 2016-01-26 | Symantec Corporation | Systems and methods for identifying malicious files |
| JP6287571B2 (ja) | 2014-05-20 | 2018-03-07 | 富士通株式会社 | 演算処理装置、情報処理装置、及び、演算処理装置の制御方法 |
| US9489532B2 (en) | 2014-05-28 | 2016-11-08 | Siemens Product Lifecycle Management Software Inc. | Fast access rights checking of configured structure data |
| TW201600997A (zh) | 2014-06-30 | 2016-01-01 | 萬國商業機器公司 | 於一集中式管理環境中動態產生一策略實施點之封包檢視策略的方法、資訊設備及電腦程式產品 |
| US9336047B2 (en) | 2014-06-30 | 2016-05-10 | International Business Machines Corporation | Prefetching of discontiguous storage locations in anticipation of transactional execution |
| US9992298B2 (en) | 2014-08-14 | 2018-06-05 | International Business Machines Corporation | Relationship-based WAN caching for object stores |
| US9525606B1 (en) | 2014-09-04 | 2016-12-20 | HCA Holdings, Inc. | Differential processing of data streams based on protocols |
| EP2993606A1 (en) * | 2014-09-05 | 2016-03-09 | Axiomatics AB | Provisioning system-level permissions using attribute-based access control policies |
| US9483250B2 (en) | 2014-09-15 | 2016-11-01 | International Business Machines Corporation | Systems management based on semantic models and low-level runtime state |
| US9436847B2 (en) | 2014-09-26 | 2016-09-06 | Intel Corporation | Cryptographic pointer address encoding |
| US10546132B2 (en) | 2014-09-30 | 2020-01-28 | Micro Focus Llc | String property labels for static analysis |
| US9767272B2 (en) | 2014-10-20 | 2017-09-19 | Intel Corporation | Attack Protection for valid gadget control transfers |
| US10078763B2 (en) * | 2014-11-19 | 2018-09-18 | BAE Systems Information and Electronic Systems Integration Incc | Programmable unit for metadata processing |
| US9830162B2 (en) | 2014-12-15 | 2017-11-28 | Intel Corporation | Technologies for indirect branch target security |
| US9576147B1 (en) | 2015-01-05 | 2017-02-21 | Amazon Technologies, Inc. | Security policy application through data tagging |
| CN104657500A (zh) * | 2015-03-12 | 2015-05-27 | 浪潮集团有限公司 | 一种基于key-value键值对的分布式存储方法 |
| US9747218B2 (en) | 2015-03-20 | 2017-08-29 | Mill Computing, Inc. | CPU security mechanisms employing thread-specific protection domains |
| US9736185B1 (en) | 2015-04-21 | 2017-08-15 | Infoblox Inc. | DNS or network metadata policy for network control |
| US9846648B2 (en) | 2015-05-11 | 2017-12-19 | Intel Corporation | Create page locality in cache controller cache allocation |
| US10073786B2 (en) * | 2015-05-28 | 2018-09-11 | Micron Technology, Inc. | Apparatuses and methods for compute enabled cache |
| US9910611B2 (en) | 2015-05-29 | 2018-03-06 | Intel Corporation | Access control for memory protection key architecture |
| US9713216B2 (en) | 2015-06-05 | 2017-07-18 | Zyntony, Inc. | Multi-section portable electronic torch |
| US9703956B1 (en) | 2015-06-08 | 2017-07-11 | Symantec Corporation | Systems and methods for categorizing virtual-machine-aware applications for further analysis |
| US10469464B2 (en) | 2015-06-09 | 2019-11-05 | Intel Corporation | Self-configuring key management system for an internet of things network |
| US10114958B2 (en) | 2015-06-16 | 2018-10-30 | Microsoft Technology Licensing, Llc | Protected regions |
| US10642753B1 (en) | 2015-06-30 | 2020-05-05 | Fireeye, Inc. | System and method for protecting a software component running in virtual machine using a virtualization layer |
| US10073977B2 (en) | 2015-07-20 | 2018-09-11 | Intel Corporation | Technologies for integrity, anti-replay, and authenticity assurance for I/O data |
| US9892281B1 (en) | 2015-07-28 | 2018-02-13 | HCA Holdings, Inc. | Testing using deidentified production data |
| US11381566B2 (en) | 2015-08-12 | 2022-07-05 | Red Hat, Inc. | Isolating network resources in a virtualized environment |
| US10586076B2 (en) | 2015-08-24 | 2020-03-10 | Acronis International Gmbh | System and method for controlling access to OS resources |
| US20170083338A1 (en) | 2015-09-19 | 2017-03-23 | Microsoft Technology Licensing, Llc | Prefetching associated with predicated load instructions |
| US9612967B1 (en) | 2015-09-25 | 2017-04-04 | Dell Products, L.P. | Cache load balancing by reclaimable block migration |
| US9507598B1 (en) | 2015-12-15 | 2016-11-29 | International Business Machines Corporation | Auxiliary branch prediction with usefulness tracking |
| US10936713B2 (en) | 2015-12-17 | 2021-03-02 | The Charles Stark Draper Laboratory, Inc. | Techniques for metadata processing |
| US10235176B2 (en) | 2015-12-17 | 2019-03-19 | The Charles Stark Draper Laboratory, Inc. | Techniques for metadata processing |
| US10133866B1 (en) | 2015-12-30 | 2018-11-20 | Fireeye, Inc. | System and method for triggering analysis of an object for malware in response to modification of that object |
| US11709679B2 (en) | 2016-03-31 | 2023-07-25 | Qualcomm Incorporated | Providing load address predictions using address prediction tables based on load path history in processor-based systems |
| US10685111B2 (en) | 2016-10-31 | 2020-06-16 | Crowdstrike, Inc. | File-modifying malware detection |
| US10409603B2 (en) | 2016-12-30 | 2019-09-10 | Intel Corporation | Processors, methods, systems, and instructions to check and store indications of whether memory addresses are in persistent memory |
| US20180276022A1 (en) | 2017-03-24 | 2018-09-27 | Commvault Systems, Inc. | Consistent virtual machine replication |
| US10503904B1 (en) | 2017-06-29 | 2019-12-10 | Fireeye, Inc. | Ransomware detection and mitigation |
| CN108521864B (zh) | 2017-10-20 | 2021-01-05 | 深圳市大疆创新科技有限公司 | 成像控制方法、成像装置和无人机 |
| US10635810B2 (en) | 2018-01-31 | 2020-04-28 | Jungle Disk, L.L.C. | Probabilistic anti-encrypting malware protections for cloud-based file systems |
| SG11202007272QA (en) | 2018-02-02 | 2020-08-28 | Charles Stark Draper Laboratory Inc | Systems and methods for policy execution processing |
| EP3746922A1 (en) | 2018-02-02 | 2020-12-09 | Dover Microsystems, Inc. | Systems and methods for transforming instructions for metadata processing |
| WO2019152792A1 (en) | 2018-02-02 | 2019-08-08 | Dover Microsystems, Inc. | Systems and methods for policy linking and/or loading for secure initialization |
| US11307854B2 (en) | 2018-02-07 | 2022-04-19 | Intel Corporation | Memory write log storage processors, methods, systems, and instructions |
| US11417109B1 (en) | 2018-03-20 | 2022-08-16 | Amazon Technologies, Inc. | Network-based vehicle event detection system |
| US10984122B2 (en) | 2018-04-13 | 2021-04-20 | Sophos Limited | Enterprise document classification |
| US10776482B2 (en) | 2018-05-18 | 2020-09-15 | International Business Machines Corporation | Automated virtual machine integrity checks |
| US10922411B2 (en) | 2018-06-20 | 2021-02-16 | Malwarebytes Inc. | Intelligent event collection for cloud-based malware detection |
| US10970396B2 (en) | 2018-06-20 | 2021-04-06 | Malwarebytes Inc. | Intelligent event collection for rolling back an endpoint state in response to malware |
| US10424043B1 (en) * | 2018-07-02 | 2019-09-24 | Intel Corporation | Efficiently enqueuing workloads from user mode to hardware across privilege domains |
| TW202022678A (zh) | 2018-11-06 | 2020-06-16 | 美商多佛微系統公司 | 用於停滯主處理器的系統和方法 |
| US11360704B2 (en) * | 2018-12-21 | 2022-06-14 | Micron Technology, Inc. | Multiplexed signal development in a memory device |
| WO2020150351A1 (en) | 2019-01-18 | 2020-07-23 | Dover Microsystems, Inc. | Systems and methods for metadata classification |
| US11522905B2 (en) | 2019-09-11 | 2022-12-06 | International Business Machines Corporation | Malicious virtual machine detection |
| WO2021076871A1 (en) | 2019-10-18 | 2021-04-22 | Dover Microsystems, Inc. | Systems and methods for updating metadata |
| WO2021092138A1 (en) | 2019-11-06 | 2021-05-14 | Dover Microsystems, Inc. | Systems and methods for improving efficiency of metadata processing |
-
2016
- 2016-05-31 US US15/168,689 patent/US10235176B2/en active Active
- 2016-12-12 EP EP16820480.8A patent/EP3387577B1/en active Active
- 2016-12-12 EP EP16820481.6A patent/EP3387578A1/en active Pending
- 2016-12-12 JP JP2018550654A patent/JP7053486B2/ja active Active
- 2016-12-12 CN CN201680081293.8A patent/CN108885660B/zh active Active
- 2016-12-12 US US16/062,796 patent/US11507373B2/en active Active
- 2016-12-12 JP JP2018531549A patent/JP7000326B2/ja active Active
- 2016-12-12 WO PCT/US2016/066194 patent/WO2017106103A1/en active Application Filing
- 2016-12-12 SG SG11201804733YA patent/SG11201804733YA/en unknown
- 2016-12-12 KR KR1020187020288A patent/KR102572262B1/ko active IP Right Grant
- 2016-12-12 CN CN201680081309.5A patent/CN109074447A/zh active Pending
- 2016-12-12 WO PCT/US2016/066188 patent/WO2017106101A2/en active Application Filing
- 2016-12-12 KR KR1020187020285A patent/KR102610802B1/ko active IP Right Grant
- 2016-12-12 SG SG11201804696RA patent/SG11201804696RA/en unknown
-
2017
- 2017-02-07 US US15/426,098 patent/US9785440B2/en active Active
- 2017-06-16 US US15/624,878 patent/US10642616B2/en active Active
- 2017-09-05 US US15/695,541 patent/US10261794B2/en active Active
-
2018
- 2018-06-07 US US16/002,757 patent/US10754650B2/en active Active
- 2018-06-07 US US16/002,957 patent/US10545760B2/en active Active
- 2018-06-07 US US16/002,987 patent/US10521230B2/en active Active
- 2018-06-07 US US16/002,642 patent/US10725778B2/en active Active
-
2019
- 2019-01-24 US US16/256,640 patent/US11182162B2/en active Active
- 2019-11-14 US US16/684,172 patent/US11340902B2/en active Active
-
2020
- 2020-06-18 US US16/905,680 patent/US11635960B2/en active Active
- 2020-07-15 US US16/929,692 patent/US11782714B2/en active Active
-
2021
- 2021-10-26 US US17/452,271 patent/US11720361B2/en active Active
Non-Patent Citations (2)
| Title |
|---|
| Arthur Azevedo de Amorim et al., "Micro-Policies: Formally Verified, Tag-Based Security Monitors"(2015.07.)* * |
| Udit Dhawan et al., "PUMP: A Programmable Unit for Metadata Processing"(2014.06.)* * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20220068355A (ko) * | 2020-11-19 | 2022-05-26 | 주식회사 올리브텍 | 스토리지 운영체제의 커널 수준에서 파일에 지정된 열람제한시간 동안 파일 내용 읽기 및 쓰기를 원천적으로 방지하는 데이터 보호 방법 |
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102610802B1 (ko) | 메타데이터 프로세싱 기술 | |
| US10936713B2 (en) | Techniques for metadata processing | |
| KR102514351B1 (ko) | 메타데이터 처리 기술 | |
| Milenkovic | Architectures for run-time verification of code integrity | |
| Roessler | Policy Implementation and Engineering for Tagged Architectures | |
| Burow | Taking Back Control: Closing the Gap Between C/C++ and Machine Semantics | |
| Deng | Flexible and efficient accelerator architecture for runtime monitoring |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant |