Archive for July, 2007

Another one bites the dust

Sunday, July 29th, 2007

Seems my computer decided I’ve hacked enough on WikiBench this week. This morning I smelled something odd, and after checking my email noticed that my CPU temperature was 84C. I usually push 80C when listening to music or watching video, but when it’s been idle 50C is more normal. So I powered down and poked around.

Best guess I can come up with is that the PSU fan died as that part was the hottest. Since that fan is also the main exhaust fan I’m not surprised the CPU was so hot.

I will try to get a new PSU and a new case ASAP since the airflow on this one is terrible. Unfortunately money is a bit short right now. (I am a student, after all…) Hopefully my box will live again soon. In the meantime at least I have my laptop.

Facebook Application Smashing

Sunday, July 22nd, 2007

A friend and I are starting a new blog to expose vulnerabilities in Facebook applications. Since Facebook has a reputation of being secure, people seem to trust whatever applications will integrate with it. However, careless coding by third parties can allow all kinds of attacks, some of which can result in data theft. Hopefully this blog will bring some examples to light.

I’m running out of title ideas

Thursday, July 12th, 2007

But not motivation to code.

Since my last post, the following changes have been made to Affe:

  • The AffeCompiler class has been split into two classes. AffeCompiler stores information about the configuration (host type and symbol table) and passes copies to AffeCompilerState for actual compilation. This allows the host class information to be cached when compiling repeatedly against the same class, and for changes to the symbol table to be retained.
  • The parse tree is no longer immutable. It became apparent that to perform optimizations and other tweaks to the compiler output changing the tree is desired.
  • Added type system. Expressions are automatically cast between required types. Methods and fields on the host class can now accept and return any type.
  • Added support for string literals.
  • Moved the tree classes into their own namespace.
  • Transform methods have been improved. The AffeTransform attribute now takes a Type instead of an int. This type specifies the “return type” (actually the type of the object left on top of the stack). This allows for a primitive form of vararg methods, and the method can simply throw an exception if the count of expressions is incorrect.
  • Refactored the DefineLocals tree of calls into an AnalyzeTree tree, which not only finds locals but adds casts where required and does some other nifty optimizations.
  • All tree classes except Root now inherit from Node, which provides a property for accessing the node’s location in the input text.
  • Added better error support. Exceptions now contain the Node causing the error. Combined with the Node’s property this allows the location of the error to be displayed.
  • Added TypeSymbol, which maps an identifier to a Type.
  • Added support for method, field, and property access, both for objects (instance invocation) and types (static invocation).

Type systems can be complex. jchambers summed it up pretty well:

12:33 < SerajewelKS> whew, writing compilers is easy until you decide to add support for types besides float

12:34 <@jchambers> until then I think you just have a calculator.

Look for the next post, where hopefully I’ll have typed variable declaration and a customizable default variable type. After that there are a few fringe cases I might address such as invoking members on value types, which require special treatment in IL.

More Affe hackery

Tuesday, July 10th, 2007

Today I added:

  • Variable persistence. If a field of type ScriptState is tagged [AffeBound] on the host class, it will be used to store the state of all of the variables local to the script. If no such field is found, no state preserving IL will be emitted.
  • Bound methods can now return anything, but only methods returning float can be used in expressions. Others can be used in call statements.
  • The return keyword is now supported. In the case of a state-preserved script, it will cause a jump to the code that stores variable state.

The library is also in my public Subversion repository: svn co https://layla.chrishowie.com/svn/Cdh.Affe.

Affe evolves (Get it? It’s a pun.)

Tuesday, July 10th, 2007

Well, the plan was to have Affe be a simple language. I guess it still is, but I’ve been adding support for many C-style language features and tweaking other features over the past day. Specifically, the following:

  • Added if/else support, with the same nesting rules as C.
  • Added the following operators:
    • ! (boolean not)
    • == (equality)
    • != (inequality)
    • < (less than)
    • <= (less than or equal to)
    • > (greater than)
    • >= (greater than or equal to)
  • The tree is now scanned for variables before compilation, since with conditionals it’s no longer sufficient to initialize an unassigned variable the first time the compiler sees it. All variables local to the script are initialized to zero before the tree is compiled. This may be optimized later if the performance impact is really all that bad.
  • A call can now be used as a statement instead of just in an expression.
  • Added support for while loops, including the continue and break keywords.
  • The library is now licensed under the LGPL.

