If you've heard about Windows Server "Longhorn" sticking system files in random addresses of the memory to reduce the amount of remote code execution attacks, and I had a slight improvisation to that idea.

Longhorn loads the whole file, exactly as it is in the memory, as an exact copy. If a hacker finds out the address, he/she will be able to place a piece of malicious code over there in the same position of the file.

I thought about that for a while, and decided that, although the chance of that happening now would be low, why not make it extremely lower?

Break up the system file into segments, and then loading them in random positions (with JMPs in between) may increase the security because one piece of code will be in the upper half of the RAM, and the next piece of code in the sequence is in the lower half, for example. It should not affect performance of the RAM, as the name stands for Random Access Memory.

So, let's say the contents of the kernel for Example OS X was disassembled and translated to FASM. The code may look something like the following:

Original Example OS X Kernel on the hard drive:

The Example OS X kernel when loaded into the RAM:

I want to know what you think about this idea. And yes. I want to know how good you think it is, any improvements you can make to it, and how bad you think it is.

Also, I would like to know the longest JMP in ASM history, so I can account for that in my code. Also tell me exactly what value you put after the JMP, and whether it was a 16-bit, 32-bit, or 64-bit instruction so I can try it out myself!

The longest JMP I have tried is 5 bytes long:

Imho not necessary, and could end up introducing too much overhead.

Address Space Randomization was added to avoid simple buffer overflow (and heap smashing, etc.) exploit code by not being able to rely on hardcoded addresses. Imho your segmentation idea (you might want to call it "sections" or "chunks" instead to avoid confusion with x86 segments) doesn't add much extra safety.

Also, keep in mind that the randomization is done at the linear level, not the physical level... doesn't make sense to add randomization to physical ram level, if code has already gained ring0 access (which is necessary for tampering with linear->physical mappings), you're already screwed.

Ikesyay! I forgot about those x86 segments!

It wouldn't affect performance of the RAM, it would affect performance of the full system and not because RAM isn't Random Access Memory, but because processor wouldn't able to use its integrated instruction cache and predecoding instructions + extra jumps that affect performance too.