Archive for May, 2008

Iron Man

I’ve always liked Iron Man. Tony Stark has a simple comic book story: a smart guy, who doesn’t think very much about what he’s doing, is nearly killed. The experience changes him–but not all that much. He’s a superhero because he’s addicted to action, because he feels the need to justify his survival, and because he needs the armor to keep himself alive. He doesn’t have any special powers–he’s just very inventive.

Tony Stark’s alcoholism wasn’t introduced until the character had been around for a long time. Stan Lee created Iron Man in 1963 (script by his brother, Larry Leiber, and art by Don Heck and Jack Kirby). The alcoholism was introduced in the 1980s by David Michelinie and Bob Layton. However, even though it came so much later, it fit the character so well that it has never been forgotten. Denny O’Neill later picked it up for a long run on the character in which Stark loses everything and his friend Rhodey takes over as Iron Man.

Iron Man is a natural hero for an engineer: a smart, intuitive guy who succeeds entirely on his own wits. He’s also, of course, handsome, suave, ultra wealthy, self confident–in fact, overly confident. I don’t think anybody could really identify with Tony Stark, which probably hurts his sales. But he’s a believable character at the core, more believable than many superheroes.

I didn’t have high hopes for the movie which just came out, but I’m happy to say that it captures the character very well and was also a very good movie. They changed the details of the comic book story, but kept all the essential elements. In fact, it’s early days yet, but right now I think it was one of the best superhero movies that’s been made, right up there with the first Tim Burton Batman movie. Unusually, the ordinary life sequences were better than the action sequences–something which only works because Iron Man is such a plausible character at the core. That said, the special effects were excellent, and really conveyed the power of the armored suit.

If you’re a comic book fan, sit through all the credits until the very end, to see the short setup for the sequel (if you’re not a comic book fan, though, the setup probably won’t make any sense).


Linker relro

gcc, the GNU linker, and the glibc dynamic linker cooperate to implement an idea called read-only relocations, or relro. This permits the linker to designate a part of an executable or (more commonly) a shared library as being read-only after dynamic relocations have been applied.

This may be used for read-only global variables which are initialized to something which requires a relocation, such as the address of a function or a different global variable. Because the global variable requires a runtime initialization in the form of a dynamic relocation, it can not be placed in a read-only segment. However, because it is declared to be constant, and therefore may not be changed by the program, the dynamic linker can mark it as read-only after the dynamic relocation has been applied.

For some targets this technique may also be used for the PLT or parts of the GOT.

Making these pages read-only helps catch some cases of memory corruption, and making the PLT in particular read-only helps prevent some types of buffer overflow exploits.

The first step is in gcc. When gcc sees a variable which is constant but requires a dynamic relocation, it puts it into a section named (this functionality unfortunately relies on magic section names). A variable which requires a dynamic relocation against a local symbol is put into a section; this helps group such variables together, so that the dynamic linker may apply the relocations, which will always be RELATIVE relocations, more efficiently, especially when using combreloc.

The linker groups and sections as usual. The new step is that the linker then emits a PT_GNU_RELRO program segment which covers these sections. If the PLT and/or GOT can be read-only after dynamic relocations, they are put next to the sections and also become part of the new segment. This segment will enclosed within a PT_LOAD segment. The p_vaddr field of the PT_GNU_RELRO segment gives the virtual address of the start of the read-only after dynamic relocations code, and the p_memsz field gives its length.

When the dynamic linker sees a PT_GNU_RELRO segment, it uses mprotect to mark the pages as read-only after the dynamic relocations have been applied. Of course this only works if the segment does in fact cover an entire page. The linker will try to force this to happen.

Note that the current dynamic linker code will only work correctly if the PT_GNU_RELRO segment starts on a page boundary. This is because the dynamic linker rounds the p_vaddr field down to the previous page boundary. If there is anything on the page which should not be read-only, the program is likely to fail at runtime. So in effect the linker must only emit a PT_GNU_RELRO segment if it ensures that it starts on a page boundary.

I see this as a relatively minor security benefit. It is not an optimization as far as I can see. I am documenting it here as part of my general documentation of obscure linker features. The current description of this feature in the GNU linker manual is rather obscure.

Comments (2)

Rent Control

My home city, Cambridge, Massachusetts, used to have rent control. It was generally supported in the city, but it was voted out in a statewide referendum in 1994.

The statewide referendum was a bit of a crock; only three cities in the state had any form of rent control (Cambridge, Boston, and Brookline). Rent control, like historical preservation, is something which local communities should be able to decide for themselves. I don’t think it was appropriate for it to be removed by referendum.