The next two planned features are:

  • A state preserving mechanism, like I discussed in my last post. I’ve been putting this off because I’m having trouble coming up with a clean way to pass the state object around.
  • Subroutine support. The subroutine would be compiled into its own dynamic method (meaning that it would not share scope with the enclosing script) and would be called from the main script.

Subroutine support brings up two interesting points. One is that variable state persistence would probably not be able to extend to them, as storing its state on the same object would not make sense considering that the scope would be different. Presumably one could chain the states together using the subroutine names, but I’m not sure that persistence would really be needed in the case of nested subroutines anyway.

The other point is about the lifetime of a DynamicMethod. These objects are eligible for garbage collection, which is kind of their point. But if I call one DynamicMethod from another, and then discard the reference, could the GC destroy the method while the method that calls it is still alive? (And do Mono and MS.NET agree what should happen?) This is an important question to answer right now, because it would be pointless to implement this if the GC will ruin it.

(Actually if the GC would destroy the method, it could be worked around by maintaining a mapping between weak references to caller methods and strong references to the callee methods. The callee method would be discarded when its caller weak reference is collected.)

Okay, enough rambling.

Affe

Sunday, July 8th, 2007

Introducing my new CLI language, Affe. While not exactly flexible, the language will be useful to me.

Since the goal was to have an expression-evaluating language that targets DynamicMethod instead of Assembly, it’s not used the same way most other languages are. It cannot be used to define subroutines or manipulate objects. In fact the only supported variable type is float.

Methods and variables are provided by a class that the embedder provides. Attributes are used to control which members are exposed to Affe.

A picture is worth a thousand words, so here is an example of how it could be used:

public class AffeTest {
	private delegate void AffeCall(AffeTest t);

	[AffeBound]
	public float X = 0;

	[AffeBound]
	public static readonly float Y = 10;

	[AffeBound]
	public static float abs(float a) {
		if (a < 0)
			return -a;

		return a;
	}

	public static void Run() {
		DynamicMethod dm = new AffeCompiler().Compile(
			typeof(AffeTest), "X = abs((5 - Y) * 3);");

		AffeTest obj = new AffeTest();

		// Invoke with reflection -- slow.
		dm.Invoke(null, new object[] { obj });
		Console.WriteLine(obj.X);

		obj.X = 0;

		// Invoke with a delegate -- very fast.
		AffeCall d = (AffeCall)
			Delegate.CreateDelegate(typeof(AffeCall), dm);

		d(obj);

		Console.WriteLine(obj.X);
	}
}

While not much, this serves to illustrate most of Affe’s features. A class is created and various fields and methods are bound (note that Affe correctly handles static fields and methods), a script is compiled against the class, and run against an instance of the class.

Note that any field whose type is not float and any method whose return type and all parameter types are not float will be ignored. There is one special exception to this case. A method tagged [AffeTransform(n)] is a sort of “virtual” method taking n parameters. It will be called with two parameters, an AffeCompiler and an Expression[]. The method can then use the compiler object to emit IL. Therefore these are compile-time methods and can be used to make up for the otherwise limited language features without requiring method calls during run-time.

In case I forgot anything, here is a feature list:

  • Implicit variable declaration. (Variables used prior to assignment are set to 0.)
  • Binding of variables and calls to class members.
  • Compile-time transform methods.
  • Operators +, -, /, *, |, &, and %.

The next feature on the list to add is variable state persistence. In other words, the ability for the values in local variables to persist from call to call, possibly by way of a state object passed by the caller. Of course values in bound fields will persist, but this will allow all variables to persist without prior knowledge of their existence.

Mono and compilers

Saturday, July 7th, 2007

Just two quick notes.

I implemented a missing feature in Mono and two people were offering a bounty for it. Who knew that hacking Mono as a hobby would help pay my car insurance? :)

Over the past week or so I’ve been reading the Red Dragon Book with the specific goal of writing a language targeting the CLI, specifically the DynamicMethod gap. We have tons of languages but none give you the ability to compile a block of code to a DynamicMethod without some horrible and inefficient hack. The language will be very limited and will solve a specific problem for me, but of course I will be releasing it in case anyone else finds it useful.

It will not support OO or strings at all, or at least nothing of the sort is planned. It will be primarily a math expression evaluator. The type that the DynamicMethod is declared on will have all of its methods and fields that are tagged with a certain attribute exposed to the code. I may hack something up for the case where variables used in the code block need to persist between invocations.

Should be fun, and if it turns out that I find something better at least I’ll be able to say that I wrote a compiler.