2 ms·

> The allocator gets address space. The allocator gets address space from the OS. > The OS doesn't just shove things into your process in general. It can't re

> The allocator gets address space. The allocator gets address space from the OS. > The OS doesn't just shove things into your process in general. It can't return a 52 bit pointer out of nowhere. My first draft mentioned OS explicitly but it's not really the OS that's making the decisions. Of course it’s the OS making the decision. You ask the OS for memory and it returns whatever it wants. The allocators acts as bridge between the application and OS and can do cool stuff but if the OS returns a 52 bits pointer there isn’t a thing the allocator can do about it that would result in a working 48 bits pointer. > It does show that, but that decorrelation is neither necessary nor sufficient to solve this problem. It absolutely is necessary, since the entire subject is to not break applications requiring a smaller address space for their tagging scheme to work even as the system and other applications migrate to larger ones.

Dylan16807 3y ago
The allocator can choose which part of the address space to fill. It does not have to deal with "whatever the OS wants". > It absolutely is necessary, since the entire subject is to not break applications requiring a smaller address space for their tagging scheme to work even as the system and other applications migrate to larger ones. Even if you have a 1:1 memory mapping, you can leave the applications that want small addresses at the start of memory. You don't need to decorrelate virtual and physical addresses to do that.
- masklinn 3y ago
  > The allocator can choose which part of the address space to fill. No it can not. The allocator can request which part of the address space to fill, and the OS is completely free to ignore that request. > It does not have to deal with "whatever the OS wants". It absolutely does, the OS is ultimately who controls both the physical and virtual address spaces. > Even if you have a 1:1 memory mapping, you can leave the applications that want small addresses at the start of memory. Up until it’s all taken and then you can’t do that anymore.
  - Dylan16807 3y ago
    > the OS is completely free to ignore that request I'm assuming an OS that isn't refusing to do things for no reason. Aren't you? If we're accounting for capricious refusal of program allocation requests, then 64-bit clean programs can't safely run either. > Up until it’s all taken Which is no worse than it was before you upgraded your RAM. Not that anyone is running big programs on systems without MMUs.
    - masklinn 3y ago
      > I'm assuming an OS that isn't refusing to do things for no reason. > Aren't you? You are apparently assuming the OS would have no reason to refuse. I've seen DeRaadt cook, I'd rather not assume anything that's not guaranteed. And I especially wouldn't make up new modes of operations which don't exist for no justifiable reason.

Dylan16807 3y ago

The allocator can choose which part of the address space to fill. It does not have to deal with "whatever the OS wants". > It absolutely is necessary, since the entire subject is to not break applications requiring a smaller address space for their tagging scheme to work even as the system and other applications migrate to larger ones. Even if you have a 1:1 memory mapping, you can leave the applications that want small addresses at the start of memory. You don't need to decorrelate virtual and physical addresses to do that.

masklinn 3y ago
> The allocator can choose which part of the address space to fill. No it can not. The allocator can request which part of the address space to fill, and the OS is completely free to ignore that request. > It does not have to deal with "whatever the OS wants". It absolutely does, the OS is ultimately who controls both the physical and virtual address spaces. > Even if you have a 1:1 memory mapping, you can leave the applications that want small addresses at the start of memory. Up until it’s all taken and then you can’t do that anymore.
- Dylan16807 3y ago
  > the OS is completely free to ignore that request I'm assuming an OS that isn't refusing to do things for no reason. Aren't you? If we're accounting for capricious refusal of program allocation requests, then 64-bit clean programs can't safely run either. > Up until it’s all taken Which is no worse than it was before you upgraded your RAM. Not that anyone is running big programs on systems without MMUs.
  - masklinn 3y ago
    > I'm assuming an OS that isn't refusing to do things for no reason. > Aren't you? You are apparently assuming the OS would have no reason to refuse. I've seen DeRaadt cook, I'd rather not assume anything that's not guaranteed. And I especially wouldn't make up new modes of operations which don't exist for no justifiable reason.