In my opinion, the general effect of removing rent control in Cambridge was negative. Over a period of several years rents increased steadily. Many long-time residents were forced to leave the city. The city became less diverse. Harvard Square turned into an outdoor shopping mall. From my perspective as a long-time city resident, these were not changes that I wanted to happen.

The arguments against rent control are that it is unfair to landlors, and it discourages them from investing in the building. As far as I can see these arguments do not apply to rent control in a steady state. They only applies to discussions about creating rent control for the first time or about removing it. Unexpectedly removing rent control amounts to a windfall for landlords. This doesn’t mean it can’t be done, but it does mean that arguments about fairness and investment don’t apply.

Rent control can introduce some perverse incentives. If rent control is written such that the rent can only increase when people move, people have a strong incentive to stay. A fair rent control law has to maintain similar rents for similar apartments across the area. Then people will be willing to move, at least within the area.

In some cases it may be appropriate to have an income component to rent control, so that lower income people can rent apartments. In order to make this fair to the landlord, the difference in rent needs to be supplied by the city out of property tax revenue. If the renter’s income increase, the rent should also increase up to a point. However, the rent should increase more slowly than the renter’s income after taxes, to avoid a perverse incentive to keep income low.

Used wisely, rent control can encourage a more diverse community, and that should be a choice open to the people living in that community.

I’m not going to argue that the Cambridge rent control system was used wisely. It was not too bad overall, but in my view the rent control advocates were arrogant and refused to consider even legitimate concerns of the landlords. Had they been willing to discuss issues more openly and fairly, the statewide referendum effort would probably not have been launched in the first place.

The city I live in now, Berkeley, California, still has rent control. However, I don’t know too much about the details. I do know that the eviction policy seems unfair to landlords. It is apparently very difficult to evict renters, taking many months or even years. Eviction control is required due to an unfortunate state law, which permits rents to be adjusted when a tenant leaves. This gives landlords an incentive to push tenants out frequently in order to raise rents. As noted above, it also gives tenants a perverse incentive to stay longer than they otherwise would. However, the effect of the current eviction control rules seems to be that tenants are permitted to stay for many months even if they fail to pay their rent. This seems unfair. However, as I said, I’m not familiar with the details as I was in Cambridge.

Comments (10)

GCC in C++

It is time to start using C++ in gcc. gcc was originally written in C. C++ has now advanced to the point where we can reasonably take advantage of the new features that it provides. The most obvious advantage would be in data structures. gcc implements data structures which are awkward to use for different types. With C++ they could become much simpler. The target structure is naturally implemented as a base class, which would simplify target code. The double-wide integer values could be naturally represented as a small class with operators, again simplifying the code and making it easier to understand.

This would be an easy transition, as the code is already almost completely written in the shared subset of C and C++. One of the arguments against converting to C++ is that the code would be less efficient, but it’s not as though the C code would become less efficient because we were compiling with a C++ compiler. Certainly we would have to pay close attention to efficiency with new changes, but that is no different from what we do today.

The other argument against C++ is that the language has too many complicated features. I think that gcc’s review system will ensure that new code is at least as readable as the old code. In any case programmers these days learn C++ in school. It is not so complex that gcc developers can not understand it.

The only real technical difficulty I see is that we would have to make bootstrapping work with the right libstdc++. I’m sure this is possible. We would also have to explicitly make sure that new versions of gcc can be compiled with old versions of gcc. This would be an addition to the release testing.

In the past Richard Stallman has objected to using C++ for gcc. I don’t know who he feels about it today. However, I believe that this sort of decision should be made by the actual developers.

If anybody has a principled argument against using C++ for gcc, I would very much like to hear it.

Comments (13)

Linker combreloc

The GNU linker has a -z combreloc option, which is enabled by default (it can be turned off via -z nocombreloc). I just implemented this in gold as well. This option directs the linker to sort the dynamic relocations. The sorting is done in order to optimize the dynamic linker.

The dynamic linker in glibc uses a one element cache when processing relocs: if a relocation refers to the same symbol as the previous relocation, then the dynamic linker reuses the value rather than looking up the symbol again. Thus the dynamic linker gets the best results if the dynamic relocations are sorted so that all dynamic relocations for a given dynamic symbol are adjacent.

Other than that, the linker sorts together all relative relocations, which don’t have symbols. Two relative relocations, or two relocations against the same symbol, are sorted by the address in the output file. This tends to optimize paging and caching when there are two references from the same page.

This may seem like a micro-optimization, but it can have a real effect on program startup time, especially if the program has lots of shared libraries. I’ve seen a case where a program starts up 16% faster because the relocations were sorted.


« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »