On 11/04/2015 10:30 AM, Daniel Cashman wrote: > On 11/3/15 3:21 PM, Kees Cook wrote: >> On Tue, Nov 3, 2015 at 3:14 PM, Daniel Cashman <dcashman@xxxxxxxxxxx> wrote: >>> On 11/03/2015 11:19 AM, Kees Cook wrote: >>>> Do you have patches for x86 and arm64? >>> >>> I was holding off on those until I could gauge upstream reception. If >>> desired, I could put those together and add them as [PATCH 3/4] and >>> [PATCH 4/4]. >> >> If they're as trivial as I'm hoping, yeah, let's toss them in now. If >> not, skip 'em. PowerPC, MIPS, and s390 should be relatively simple >> too, but one or two of those have somewhat stranger calculations when >> I looked, so their Kconfigs may not be as clean. > > Creating the patches should be simple, it's the choice of minimum and > maximum values for each architecture that I'd be most concerned about. > I'll put them together, though, and the ranges can be changed following > discussion with those more knowledgeable, if needed. I also don't have > devices on which to test the PowerPC, MIPS and s390 changes, so I'll > need someone's help for that. Actually, in preparing the x86 and arm64 patches, it became apparent that the current patch-set does not address 32-bit executables running on 64-bit systems (compatibility mode), since only one procfs mmap_rnd_bits variable is created and exported. Some possible solutions: 1) Create a second set for compatibility, e.g. mmap_rnd_compat_bits, mmap_rnd_compat_bits_min, mmap_rnd_compat_bits_max and export it as with mmap_rnd_bits. This provides the most control and is truest to the spirit of this patch, but pollutes the Kconfigs and procfs a bit more, especially if we ever need a mmap_rnd_64compat_bits... 2) Get rid of the arch-independent nature of this patch and instead let each arch define its own Kconfig values and procfs entries. Essentially the same outcome as the above, but with less disruption in the common kernel code, although also with a potentially variable ABI. 3) Default to the lowest-supported, e.g. arm64 running with CONFIG_COMPAT would be limited to the same range as arm. This solution I think is highly undesirable, as it actually makes things worse for existing 64-bit platforms. 4) Support setting the COMPAT values by Kconfig, but don't expose them via procfs. This keeps the procfs change simple and gets most of its benefits. 5) Leave the COMPAT values specified in code, and only adjust introduce config and tunable options for the 64-bit processes. Basically keep this patch-set as-is and not give any benefit to compatible applications. My preference would be for either solutions 1 or 4, but would love feedback and/or other solutions. Thoughts? Thank You, Dan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>