[Mono-devel-list] [PATCH] Move of Interlocked.Increment/Decrement/Exchange I4 to op codes

[Ben Maurer]

On Mon, 2004-11-29 at 19:31 +0100, Paolo Molaro wrote:
> BTW: please don't send me _three_ copies of the same mail.
> Just post to the list.
Sorry about that. Hit the wrong button twice ;-)

> On 11/29/04 Ben Maurer wrote:
> > > for some examples of the problem. The emitted code has many
> > > dependencies on the runtime internals and those need to be tracked
> > > somehow. This has nothing to do with changes to corlib, which are
> > > already handled. The offsets of course are only part of the issue,
> > > there are many other dependencies on algorithms etc.
> > 
> > Every time you make install, corlib will be built along with the
> > runtime, (even if the code was unchanged in corlib), so the aot will be
> > invalidated.
> 
> Luckily the build system is not retarded: it doesn't build anything on
> make install. You'll also note, if you try, that corlib is not rebuilt
> if, for example, mini is changed. So your assumption is wrong.
Ah, someone changed that behavior. With make bootstrap it always did
that.

> The first is best handled with the existing MONO_AOT_FILE_VERSION,
> augmented with the mono release version. 
That would work. __DATE__ and __TIME__ would give us something that
would work without the release version (ie, for developers). (actually,
I guess this is a bit messy because the file that the macros are in
might not have changed. But am sure we can hack a clever way to deal
with that. In fact, it'd be nice to do that so we could display
svnversion in --version, but thats another issue)

> Note that this data
> is built into the mono binary, so it can't never happen that
> it's accidentally changed (like a corlib version which can
> be different than the one compiled together with mono: which itself
> is fine).
You can't take the corlib from version 1.0.2 and use the runtime from
1.0.4. That would be buggy at best, and at worse could make a system
with a security hole. 

> Also, from a security standpoint, I prefer to add the info about the
> embedded offsets and other automatically checked data, because it
> reduces the chances there is a human error in increasing the aot 
> version. Your solution would be a security nightmare.

For releases, using the version that automake gets should be fine. We
absolutely know that we won't forget to increment this (otherwise
packages would be fucked up). The developers could get __DATE__ and
__TIME__ to help them.

Not to mention, executing an untrusted .so aot file is a security hole
by any means. I can go in, use objdump, change a few lines of assembly,
reassemble. I might have to change the assembly so that the data was
valid.

The abi is more than a list of fields and offsets. The meaning of a
field can be changed without changing its name. There are also many
other changes that could be made (for example, sorting instance fields
so that we avoid holes) which would not change this ABI. Rather than
relying on the developer to evaluate if old AOT files would work with
his new code, it is much safer to just clobber the AOT file with every
change.

IMHO, an AOT file is specific to:
      * The *exact* system it was generated on (processor model, number
        of processors, etc)
      * The mono runtime it was generated with
      * The dlls it was linked against

Taking the "The mono runtime it was generated with" and making it "the
abi of the runtime it was generated with" is much, much more error
prone.

-- Ben