Recently there was some discussion about ways to ease the tired backs of kernel maintainers. Apparently the merge windows are times of great labor, and some folks wanted to alert contributors to some preferable code submission habits.

There were a variety of ideas, and Kevin Cernekee summarized them in patch form, but one key idea was that none of this advice really could be treated as etched into stone. Linus Torvalds and Theodore Ts'o, in particular, pointed out that maintainers all have their own ways of doing things, and that no general rules could be relied on universally to produce repeatable results.

In general though, as Kevin posted, the merge window is not a great time to submit new patches. The merge window is the time after a new kernel version comes out and before the first -rc release. Developers either should avoid submitting patches at that time, or as was also discussed, they at least should not expect a reply to their patches, and they should avoid submitting any patch a second time during that period, if the first one seems to go unaccepted.

Kevin also posted a very rough calculation of when developers might expect to see their code in an official kernel. If they submit code within the first four -rc releases, they could expect to see their code in the next official kernel release. If they submit code within the remaining four -rc releases, they could expect to see it in the second following official release. Alan Cox thought this calculation very valuable, though Linus cautioned that it was really quite a rough estimate and highly dependent on any given maintainer's particular patch acceptance habits.

Richard Weinberger has suggested a security improvement aimed at attackers who target forking servers, such as httpd and sshd. Apparently by creating lots of forks, the attacker could make guesses about code locations in each forked memory allocation. After enough tries, it potentially could find the location of key code and launch a root shell in the parent process. That would be bad.

Richard's idea was to identify if a child process dies due to a fatal error and cause future forks to wait 30 seconds before executing. This would cause the attack to take much more time, but would tend not to inconvenience regular users.

There was some support for this idea and some opposition. Pavel Machek came to believe that Richard's patch was only trying to slow the kernel down in random ways, in the hope that it might help. But Kees Cook and Andy Lutomirski both felt that Richard's patch was highly targeted and would not unduly delay user code.

Richard had gotten his original idea while exploring the intricacies of the offset2lib weakness, which detailed a way for attacking code to identify the location of user libraries in memory. Once this location is known, there are relatively trivial ways to launch a root shell. Any technique by which an attacker could gain knowledge of the location of code in memory, therefore, must be considered a security hole and be fixed immediately. But, it's not always clear exactly how best to prevent that information from being seen.

The Arm and Arm64 projects are experiencing a kind of growing pain—some incompatibilities between the /proc/cpuinfo files on both architectures that are causing some user programs to lose portability.

Part of the problem is that the Arm64 developers need to incorporate all APIs from Arm into their code if they want to maintain portability, although they really want to abandon those APIs in favor of better ones. In the current case, the /proc/cpuinfo files will have to be brought in line with each other, even if there's code out there that depends on their differences.

Russell King had a bit to say about the situation, in the form of a cautionary tale:

As ARM64 wants to be compatible with ARM32 (in that it wants to be able to run ARM32 applications), ARM64 has to offer a compatible user API for everything that is a user API.

That means you have to generate an ARM32 compatible /proc/cpuinfo, ARM32 compatible hwcap information, ARM32 compatible signal structures, ARM32 compatible everything else. Which means you basically need to have a copy of the ARM32 core code in ARM64, even if you want a different native ARM64 user API.

This is exactly the reason why architectures like X86 decided it was silly having separated 32- and 64-bit, and why they went through a process of merging the two together. A lot of the code was identical, and a lot of the 32-bit-specific code was needed for 64-bit to provide the 32-bit API.

Right now, you're finding out this the hard way, and hitting these API problems in the process, and going "oh fsck" when you hit them—quite simply because you've backed yourselves into a corner over this. You have established a different ARM64 API because you didn't want the ARM32 legacy, but then you've found that you do need the ARM32 legacy. Now you're in the position of having to change the ARM64 API, possibly breaking ARM64 applications in the process.