I think you need to initialize anon_loc to 0 in _vm_map_init() for this to work as intended?

Even then, when curr_min_addr == 0, the amount of randomization applied to the initial anon mapping is quite small. For PIEs, libraries are loaded after the (random) base load address, but otherwise, the set of possible initial addresses is quite small.

I fixed several more bugs with anon_loc, e.g. copying it on fork. Also I added explicit setting of anon_loc on execution of the ELF binary in 'hard' mode, similar to the interpreter base address selection.

I am not sure what do you mean by the amount of randomization. Either rnd is applied or not, if it is applied, then the amount of the entropy is guaranteed to be some.

IMO it would be clearer if you rename "anon" to "coalesce".

I guess you can just write anon = update_anon instead.

I mean that if the curr_min_addr is not randomized, the amount of entropy added is quite small. In the latest version this is still a problem for non-anonymous mappings in non-PIE binaries: the starting min address is constant (vm_daddr + lim(RLIMIT_DATA)), so the load address of libc.so, for example, can be guessed without much work. I am not sure if this is really a significant problem when the executable's address is not randomized, however.

Does it make sense to update anon_loc if find_space == VMFS_NO_SPACE?

I am still not sure about this. Do you mean that the amount of entropy allowed by the aslr_pages_rnd_XXX arrays is too small ?

Indeed, it does not provide nearly as much entropy as the initial randomization of et_dyn_addr for PIEs or anon_loc. Consider that libc.so is mapped with VMFS_OPTIMAL_SPACE, so we will set

*addr += (arc4random() % 0x10) * 0x200000;

For a non-PIE on amd64 this means that libc.so will get loaded somewhere in [0x800000000, 0x800200000], so the entropy added is quite minimal. PIEs do not have this problem.

Don't we need to reset curr_min_addr here too?

The intent is to make two normal passes without coalescing. Second pass resets curr_min_addr.

Yes, this is how I want to keep it now, by disturbing the normal layout as minimal as possible for PoC. On the other hand, since PIE base, ld.elf load address, and now initial anon base are already 'hard' randomized, might be it is indeed does not make sense to keep that part of entropy low. In fact I think we will see after another exp run.

I noticed that we are coalescing mappings in pipe_map. Is there any advantage to be gained by doing this? As a downside, I think the coalescing increases page table usage, especially since most pipe_map mappings are the same size.

mm, we reset curr_min_addr only if en_aslr is set though.

Sorry for being indecisive. Thinking some more, I think "clustering" actually makes more sense than "coalescing." Coalescing is the process of bringing together multiple entities that were previously separate, but in this case, the anonymous mappings are not separate to begin with.

"When creating an anonymous mapping, try clustering with an existing anonymous mapping first."

The text is a bit misleading since coalesce == false doesn't imply that coalescing failed. How about:

"We make up to two attempts to find address space for a given find_space value. The first attempt may apply randomization or may cluster with an existing anonymous mapping. If this first attempt fails, perform a first-fit search of the available address space."

Why is it necessary to set curr_min_addr here? We know try == 1, so after following the goto we will assign to curr_min_addr again.

MAP_IS_SUB_MAP, for consistency with MAP_ENTRY_IS_SUB_MAP?

Did you mean to clear the flag here?

I don't think we should update anon_loc if max_addr is specified (e.g., MAP_32BIT was passed).

"Decide whether to"

I think it would be worth adding a counter for vm_map_findspace() failures, at least for the en_aslr case.

I added the counter for try == 2 restarts.

IMO iti is of limited usefulness because it is global, but I do not think it is worth adding the per-vmspace counters and the whole required infrastructure for it.

I don't follow what you mean by the "entire executable image."

For ASLR having only opt-out is reasonable, IMO.

For other bits (max_prot, W^X, etc.) initially we probably want both opt-in and opt-out, as there may be some time before we can enable features by default.

@markj are you suggesting even committing the coalescing separately?

Let's comment this here too

Discussed on IRC, suggest either NT_FREEBSD_FCTL_ASLR_DIS or NT_FREEBSD_FCTL_ASLR_DISABLE - doesn't matter so much for this in isolation but want something that will have a regular pattern when we add MAX_PROT and other feature bits.

Flag name LGTM

"enable" is more common in the tree than "enabled" (27 to 3 on my laptop) and IMO preferable.

Also, should we have a kern.elfN.aslr.* tree? So e.g. kern.elf64.aslr.enable, perhaps kern.elf64.aslr.pie_enable?

If max_addr != 0, you've guaranteed that *addr + length <= max_addr, but after this modification to *addr, the guarantee won't hold and you may return an address beyond max_addr. Or so it seems to me.

You mean, in the situation where vm_map_maxaddr(map) > max_addr. Please see D19688.