Towards the Formal Specification and Verification of Maple Programs

In this paper, we present our ongoing work and initial results on the formal specification and verification of MiniMaple (a substantial subset of Maple with slight extensions) programs. The main goal of our work is to find behavioral errors in such programs w.r.t. their specifications by static analysis. This task is more complex for widely used computer algebra languages like Maple as these are fundamentally different from classical languages: they support non-standard types of objects such as symbols, unevaluated expressions and polynomials and require abstract computer algebraic concepts and objects such as rings and orderings etc. As a starting point we have defined and formalized a syntax, semantics, type system and specification language for MiniMaple

Type Checking and Inference for Dynamic Languages

Object-oriented dynamic languages such as Ruby, Python, and JavaScript provide rapid code development and a high degree of flexibility and agility to the programmer. Some of the their main features include dynamic typing and metaprogramming. In dynamic typing, programmers do not declare or cast types, and types are not known until run time. In addition, an object’s suitability is determined by its methods, as opposed to its class. Metaprogramming dynamically generates code as the program executes, which means that methods and classes can be added and modified at run-time. These features are powerful but lead to a major drawback of dynamic languages: the lack of static types means that type errors can remain latent long into the software development process or even into deployment, especially in the presence of metaprogramming. To bring the benefits of static types to dynamic languages, I present three pieces of work. First, I present the Ruby Type Checker (rtc), a tool that adds type check- ing to Ruby. Rtc addresses the issue of latent type errors by checking all types during run time at method entrance and exit. Thus it checks types later than a purely static system, but earlier than a traditional dynamic type system. Rtc is implemented as a Ruby library and supports type annotations on classes, methods, and objects. Rtc provides a rich type language that includes union and intersection types, higher-order (block) types, and parametric polymorphism, among other features. We applied rtc to several apps and found it effective at checking types. Second, I present Hummingbird, a just-in-time static type checker for dy- namic languages. Hummingbird also prevents latent type errors, and type checks Ruby code even in the presence of metaprogramming, which is not handled by rtc. In Hummingbird, method type signatures are gathered dynamically at run-time, as those methods are created. When a method is called, Hummingbird statically type checks the method body against current type signatures. Thus, Hummingbird provides thorough static checks on a per-method basis, while also allowing arbitrarily complex metaprogramming. We applied Hummingbird to six apps, including three that use Ruby on Rails, a powerful framework that relies heavily on metaprogramming. We found that all apps type check successfully using Hummingbird, and that Hummingbird’s performance overhead is reasonable. Lastly, I present a practical type inference system for Ruby. Although both rtc and Hummingbird are very effective tools for type checking, the programmer must provide the type annotations on the application methods, which may be a time-consuming and error-prone process. Type inference is a generalization of type checking that automatically infers types while performing checking. However, standard type inference often infers types that are overly permissive compared to what a programmer might write, or contain no useful information, such as the bottom type. I first present a standard type inference system for Ruby, where constraints on a method is statically gathered as soon as the method is invoked at run-time, and types are resolved after all constraints have been gathered on all methods. I then build a practical type inference system on top of the standard type inference system. The goal of my practical type inference system is to infer types that are concise and include actual classes when appropriate. Finally, I evaluate my practical type inference system on three Ruby apps and show it to be very effective compared to the standard type inference system. In sum, I believe that rtc, Hummingbird, and the practical type inference system all take strong steps forward in bringing the benefits of static typing to dynamic languages

A software approach to defeating side channels in last-level caches

We present a software approach to mitigate access-driven side-channel attacks that leverage last-level caches (LLCs) shared across cores to leak information between security domains (e.g., tenants in a cloud). Our approach dynamically manages physical memory pages shared between security domains to disable sharing of LLC lines, thus preventing "Flush-Reload" side channels via LLCs. It also manages cacheability of memory pages to thwart cross-tenant "Prime-Probe" attacks in LLCs. We have implemented our approach as a memory management subsystem called CacheBar within the Linux kernel to intervene on such side channels across container boundaries, as containers are a common method for enforcing tenant isolation in Platform-as-a-Service (PaaS) clouds. Through formal verification, principled analysis, and empirical evaluation, we show that CacheBar achieves strong security with small performance overheads for PaaS workloads

On Verifying Resource Contracts using Code Contracts

In this paper we present an approach to check resource consumption contracts using an off-the-shelf static analyzer. We propose a set of annotations to support resource usage specifications, in particular, dynamic memory consumption constraints. Since dynamic memory may be recycled by a memory manager, the consumption of this resource is not monotone. The specification language can express both memory consumption and lifetime properties in a modular fashion. We develop a proof-of-concept implementation by extending Code Contracts' specification language. To verify the correctness of these annotations we rely on the Code Contracts static verifier and a points-to analysis. We also briefly discuss possible extensions of our approach to deal with non-linear expressions.Comment: In Proceedings LAFM 2013, arXiv:1401.056