Architecture overview

Raksha follows the general model of previous hardware DIFT systems [14, 20, 81]. All storage locations, including registers, caches, and main memory, are extended by tag bits. All ISA instructions are extended to propagate tags from input to output operands, and check tags in addition to their regular operation. Since tag operations happen transparently, Raksha can run all types of unmodified binaries without introducing runtime overheads.

Raksha, however, differs from previous work by supporting the features discussed ear- lier, in Section 3.1. First, it supports multiple active security policies. Specifically, each

word is associated with a 4-bit tag, where each bit supports an independent security policy with separate rules for propagation and checks. As indicated by the popularity of ECC codes, 4 extra bits per 32-bit word is an acceptable overhead for additional reliability. Fig- ure 3.1 shows the logical view of the system at the ISA level, where every register and memory location appears to be extended with a 4-bit tag. Note that the actual implementa- tion of the tag bits is dependent on the underlying hardware.

The tag storage overhead can be reduced significantly using multi-granular approaches that exploit the common case where all words in a cache line or in a memory page are associated with the same tag [81]. The choice of four tag bits per word was motivated by the number of security policies used to protect against a diverse set of attacks with the Raksha prototype (see Chapter 4). Even if future experiments show that a different number of active policies are needed, the basic mechanisms described in this section will apply.

The second difference is that Raksha’s security policies are highly flexible and software- programmable. Software uses a set of policy configuration registers to describe the propa- gation and check rules for each tag bit. The specification format allows fine-grained control over the rules. Specifically, software can independently control the tag rules for each class of instructions and configure how tags from multiple input operands are combined. More- over, Raksha allows software to specify custom rules for a small number of individual instructions. This enables handling of corner cases within an instruction class. For ex- ample, xor r1,r1,r1 is a commonly used idiom to reset registers, especially on x86 machines. To avoid false positives while detecting memory corruption attacks, we must recognize this case and suppress tag propagation from the inputs to the output. Section 3.2.2 discusses how complex corner cases can be addressed using custom rules.

The third difference is that Raksha supports user-level handling of security exceptions. Hence, the exception overhead is similar to that of a function call rather than the overhead of a full OS trap. Two hardware mechanisms are necessary to support user-level exceptions handling. First, the processor has an additional trusted mode that is orthogonal to the

!"# $%&' () $%&' *+,-. $%&' /"!) $%&' !"# 01234' 5677777777777587597777777775:75;7777777775<7557777777775=75>7777777777777777777=67=87777777777=97=:777777777=;7=<777777777=57==7777777777=>7?77777777777777678777777777777797:77777777777777;7<777777777777757=777777777777777>

/@AB%$7"C'D2BE%17!"#$%&' !%F'7"C'D2BE%17!"#$%&'( )*+& 01G%&E1H I>J77K%@DG'7)D%C2H2BE%1701234'7L"1M"NNO I>J77K%@DG'7)D%C2H2BE%1701234'7L"1M"NNO >>7P Q%7)D%C2H2BE%1 I=J77K%@DG'7*&&D'AA7)D%C2H2BE%1701234'7L"1M"NNO I=J77K%@DG'7*&&D'AA7)D%C2H2BE%1701234'7L"1M"NNO >=7P *QR7A%@DG'7%C'D21&7B2HA

I5J77R'ABE12BE%17*&&D'AA7)D%C2H2BE%1701234'7L"1M"NNO =>7P "+7A%@DG'7%C'D21&7B2HA ==7P S"+7A%@DG'7%C'D21&7B2HA !,#-.%&(./*.#0#12*"(/3%&'(4*/(.*2"1&/(1#2"12"0(#"#%5'2'6

T%HEG7U72DEBV$'BEG7%C'D2BE%1AW R'AB7B2H7X A%@DG'=7B2H7"+7A%@DG'57B2H !%F'7%C'D2BE%1AW R'AB7B2H7X7A%@DG'7B2H "BV'D7%C'D2BE%1AW Q%7)D%C2H2BE%1 -)+7'1G%&E1HW7>>7>>7>>7>>7>>=7>>7>>7>>7>>7=>7>>7=>7>>7=> T"Y $%&' /ZK-7> $%&' /ZK-7< $%&' /ZK-75 $%&' /ZK-7= $%&' /ZK-7> 01234' /ZK-7< 01234' /ZK-75 01234' /ZK-7= 01234' -2H7)D%C2H2BE%17+'HEAB'D )D'&'NE1'&7"C'D2BE%17!"#$%&' 0['G@B'7"C'D2BE%17!"#$%&' I>J77K%@DG'7/V'G\701234'7L"1M"NNO I>J77)/7/V'G\701234'7L"1M"NNO I=J77R'ABE12BE%17/V'G\701234'7L"1M"NNO I=J77,1ABD@GBE%17/V'G\701234'7L"1M"NNO /@AB%$7"C'D2BE%17!"#$%&' !%F'7"C'D2BE%170"#$%&' I>J77K%@DG'7=7/V'G\701234'7L"1M"NNO I>J77K%@DG'7/V'G\701234'7L"1M"NNO I=J77K%@DG'757/V'G\701234'7L"1M"NNO I=J77K%@DG'7*&&D'AA7/V'G\701234'7L"1M"NNO I5J77R'ABE12BE%17/V'G\701234'7L"1M"NNO I5J77R'ABE12BE%17*&&D'AA7/V'G\701234'7L"1M"NNO I<J77R'ABE12BE%17/V'G\701234'7L"1M"NNO !,#-.%&(78&79(/3%&'(4*/(.*2"1&/(1#2"12"0(#"#%5'2'6 0['G@B'7%C'D2BE%1A7L)/OW7 "1 /%$C2DEA%17%C'D2BE%1A7LK%@DG'A7%14]OW7 "1 !%F'7%C'D2BE%1A7LK%@DG'7U7R'AB72&&D'AA'AOW "1 /@AB%$7%C'D2BE%17>W7 "17LN%D7*QR7E1ABD@GBE%1^7A%@DG'A7%14]O "BV'D7%C'D2BE%1AW7 "NN -/+7'1G%&E1HW7>>>7>>>7>>>7>==7>>7>=7>>7>>7>==>7>= 0S0/ () *+,-. /"!) !"# T"Y /ZK-7> /ZK-7< /ZK-75 /ZK-7= -2H7/V'G\7+'HEAB'D7 5:777777777777777777775<755777777777777777775>7=?77777777777777777777=87=97777777777777777777=;7=<777777777=57==7777777777=>7?77777777777776787777777777777977:777777777777777777777777777777757=777777777777777>

Figure 3.2: The format of the Tag Propagation Register. There are 4 TPRs, one per active security policy.

conventional user and kernel mode privilege levels. Software can directly access the tags or the policy configuration registers only when trusted mode is enabled. Tag propagation and checks are also disabled when in trusted mode. Second, a hardware register provides the address for a predefined security handler to be invoked on a tag exception. When a tag exception is raised, the processor automatically switches to the trusted mode but remains in the same user/kernel mode and the same address space. There is no need for an additional mechanism to protect the security handler’s code and data from malicious code. Raksha protects the handler using one of the four active security policies. Its code and data are tagged and a rule is specified that generates an exception if they are accessed outside of the trusted mode.