128-Bit Addressing in RISC-V and Security
Tue1530-128bit-Addr-RISC-V-Wallach-Micron
Tue1530-128bit-Addr-RISC-V-Wallach-Micron
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>128</strong>-<strong>Bit</strong> <strong>Address<strong>in</strong>g</strong> <strong>in</strong> <strong>RISC</strong>-V<br />
<strong>and</strong> <strong>Security</strong><br />
Steve Wallach<br />
swallach@micron.com
PresentaCon<br />
• Background/FoundaConal<br />
NoCons<br />
– From the 1970’s to today<br />
• Exascale Issues<br />
• Proposal (Strawman)<br />
• ProtecCon structures for<br />
current address spaces<br />
• References<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
2
Background<br />
• S<strong>in</strong>ce the late 70’s, ma<strong>in</strong>stream<br />
processors have <strong>in</strong>creased the<br />
size of the virtual space by simply<br />
add<strong>in</strong>g more bits<br />
– DEC PDP/11 & VAX: 16è 32<br />
– Data General Eclipse/MV: 16 è 32<br />
– SPARC & HP <strong>RISC</strong>: 32 è 64<br />
– Intel x86; 16è 32 è 64 (48 used)<br />
• Itanium 64<br />
– IBM Power: 32 è 64<br />
– ARM: 32 è 64<br />
• Memory management <strong>and</strong><br />
protecCon are <strong>in</strong>term<strong>in</strong>gled<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
3
Background<br />
• Other’s (pioneer’s) did not simply<br />
add more bits<br />
– IBM – FS (Ref: [13]) – 1976<br />
• Tagged 16 byte po<strong>in</strong>ters<br />
(CapabiliCes)<br />
• System/38 is the dim<strong>in</strong>uCve of FS<br />
– Data General - FHP (Ref: [3, 4,17]) -<br />
1980<br />
• Ref:<br />
hgp://people.cs.clemson.edu/<br />
~mark/ip.html<br />
– true object orientaCon with onelevel<br />
address<strong>in</strong>g across a network<br />
(<strong>128</strong> bit po<strong>in</strong>ters!)<br />
– Intel 432 iMAX OS – (Ref: [16]) – 1980<br />
• 24 bit passive address<br />
• 80 bit UID (16 bit checksum)<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
4
What Happened<br />
• MulCcs at MIT<br />
– UNIX is the dim<strong>in</strong>uCve of<br />
MulCcs<br />
• Project Genie at UC<br />
Berkeley<br />
• Influenced Industry<br />
– Graduates<br />
– A new era of compuCng<br />
– Technology was not ready<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
5
ARCHITECTURE OBJECTIVES<br />
• Programm<strong>in</strong>g generality is the ability<br />
to move a program between<br />
computer <strong>in</strong>stallaCons; the ability to<br />
ma<strong>in</strong>ta<strong>in</strong> a program with<strong>in</strong> chang<strong>in</strong>g<br />
hardware; the ability to use a<br />
program <strong>in</strong> the construcCon of<br />
another - without alter<strong>in</strong>g the<br />
program descripCon <strong>in</strong> any way.<br />
[9] Dennis, J., “PROGRAMMING GENERALITY , PARALLELISM <strong>and</strong> COMPUTER<br />
ARCHITECTURE”, MAC-M-409, MEMO NO. 32 , MIT.<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
6
Go<strong>in</strong>g Forward<br />
• There Time is to only def<strong>in</strong>e one mistake a <strong>128</strong> that bit can space be made without <strong>in</strong> computer the design need that for is <strong>128</strong> difficult address to<br />
recover arithmeCc from—not hav<strong>in</strong>g enough address bits for memory address<strong>in</strong>g <strong>and</strong><br />
memory management.” Bell <strong>and</strong> Strecker, ISCA-3, 1976.<br />
– What is “i” <strong>in</strong> A[i]?<br />
– A Virtual Address greater than 64 bits<br />
(v2.1, page 105)<br />
• Time to correct <strong>and</strong> <strong>in</strong>corporate appropriate security <strong>and</strong> access<br />
mechanisms<br />
– Network Wide <strong>Security</strong> Model<br />
• Now each node has its own security model (client/server/network/server)<br />
– Access to the web is assumed <strong>and</strong> required<br />
• Private Cloud<br />
<strong>RISC</strong> V ISA SPEC ( page 105 – v2.1)<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
7
<strong>Security</strong> & Facts<br />
• Computer Virtual Address’s (VA) span to local disk only<br />
– Disk Access is now Global (In pracCce)<br />
– Remember a VA references DISK explicitly NOT ma<strong>in</strong> memory (CS101)<br />
• Network <strong>Address<strong>in</strong>g</strong> (IPv4 & IPv6 span the enCre network)<br />
– IPv6 created a <strong>128</strong> bit network address space. Unique names<br />
• MAC <strong>and</strong> URL’s addresses are unique<br />
• EMAIL addresses are unique<br />
• Phone numbers are global; country code, city code, local code<br />
• Two different (web <strong>and</strong> local) address structures<br />
– Two different protecCon <strong>and</strong> address<strong>in</strong>g systems<br />
– Two different authenCcaCon systems<br />
• Soxware needed to bridge these two doma<strong>in</strong>s (too much soxware)<br />
• What if one unified name structure could be developed?<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
8
ProtecCon ObjecCves<br />
• The orig<strong>in</strong>al moCvaCon for puyng<br />
protecCon mechanisms <strong>in</strong>to<br />
computer systems was to keep one<br />
user’s (program) malice or error from<br />
harm<strong>in</strong>g other users (program). Harm<br />
can be <strong>in</strong>flicted <strong>in</strong> several ways:<br />
– a) By destroy<strong>in</strong>g or modify<strong>in</strong>g another<br />
user’s (program) data.<br />
– b) By read<strong>in</strong>g or copy<strong>in</strong>g another user’s<br />
(program) data without permission.<br />
– c) By degrad<strong>in</strong>g the service another user<br />
(program) gets, for example, us<strong>in</strong>g up all<br />
the disk space or geyng more than a fair<br />
share of the process<strong>in</strong>g Cme<br />
[1] Lampson, ProtecCon. Proc. 5th Pr<strong>in</strong>ceton Conf. on Informa2on<br />
Sciences <strong>and</strong> Systems, Pr<strong>in</strong>ceton, 1971<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP 9
Some FoundaConal Basis<br />
• One should recognize that concentraCon on<br />
protecCon <strong>and</strong> authenCcaCon mechanisms<br />
provides a narrow view of <strong>in</strong>formaCon<br />
security ,<strong>and</strong> that a narrow view is<br />
dangerous .The objecRve of a secure system<br />
is to prevent all unauthorized use of<br />
<strong>in</strong>formaRon, a negaRve k<strong>in</strong>d of<br />
requirement.<br />
• Every access to every object must be<br />
checked for authority. This pr<strong>in</strong>ciple, when<br />
systemaCcally applied, is the primary<br />
underp<strong>in</strong>n<strong>in</strong>g of the protecCon system<br />
• Validity/AuthenRcity is a REQUIREMENT<br />
(Ref D. Clark, personal communicaRons)<br />
[2] Schroder & Saltzer, “The protecCon of <strong>in</strong>formaCon <strong>in</strong> computer systems”,<br />
PROCEEDINGS OF THE IEEE, VOL. 63, NO. 9, SEPTEMBER 1975<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
10
Previous Efforts<br />
• Another soluCon is to address each segment with<br />
a unique <strong>in</strong>teger which is assigned at the Cme the<br />
segment is created, never changed, <strong>and</strong> not<br />
reused even axer the segment has disappeared<br />
from the system. Call this the unique <strong>in</strong>teger<br />
soluCon. ([3,4,5] & [13]Rad<strong>in</strong>’s H – H<strong>and</strong>le)<br />
[3] US Patent, 4,525,780, “DATA PROCESSING SYSTEM HAVING A<br />
MEMORY USING OBJECT- BASED INFORMATION AND A<br />
PROTECTION SCHEME …” , 1985<br />
[4] US Patent, 4,821,184,” UNIVERSAL ADDRESSING SYSTEM FOR A<br />
DIGITAL DATA PROCESSING SYSTEM”, 1989<br />
[5] Fabry, “ Capability-Based <strong>Address<strong>in</strong>g</strong>”, CACM, July<br />
1974<br />
[13] Rad<strong>in</strong>, Schneider, “An Architecture for an Extended<br />
Mach<strong>in</strong>e With Protected <strong>Address<strong>in</strong>g</strong>”, Rad<strong>in</strong>, Schneider,<br />
TR 00.2757, IBM May 21, 1976<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP 11
OPAL<br />
•<br />
S<strong>in</strong>gle Address Space for all<br />
applicaCons<br />
•<br />
Persistent Po<strong>in</strong>ters<br />
•<br />
“A full 64-bit address space will last<br />
for 500 years if allocated at the rate<br />
of one gigabyte per second. We<br />
believe that 64 bits is enough "for<br />
all Cme" on a s<strong>in</strong>gle computer,<br />
enough for a long Cme on a small<br />
network, <strong>and</strong> not enough for very<br />
long at all on the global network.”<br />
[14] J. Chase, H. Levy, et. al, “Shar<strong>in</strong>g <strong>and</strong> protecRon <strong>in</strong> a s<strong>in</strong>gle address space operaRng system” “<br />
Journal ACM TransacCons on Computer Systems (TOCS) - Special issue on computer architecture, Volume<br />
12 Issue 4, Nov. 1994, Pages 271-307<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
12
Strawman – RV<strong>128</strong>I<br />
OBJECT ID<br />
Byte Offset<br />
64 64<br />
• <strong>128</strong> <strong>Bit</strong>s<br />
• Object ID – Unique IdenCfier<br />
– a soxware (or hardware) structure that is considered to be worthy of a disCnct name.<br />
• Index<strong>in</strong>g is 64 bits – A[i]<br />
– Program Counter<br />
– Stack Po<strong>in</strong>ter (CI format - Loads <strong>and</strong> Stores)<br />
• ISA <strong>in</strong>dependent<br />
– Like rouCng IP packets (Vendor Independent)<br />
• Persistent across Cme <strong>and</strong> space<br />
• ProtecCon <strong>and</strong> memory management are <strong>in</strong>dependent<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
13
Why?<br />
• We need beger security<br />
• We need computer virtual<br />
address<strong>in</strong>g to reflect the<br />
contemporary uses<br />
– Network Wide<br />
• We do NOT want <strong>128</strong> bit flat<br />
address<strong>in</strong>g<br />
• We need po<strong>in</strong>ter <strong>in</strong>teroperability<br />
between computer systems<br />
(maybe)<br />
• We need a simplified shar<strong>in</strong>g<br />
mechanism<br />
• We need a authenCcaCon,<br />
revocaCon <strong>and</strong> protecCon aga<strong>in</strong><br />
malware/virus’s<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
14
What is a Object ?<br />
• A Object is a unique 64 bit number.<br />
• An Object can specify<br />
– LocaCon <strong>and</strong> protecCon mechanisms<br />
– Language Specific/Architecture agributes<br />
• E.G., PGAS NODE<br />
• Data Encrypted<br />
• Blockcha<strong>in</strong><br />
• The creaCon of a Object is via a central name<br />
server.<br />
– Just like: IPv6, MAC addresses, ICANN<br />
• Central NAME server Involvement<br />
– Just like a DNS server<br />
– Just like Apple’s iCloud<br />
– Only manages Object’s, NOT DATA/<br />
APPLICATIONS<br />
• Should an Object be a IPv6 address<br />
– Use bit 63 of offset to select; IPv6 or Object<br />
UID?<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
15
Access Control/Doma<strong>in</strong>s<br />
• Def<strong>in</strong>es a sphere of protecCon <strong>and</strong> use<br />
• Non-Hierarchical<br />
• Permission bits def<strong>in</strong>e what is<br />
permiged<br />
– LOCAL (Rd, Wr, Ex)<br />
– Global Network (Rd, Wr, Ex)<br />
– Extended privileged<br />
– Classical Privileged<br />
– System Calls<br />
• Explicit<br />
• Mediated<br />
– Shadow Stack<br />
• Doma<strong>in</strong> Cross<strong>in</strong>g <strong>and</strong> Return<br />
– Protected Stack (HW ma<strong>in</strong>ta<strong>in</strong>ed)<br />
– Gate Entry<br />
– Mediated Number of Gates<br />
– Stack Switch<strong>in</strong>g<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
16
AuthenCcaCon<br />
• The address space is unique over Cme <strong>and</strong> space. Any computer<br />
supporCng this address space is addressable by the name server.<br />
• Access<strong>in</strong>g an object for the first Cme requires<br />
– Permission to access (i.e., download A.OUT or .EXE file, entry with<strong>in</strong> an ACL)<br />
– Access privileges for the object<br />
• Local <strong>and</strong> Network read/write/execute<br />
• Access only thru a protected sub-object<br />
• ExecuCon Doma<strong>in</strong><br />
• Doma<strong>in</strong> of execuCon<br />
– Level of user (e.g., gold, plaCnum, execuCve plaCnum)<br />
– Adm<strong>in</strong> (Level 1, 2, or n)<br />
• In essence we have a global access control list<br />
– We have that today, but don’t realize it<br />
– It is distributed (e.g., ADOBE ma<strong>in</strong>ta<strong>in</strong>s it 2D slice of the matrix)<br />
– Each Vendor has their own access control list<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
17
Example us<strong>in</strong>g An ApplicaCon<br />
Steve Wallach – OBJECT<br />
Adobe PDF Reader - OBJECT<br />
• Can Execute <strong>in</strong> My Doma<strong>in</strong><br />
– Can read <strong>and</strong> write my file system<br />
• Can execute <strong>in</strong> different doma<strong>in</strong><br />
– Determ<strong>in</strong>e level of trust<br />
– Can read my data, but not write<br />
– Can’t send data back to ADOBE (network permissions)<br />
• Adobe FLASH - NO ACCESS<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
18
Memory Management<br />
• Each object can have its OWN<br />
memory management structure<br />
– Page Tables<br />
– Hashed Indices<br />
– PGAS like<br />
• There is NO ACCESS bits<br />
associated with the management<br />
of storage (e.g., read, write,<br />
execute, etc..)<br />
– Management is separate from<br />
protecRon<br />
• Each object can choose to have<br />
object size for constra<strong>in</strong>t access<br />
check<strong>in</strong>g (bounds check).<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
19
64 BIT LINUX<br />
Mach<strong>in</strong>e State Model<br />
File Object<br />
Proc_ID (pid_t)<br />
Process Address<br />
Space Object<br />
System Wide<br />
Resources<br />
Process<br />
CommunicaCons<br />
Process Specific (task_struct)<br />
-Unique for each process<br />
-Hashed Proc_ID<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
Kernel Ma<strong>in</strong>ta<strong>in</strong>ed<br />
.Page frame Cache<br />
.Disk Cache<br />
.Directory Cache<br />
.Lower level of<br />
Network Stack<br />
20
64 BIT LINUX<br />
-Memory Management<br />
Proc_ID<br />
32 BITS<br />
VIRTUAL ADDRESS (VA)<br />
64 BITS<br />
Hash<br />
BASE<br />
Page Table Base<br />
F(VA)<br />
LINUX NAME SPACE<br />
Page Base<br />
CAT<br />
Page<br />
Offset<br />
Process Object<br />
Address Space<br />
Page Table per Proc_ID<br />
TLB ASSOCIATES ON A 96 BIT NAME SPACE<br />
.implementaCon dependent<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
Physical<br />
Byte Address<br />
21
<strong>128</strong>-BIT VIRTUAL ADDRESSING<br />
-Memory Management<br />
OBJECT ID<br />
64 64<br />
BYTE OFFSET<br />
BASE<br />
HASH<br />
F(ID)<br />
CAT<br />
Address Space<br />
Object<br />
TLB ASSOCIATES ON A <strong>128</strong> BIT NAME SPACE<br />
.implementaCon dependent<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
PAGE BASE<br />
Control<br />
Local Page Table<br />
PGAS Local Node<br />
Object Length<br />
Lookup (hash/trees)<br />
CommunicaCons<br />
Physical<br />
Byte Address<br />
22
Exascale Issues<br />
• Subject to cost <strong>and</strong> power<br />
criCcal apps desire<br />
– One byte per peak flop (DOE<br />
ASC)<br />
– As much as you can<br />
• 2^64_bit words desirable<br />
(global access)<br />
• Memcached ConfiguraCons<br />
[7]<br />
– FronCng LARGE Disk Farms<br />
• Big Data <strong>and</strong> Compute.<br />
• BTW: An ExaByte requires 60<br />
bits of address<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP 23
Exascale Programm<strong>in</strong>g Model<br />
The mach<strong>in</strong>e that is simplest to program WINS. User cycles are more<br />
Important that cpu cycles<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
24
<strong>128</strong>- BIT VIRTUAL ADDRESSING<br />
-ProtecCon/Data Reference<br />
OBJECT ID<br />
64<br />
BYTE OFFSET<br />
64<br />
Current Doma<strong>in</strong><br />
Pr<strong>in</strong>cipal<br />
FUNCT<br />
Access Control Lists<br />
ProtecCon Agributes<br />
-Read/Write/Execute<br />
-System Calls<br />
-External References<br />
-Protected Sub-Objects<br />
Cache Last # of Entries<br />
Validate Reference before Data Reference<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
25
ProtecCon - ACL (matrix) – uses OBJECT names<br />
-ma<strong>in</strong>ta<strong>in</strong>ed by Name Server-<br />
Target Name | Object<br />
Permissions<br />
Object Length<br />
PSO Po<strong>in</strong>ter<br />
Source Name | Object (Pr<strong>in</strong>cipal)<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
Note: Doma<strong>in</strong> <strong>and</strong> Process<br />
Are NOT unique<br />
26
ACL (Access Control List) - ENTRY<br />
PERMISSIONS (Local <strong>and</strong> Global)<br />
OBJECT LENGTH - BYTES<br />
PROTECED SUB-OBJECT (PSO) POINTER<br />
64<br />
Pr<strong>in</strong>cipal UID is appended to the PSO po<strong>in</strong>ter, essenCal which virtual mach<strong>in</strong>e to use<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
27
PROTECTION -ACL Entry<br />
• PSO – Protected Sub-Object<br />
(S<strong>and</strong>box – [11])<br />
– Virtual Mach<strong>in</strong>e<br />
– Requires soxware<br />
<strong>in</strong>terpretaCon<br />
• Address of S<strong>and</strong>box<br />
– Mediated access<br />
– Part of Object creaCon<br />
• The meta data of the object<br />
– … the concept of conf<strong>in</strong><strong>in</strong>g a<br />
helper applicaCon to a<br />
restricted environment, with<strong>in</strong><br />
which it has free reign<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
28
REFERENCE MONITOR<br />
• It must validate<br />
enforcement of the security<br />
policy for every reference to<br />
<strong>in</strong>formaCon.<br />
• Second, it must be tamperproof,<br />
that is, it cannot be<br />
subverted.<br />
• Lastly, it must be verifiable,<br />
so we have high assurance<br />
it always works correctly.<br />
[18]Roger Schell,” Privacy <strong>and</strong> <strong>Security</strong> Cyber Defense Triad for Where <strong>Security</strong><br />
Magers “ NOVEMBER 2016 | VOL. 59 | NO. 11 | CACM<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP 29
Summary<br />
• Deal with Virtual Address (<strong>and</strong><br />
physical address) ranges from<br />
2020 <strong>and</strong> beyond<br />
• Incorporate Contemporary<br />
ProtecCon Mechanisms that<br />
funcCon <strong>in</strong>:<br />
– Web <strong>and</strong> Cloud based<br />
configuraCons<br />
– The objecCve of a secure<br />
system is to prevent all<br />
unauthorized use of<br />
<strong>in</strong>formaCon, a negaCve k<strong>in</strong>d of<br />
requirement.<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
30
Summary<br />
• Compare to CHERI [12]<br />
– Capability System<br />
• Good summary of s<strong>in</strong>gle address space OperaCng Systems: J. Case,<br />
H. Levy, “ Shar<strong>in</strong>g <strong>and</strong> ProtecCon <strong>in</strong> a S<strong>in</strong>gle-Address-Space<br />
OperaCng System” [14]<br />
• Should Internet address<strong>in</strong>g be by a UID <strong>and</strong> NOT IP address.<br />
– Facilitate protecCon <strong>and</strong> authenCcaCon (Ref: [ 15])<br />
• Named Data Network Proposal<br />
• What next??<br />
– Proposal<br />
• Build a prototype with FPGA’s/Simulate<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
31
References<br />
• [1] Lampson, ProtecCon. Proc. 5th Pr<strong>in</strong>ceton Conf. on Informa2on Sciences <strong>and</strong> Systems,<br />
Pr<strong>in</strong>ceton, 1971<br />
• [2] Schroder & Saltzer, “The protecCon of <strong>in</strong>formaCon <strong>in</strong> computer systems”, PROCEEDINGS<br />
OF THE IEEE, VOL. 63, NO. 9, SEPTEMBER 1975<br />
• [3]US Patent, 4,525,780 ,“DATA PROCESSING SYSTEM HAVING A MEMORY USING OBJECT-<br />
BASED INFORMATION AND A PROTECTION SCHEME FOR DETERMINING ACCESS RIGHTS TO<br />
SUCH INFORMATION”<br />
• [4]US Patent, 4,821,184,” UNIVERSAL ADDRESSING SYSTEM FOR A<br />
DIGITAL DATA PROCESSING SYSTEM”<br />
• [5] Fabry, “ Capability-Based <strong>Address<strong>in</strong>g</strong>”, CommunicaCons of the ACM, July 1974, Volume<br />
17, Number 7<br />
• [6] hgp://en.wikipedia.org/wiki/Doma<strong>in</strong>_Name_System<br />
• [7] hgp://en.wikipedia.org/wiki/Memcached<br />
• [8] hgp://en.wikipedia.org/wiki/Heap_feng_shui<br />
• [9] Dennis, J., “PROGRAMMING GENERALITY , PARALLELISM <strong>and</strong> COMPUTER<br />
ARCHITECTURE”, MAC-M-409, MEMO NO. 32 , MIT.<br />
• hgp://csg.csail.mit.edu/CSGArchives/memos/Memo-32.pdf<br />
• [10] hgp://code.google.com/p/google-safe-brows<strong>in</strong>g/wiki/SafeBrows<strong>in</strong>gDesign<br />
• [11] Ian Goldberg, David Wagner, R<strong>and</strong>i Thomas, <strong>and</strong> Eric Brewer (1996).<br />
"A Secure Environment for Untrusted Helper ApplicaCons (Conf<strong>in</strong><strong>in</strong>g the Wily Hacker)".<br />
Proceed<strong>in</strong>gs of the Sixth USENIX UNIX <strong>Security</strong> Symposium.<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
32
References<br />
• [12] Robert N.M. Watson, Peter G. Neumann Jonathan Woodruff, Jonathan Anderson, Ross<br />
Anderson, Nirav Dave, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Philip Paeps,<br />
Michael Roe, <strong>and</strong> Hassen Saidi.<br />
CHERI: a research plaorm deconflaCng hardware virtualizaCon <strong>and</strong> protecCon. Workshop<br />
paper, RunCme Environments, Systems, Layer<strong>in</strong>g <strong>and</strong> Virtualized Environments (RESoLVE<br />
2012), March, 2012.<br />
• [13] Rad<strong>in</strong>, Schneider, “An Architecture for an Extended Mach<strong>in</strong>e With Protected<br />
<strong>Address<strong>in</strong>g</strong>”, TR 00.2757, IBM May 21, 1976.<br />
• [14] J. Chase, H. Levy, et. al, “Shar<strong>in</strong>g <strong>and</strong> protecRon <strong>in</strong> a s<strong>in</strong>gle address space operaRng<br />
system” “ Journal ACM TransacCons on Computer Systems (TOCS) - Special issue on<br />
computer architecture, Volume 12 Issue 4, Nov. 1994, Pages 271-307<br />
• [15]Zhang, Estr<strong>in</strong>, et. al, “Named Data Network<strong>in</strong>g (NDN) Project, NDN -0001, October, 31,<br />
2010.<br />
• [16]F. Pollack, et. al., “ The iMAX-432 object fil<strong>in</strong>g system” Proceed<strong>in</strong>g SOSP '81 Proceed<strong>in</strong>gs<br />
of the eighth ACM symposium on OperaCng systems pr<strong>in</strong>ciples Pages 137-147<br />
• [17] hlp://people.cs.clemson.edu/~mark/op.html<br />
• [18]Roger Schell,” Privacy <strong>and</strong> <strong>Security</strong> Cyber Defense Triad for Where <strong>Security</strong> Magers “<br />
NOVEMBER 2016 | VOL. 59 | NO. 11 | CACM<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
33
BACKUP SLIDES<br />
• The follow<strong>in</strong>g slides discuss<br />
– RevocaCons<br />
– Shadow Stack<br />
– ETC<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
34
RevocaCon<br />
• Every client has a “KILL<br />
SWITCH”<br />
• The central name server is<br />
accessed <strong>and</strong> each object has<br />
a kill capability (only <strong>in</strong>iCated<br />
by the owner)<br />
• What if the unified name<br />
server is NEVER accessed<br />
aga<strong>in</strong>??<br />
– Watch Dog Timer?<br />
• Compare to a capability based<br />
system ( [5] Fabry & [12] Watson,<br />
et. al, CHERI)<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
35
S<strong>and</strong>box ParCculars<br />
• Sys Calls Mediated to Def<strong>in</strong>ed Doma<strong>in</strong> Server<br />
– (Framework of [11])<br />
• Dispatch Table With<strong>in</strong> Doma<strong>in</strong> Server traversed<br />
to to decide allow or deny the call.<br />
– If denied – Kill<br />
• Trusted Apps can bypass the framework<br />
– Part of ACL entry<br />
• If no sys calls <strong>and</strong> only reads/writes to permiged<br />
data<br />
– Timer resoluCon or other means<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
36
Some Object UID Math<br />
• 60 seconds <strong>in</strong> a m<strong>in</strong>ute<br />
• 60 m<strong>in</strong>utes <strong>in</strong> a hour<br />
• 24 hour <strong>in</strong> a day<br />
• 365 days <strong>in</strong> a year<br />
• Yields 31,536 000 seconds<br />
<strong>in</strong> a year<br />
• 30 years of life è<br />
946,080,000 or 2^30<br />
• 2^34 clients (16 billion)<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
37
What if processors like this w<strong>in</strong>?<br />
(A number of vendors like this model)<br />
hgp://www.wired.com/2014/08/datacenter-of-the-future/<br />
hgp://www.wired.com/2013/05/google-jason-mars/<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP<br />
Courtesy of Steve Poole<br />
38
ProtecCon <strong>in</strong> Unified Name Space<br />
• ACL – access control matrix<br />
• ProtecCon Doma<strong>in</strong>s<br />
• RevocaCon<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP 39
Shadow Stack<br />
• Independent, somewhat of<br />
address proposal<br />
• Solves classical virus/malware<br />
agacks<br />
– Heap Overflow<br />
• Change return address<br />
– WriCng over Stack<br />
– Heap Fung Hui Agacks [8]<br />
• Hardware protected SP, AP, FP<br />
– Ak<strong>in</strong> to doma<strong>in</strong> cross<strong>in</strong>g<br />
– Return via shadow stack<br />
2016 _NOV _<strong>RISC</strong>V_WORKSHOP 40
Shadow Stack - Architecture<br />
Return Block<br />
Return Block<br />
FP<br />
AP<br />
FP<br />
AP<br />
Stack Po<strong>in</strong>ter<br />
Stack Po<strong>in</strong>ter<br />
Shadow Stack (Hardware Ma<strong>in</strong>ta<strong>in</strong>ed)<br />
User Visible Stack<br />
Different Doma<strong>in</strong>, Same virtual address Can not write/read Shadow Stack<br />
Return via THIS STACK 2016 _NOV _<strong>RISC</strong>V_WORKSHOP 41