14os_dependability课件.pptVIP

* This problem has been studied by other researchers, and approaches include … Later in this session we will hear about XFI, a scheme that combines static analysis and software guards like SFI to check a variety of very useful properties for extensions. XFI’s static analysis works at the binary level. In SafeDrive, we look at what we can do if we have the source code to the extension. The question is basically, what can be done at the C language level to better detect and handle bugs in extensions. * * This code declares a struct that contains a pointer, data, to an array of integers. The following code accesses members of that array. The question is, how to check the safety of memory accesses in programs like this. The C compiler doesn’t do this for us because C pointers do not express extent of buffers, unlike high-level languages like Java, where each array has a length at runtime. * However, for any approach based on fat pointers, adding the bounds changed the layout of the struct. If the struct is a global data struct exported by the host program and used by the extension, both sodes have to be changed. This makes them unsuitable for our case where we only want to change the extension. * So instead of using fat pointers, we observe that in this case, the struct actually contains the length of the buffer as another field. Actually the general observation is that bounds info are often available in other fields or variables nearby in the a lot of programs. Therefore for this example, we add an annotation count(len) that tell the compiler this relationship so that it can enforce it. Then the compiler can emit runtime checks when necessary. Then this results in no memory layout change to the data structures and API function. Thus this can be applied to one extension a time. Also note that many of the checks can be optimized away by a clever compiler. For example, the check in this example is not necessary because the loop invariant makes the condition always