Michał Cierniak : CLR

Execution Engine-independent JIT compilers

michaljc — Thu, 24 Feb 2005 03:55:00 GMT

I have recently put together a set of slides about LIL (Low-level Intermediate Language) and gave a talk at Microsoft. This work was done before I joined Microsoft: LIL was developed by the ORP (Open Runtime Platform) team at Intel. LIL was addressing multiple issues in the ORP design (papers referenced below can give you an idea) but the focus of this presentation was more narrow: how to improve the interface between the JIT (Just-In-Time compiler) and the rest of the VM. I'd like to point out that I use the terms VM (Virtual Machine) and EE (Execution Engine) interchangeably (see this post for a discussion of this terminology). Others have come up independently with somewhat similar ideas and I found quite a lot of interest in the LIL approach in conversations both inside and outside of Microsoft. For my current presentation I took some of the old LIL slides that I used in a talk I gave at ETH Zürich in 2003 and modified them to focus on the JIT/EE interface. This version of slides benefited from my conversations with many people in the last year, after the original LIL papers were published. I think that I owe most to my conversations with George Bosworth and to comments by Thorsten Brunklaus who worked on the SEAM VM (see below) and now is in the CLR team.

LIL is described at length in the VM'04 paper. The MPOOL'03 paper (pdf) presents some thoughts on how LIL could be used to abstract away the object model from the JIT. Full references to these two papers are available on my publications page.

The talk I just gave had the title "Execution Engine-independent JIT compilers" and the basic idea is that LIL enables a much better abstraction of the EE from a JIT's point of view then what is used in all known to me implementations of virtual machines for JVM and CLR/CLI. I made the full presentation available as a pdf file.

Here are references to the related work mentioned in the slides:

Bartok is a compiler developed by the Advanced Compiler Technology group at MSR
JikesRVM: http://www.ibm.com/developerworks/oss/jikesrvm
LLVM: http://llvm.cs.uiuc.edu
C--: http://www.cminusminus.org
SEAM: http://www.ps.uni-sb.de/seam (also, this discussion is an entertaining read if you want to see varied opinions on the subject)
PCR: http://portal.acm.org/citation.cfm?id=74862
Alan Kay's quote is from the ACM Queue article.

Secure CRT

michaljc — Mon, 03 Jan 2005 04:27:00 GMT

One of the cool new things we are doing in the security push is the conversion of all uses of potentially unsafe CRT (C Runtime) functions to their new, safe counterparts. When we think of unsafe CRT functions, we usually think of string manipulation functions and these functions are probably indeed responsible for most of the security bugs
(For a few examples of what can go wrong with the traditional string manipulation functions, read this post) but there are other improvements in the CRT libraries. As mentioned on MSDN the main categories of improvement in CRT are: parameter validation, sized buffers, null termination, enhanced error reporting, file system security, Windows security, and format string syntax checking.

Resources
For a great introduction to Secure CRT, read this article by Michael Howard. A list of secure CRT functions with short descriptions and links to longer articles is available in the Whidbey section of MSDN. Secure CRT is also mentioned by another blogger. A clever way of using templates to avoid typing the extra parameter when the compiler can deduce it itself is described here.

Rotor
Secure CRT functions are being discussed in the context of the ISO/IEC standard for C (in JTC1/SC22/WG14). You can read the submission and the Security TR Editor's Report online. However, since these functions have not been added to the C standard yet and we want to compile Rotor Whidbey on non-Windows platforms, we will include implementations of some of the secure CRT functions in the Rotor distribution. Our current plan is to include only as much as we need for Rotor, so this will not be a complete implementation.

CLR Security Push

michaljc — Mon, 03 Jan 2005 03:19:00 GMT

I have been recently coordinating much of the efforts on the CLR dev team related to the security push. The security push is a period of a few weeks for all groups involved in Whidbey to let us focus on making Whidbey more secure. There was recently a very good post by Mikhail Arkhipov outlining many of the efforts we are focusing on.

There are many people in the CLR team who are very experienced in security and they have all been working on guiding the effort but the involvement has not been restricted to them - most of the team was doing some work. The involvement of the whole team is what makes this effort a "push".

My work was mostly to know what issues we have to pay attention to; to know how to use new tools and new libraries or languages extensions; and to make general recommendations on some issues. I started to look into all these issues well before the push started and I was really glad that I did since during the security push I have been getting a lot of specific questions from various people and my earlier investigations meant that I either knew the answer or at least knew where to look or who to ask. As you can imagine, I also wrote a few documents for our team focusing on various issues, I set up a web page for the CLR devs with pointers to useful documents and with an FAQ section. I also gave a few presentations introducing new tools available to us. The presentations and documents written by me were mostly based on information already available from various sources. After all many people have been working on security at Microsoft for a while and there is a lot of knowledge to be mined within our company.

I will write later about some of the specific things that I have been looking at during the security push.