If my understanding of the Windows Portable Executable specification is correct, relocation tables are only needed when libraries cannot be loaded at their prefered addresses. Why do some applications (e.g. chrome.exe) contain a relocation table? Are applications not always loaded at their preferred addresses?
It's for ASLR
AFAIK, current system loader don't relocate .exe files, maybe because it will increase loading time.
However, in next versions of OS, loader will relocate EXEs. (When hardware will be fast enough)
Related
I know that they are two different things, but what is the difference between the actual Linux kernel and the rootFS file system especially in terms of location in memory and updates?
Regarding partitioning, why is it that the kernel and rootFS are nearly always on different partitions? Won't the kernel code be stored within the rootFS itself? So how are they on different partitions in memory?
Now regarding updating, I've been looking into an OTA update framework which claims to do a full kernel image update. It uses two separate partitions for rootFS. If there is a problem updating one rootFS partition, it can fall back to the working rootFS partition which makes sense. However, how is this actually updating the kernel tho? I don't understand.
I know that they are two different things, but what is the difference between the actual Linux kernel and the rootFS file system especially in terms of location in memory and updates?
Kernel is usually one image file (like zImage). In ARM systems kernel also needs device tree file, but let's avoid it for now. RootFS, in turn, is a file system that contains all files in your /, like binaries (init, bash), config files (/etc), user home directory, and so on. Sometimes RootFs contains kernel image file, sometimes it doesn't, depends on your particular system.
Regarding partitioning, why is it that the kernel and rootFS are nearly always on different partitions? Won't the kernel code be stored within the rootFS itself? So how are they on different partitions in memory?
The key to your questions is to think about bootloader (like U-Boot or GRUB). Once you understand how OS boot process works in bootloader, the answer will automatically reveal itself. As you mentioned, different partitioning schemes exist, which leads to difference in boot process. Actually, there is a lot of different boot schemes out there. Let's review some of them, and hopefully it'll explain what you want to know.
Kernel and rootfs on different partitions. In this case, bootloader usually reads kernel image to RAM, passing rootfs partition via kernel cmdline (via root= parameter). Then bootloader starts kernel execution, and kernel is mounting rootfs from partition specified in root= parameter.
Kernel image is located inside rootfs. In this case, bootloader ought to know where exactly kernel image is located (e.g. in /boot/zImage). Bootloader knows rootfs FS format (e.g. ext4), reads /boot/zImage from rootfs to RAM. Then execution continues as in previous item.
Kernel image and rootfs are passed via network (e.g. TFTP). In such case, sometimes, rootfs is being placed into RAM and mounted as ramdisk (from RAM). No persistent storage is used in such case, and any changes to rootfs will be lost after reboot. Another network case is when rootfs is mounted via NFS, then persistent storage on the server will be used (transparently viewed by the user).
Now regarding updating, I've been looking into an OTA update framework which claims to do a full kernel image update. It uses two separate partitions for rootFS. If there is a problem updating one rootFS partition, it can fall back to the working rootFS partition which makes sense. However, how is this actually updating the kernel tho? I don't understand.
In terms of updates, it's not that different which scheme to use,
(1) or (2). What are you talking about is called (at least in Android) A/B Seamless Updates, meaning that two partitions (A and B) are used for storing the same image (e.g. old rootfs and new rootfs). You need to understand that it's ok to update just rootfs without kernel. There is a rule in kernel development that reads like this: "We don't break userspace". Which means you can rely on different versions of kernel to run the same userspace, or you can rely on one kernel version to run different userspaces.
So it's more like architecture question: do you want to update kernel in your system at all? If yes, then you need to provide two different partitions for kernel and two partitions for rootfs. Or alternatively you can put kernel image and rootfs in the same partition (for example see Android boot image format), and provide second partition for updates.
Under what conditions can native code compiled for different architectures cooperate on the same operating system? When exactly is such mixing desirable?
Can, say 32 bit code run within a predominantly 64 bit process or do processes have to be pure?
I've been working on a Linux building and packaging system. My build targets are distinguished by an architecture (e.g., x86_64-gnu_linux ) and a variant (release, debug, something else) and for the packaging part, I've been operating under the simplifying assumption that no package can mixes architectures or depends on code built for a different target.
What exactly am I losing with this simplification?
Is it ever desirable to have a mixed architecture package assuming you have all the source code and it can compile for the native target?
In Linux, without using any hacks, a 32-bit shared library cannot be loaded in a 64-bit process. Conversely, a 64-bit library cannot be loaded in a 32-bit process. In other words, processes are pure; they are either 32-bit or 64-bit. Although it's technically possible to design a Linux OS that supports hybrid processes, but I don't think there are any such Linux distros.
When there is a need to interoperate 32-bit and 64-bit binaries, they should be run in different processes and then they can interoperate through some inter-process communication (IPC) mechanism.
So if you think it's possible it have multiple main executable files in the same package, then it is possible (although not common) to have binaries of different bit widths that are designed to interact through IPC in the same package. But even in such cases, there might be a single main executable (either 32-bit or 64-bit) that constitutes the starting point of the whole application. That executable would be responsible for launching other 32-bit or 64-bit processes. A package that contains all of these executables can be described solely by the architecture of that main executable, disregarding the target architectures of any other executables in the package. Doing something like that is reasonable.
I have aslr enabled and when I play some game called assault cube the base address of this program is always the same (00400000) I get it by doing GetModuleHandle(NULL) also tried to get it with windbg and it also says 00400000 and I was wondering how come it never changes since for the other programs it always changes?
Even if you have ASLR enabled globally, Windows only applies it to applications that specifically indicate that they support it. Doing otherwise could easily make legacy applications crash unexpectedly, leading to compatibility problems. All executables and supporting DLLs must explicitly indicate that they support ASLR.
Indicating that you support ASLR is something you do when linking the object file by specifying the /DYNAMICBASE option (at least if you're using Microsoft's linker). Modern versions of the linker have it turned on by default, but if your game was compiled with an older version of the toolset before dynamic address relocation support was the default (e.g., VS 2008 and earlier) or with a linker from a different vendor, it is likely that it was not linked with ASLR support.
This is called out in the relevant MSDN article (emphasis added):
ASLR moves executable images into random locations when a system boots, making it harder for exploit code to operate predictably. For a component to support ASLR, all components that it loads must also support ASLR. For example, if A.exe consumes B.dll and C.dll, all three must support ASLR. By default, Windows Vista and later will randomize system DLLs and EXEs, but DLLs and EXEs created by ISVs must opt in to support ASLR using the /DYNAMICBASE linker option.
See also: Vista ASLR is not on by default for image base addresses
Note that you can modify the PE header of an existing binary, forcing it to support ASLR, by running the editbin utility available with the SDK. As with the linker, the /dynamicbase switch will turn it on.
Or, you can force ASLR globally by editing the following registry entry:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages
Of course, neither of these actually change the code, so if there are compatibility problems, the application will break.
Since I have started to learn Golang since yesterday :) I have a question about the compiled file.
Let's assume that I compile my project. It generates an .exec file in /bin folder.
Now my question is Since the file has been compiled on Mac with Intel based CPU, should it be compiled on other OS and other CPU architectures such as AMD, ARM, etc. if I want to publish it to public?
I guess this should not be problem if I'm using GO lang for my backend since I run it on a server. However, what happens if I publish my .exec file, let's say on AWS, with lots of instances that they are automatically increases/decreases based on load? Does it problem?
Edit:
This is nice solution for those how are looking Go cross compiling tool https://github.com/mitchellh/gox
The answer to the first question is yes. The current implementations of Go produce a native binary, so you will probably need a different one for Linux x86 (32-bit), Linux x64 (64-bit), and Linux ARM. You will probably need a different one for Mac OS X also. You should be able to run the 32-bit executable on a 64-bit system as long as any libraries you depend on are available in 32-bit form on that system, so you might be able to skip making a 64-bit executable.
In the future, there may be other implementations of Go that compile for a virtual machine (such as JVM or .NET), in which case you wouldn't need to compile multiple versions for different architectures. Your question is more about existing Go implementations than the language itself.
I don't know anything about AWS, but I suggest you ask that as a separate question.
I am using the u-boot-2011.12 on my OMAP3 target, the cross tool chain is CodeSourcery arm-none-linux-gnueabi, I compiled u-boot, downloaded it onto the target and booted it, everything went fine,but I have some questions about the u-boot relocation feature, we know that this feature is base on PIC(position independent code), position independent code is generated by setting the -fpic flag to gcc, but I don't find fpic in the compile flags. Without the PIC, how can u-boot implement the relocation feature?
Remember when u-boot is running there is no OS yet. It doesn't really need the 'pic' feature used in most user applications. What I'll describe below is for the PowerPC architecture.
u-boot is initially running in NV memory (NAND or NOR). After u-boot initializes most of the peripherals (specially the RAM) it locates the top of the RAM, reserves some area for the global data, then copies itself to RAM. u-boot will then branch to the code in RAM and modify the fixups. u-boot is now relocated in RAM.
Look at the start.S file for your architecture and find the relocate_code() function. Then study, study, study...
I found this troubling too, and banged my head around this question for a few hours.
Luckily I stumbled upon the following thread on the u-boot mailing list :
http://lists.denx.de/pipermail/u-boot/2010-October/078297.html
What this says, is that at least on ARM, using -fPIC/-fPIE at COMPILE TIME is not necessary to generate position independent binaries. It eases the task of the runtime loader by doing as most work up-front as possible, but that's all.
Whether you use fPIC or not, you can always use -pic / -pie at LINK TIME, which will move all position-dependent references to a relocation section. Since no processing was performed at COMPILE TIME to add helpers, expect this section to be larger than when using -fPIC.
They conclude that for their purposes using -fPIC does not have any significant advantage over a link-time only solution.
[edit] See commit u-boot 92d5ecba for reference
arm: implement ELF relocations
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=92d5ecba47feb9961c3b7525e947866c5f0d2de5