Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linear Address Spaces: Unsafe at any speed (2022)

queue.acm.org

Post reply on HN
Print view View original

151–160 of 183 posts

Re: Linear Address Spaces: Unsafe at any speed (2022)

#151

Post by cryptonector »

imtringued wrote: post #139
suspended_state wrote: post #93

Earlier quoted context omitted.

> Code has to have addresses for calls and branches. Does it mean that at that level an address has to be an offset in a linear address space? If you have hardware powerful enough to make addresses abstract, couldn't also provide the operations to manipulate them abstractly?

This is probably the worst possible way to implement a processor. Instead of just bumping the instruction pointer by one or an offset, you now need to have code labels in your processor and a way to efficiently look them up. goto "exit" means the processor needs to have a lookup table of all the possible nodes in the computational graph. Calling a function requires a global look up table. How is that table implemente…

See my sibling comment. Basically each text fragment (either each branch-free run of instructions or each function/method) would need to be an object w/ capability, and the linker-loader must arrange for all text references to have the correct pointers. And then it would work. It's just a complication of the linker-loader, but once a program is loaded there would be no further lookups (unless you use something like `dlsym()`). The compromise to make is that within each such text object you have linear addressing with small offsets.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#152

Post by nine_k »

bri3d wrote: post #20
nine_k wrote: post #16

Earlier quoted context omitted.

Aerospace, automotive, and medical devices represent a strong demand. They sometimes use and run really interesting stuff, due to the lack of such a strong backwards-compatibility demand, and a very high cost of software malfunction. Your onboard engine control system can run an OS based on seL4 with software written using Ada SPARK, or something. Nobody would bat an eye, nobody needs to run 20-years-old third-party…

I don’t think these devices represent a demand in the same way at all. Secure boot firmware is another “demand” here that’s not really a demand. All of these things, generally speaking, run unified, trusted applications, so there is no need for dynamic address space protection mechanisms or “OS level” safety. These systems can easily ban dynamic allocation, statically precompute all input sizes, and given enough effo…

In a way, I agree. If you can verify the entire system throughout, you can remove certain runtime checks, such as the separation between the OS and tasks. If you have only one program to run, you can use a unikernel.

I suspect that specifically car / aircraft / spacecraft computers receive regular updates, and these updates change the smallest part they can. So they have separate programs / services running on top of a more general OS. The principles of defense in depth requires that each component should be hardened separately, to minimize the blast radius if a bug slips in.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#153

Post by nine_k »

imtringued wrote: post #136
nine_k wrote: post #9

Earlier quoted context omitted.

But we don't have a linear address space, unless you're working with a tiny MCU. For last like 30 years we have virtual address space on every mainstream processor, and we can mix and match pages the way we want, insulate processes from one another, add sentinel pages at the ends of large structures to generate a fault, etc. We just structure process heaps as linear memory, but this is not a hard requirement, even on…

This feels like a pointless form of pendantry. Okay, so we went from linear address spaces to partioned/disaggregated linear address spaces. This is hardly the victory you claim it is, because page sizes are increasing and thus the minimum addressable block of memory keeps increasing. Within a page everything is linear as usual. The reason why linear address spaces are everywhere has to do with the fact that they are…

We have a linear address space where we can map physical RAM and memory-mapped devices dynamically. Every core, at any given time, may have its own view of it. The current approach uses pretty coarse granularity, separating execution at the process level. The separation could be more granular.

The problem is the granularity of trust within the system. Were the MMU much faster, and TLB much larger (say, 128MiB of dedicated SRAM), the granularity might be pretty high, giving each function's stack a separate address space insulated from the rest of RAM. This is possible even now, just would be impractically slow.

Any hierarchical (tree-based) addressing scheme is equivalent to a linear addressing scheme, pick any tree traversal algorithm. Any locally-hierarchical addressing scheme seemingly can be implemented with (short) offsets in a linear address space; this is how most jumps in x64 and aarch64 are encoded, for instance.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#154

Post by senderista »

gpderetta wrote: post #145
inkyoto wrote: post #65

Earlier quoted context omitted.

> Because the attempts at segmented or object-oriented address spaces failed miserably. > That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin. I would further posit that segmented and object-oriented address spaces have failed and will continue to fail for as long as we have a separation into two di…

I think seamless persistent storage is also bound to fail. There are significant differences on how we treat ephemeral objects in programs and persistent storage. Ephemeral objects are low value, if something goes wrong we can just restart and recover from storage. Persistent storage is often high value, we make significant effort to guarantee its consistency and durability even in the presence of crashes.

“Persistent memory leaks” will be an interesting new failure mode.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#155

Post by dmitrygr »

philipallstar wrote: post #140
dmitrygr wrote: post #86

“Why don’t we do $thing_that_decisively_failed instead of $thing_that_evolved_to_beat_all_other_approaches?” Usually this sort of question comes from a lack of understanding of the history of the failure of the first and the success of the second. The fence principle always applies “don’t tear down a fence till you understand why it was built” Linear address spaces allow for how computers actually operate - layers. O…

> The fence principle always applies “don’t tear down a fence till you understand why it was built” Don't rename Chesterton's Fence until you understand why it was named that.

Was not aware the fence had a name. Learned it in Russian without the name. TIL, thank you.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#156

Post by convolvatron »

aforwardslash wrote: post #98
convolvatron wrote: post #15

Earlier quoted context omitted.

its entirely possible to implement segments on top of paging. what you need to do is add the kernel abstractions for implementing call gates that change segment visibility, and write some infrastructure to manage unions-of-a-bunch-of-little-regions. I haven't implemented this myself, but a friend did on a project we were working on together and as a mechanism it works perfectly well. getting userspace to do the right…

If I understood correctly, you'te talking about using descriptors to map segments; the issue with this approach is two-fold: it is slow (as each descriptor needs to be created for each segment - and sometimes more than one, if you need write-execute permissions), and there is a practical limit on the number of descriptors you can have - 8192 total, including call gates and whatnot. To extend this, you need to use LDT…

no, not at all. we weren't using the underlying segmentation support. we just added kernel facilities to support segment ids and ranges and augment the kernel region structure appropriately. A call gate is just a syscall that changes the processes VM tables to include or drop regions (segments) based on the policy of the call.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#157

Post by convolvatron »

tliltocatl wrote: post #54
convolvatron wrote: post #15

Earlier quoted context omitted.

its entirely possible to implement segments on top of paging. what you need to do is add the kernel abstractions for implementing call gates that change segment visibility, and write some infrastructure to manage unions-of-a-bunch-of-little-regions. I haven't implemented this myself, but a friend did on a project we were working on together and as a mechanism it works perfectly well. getting userspace to do the right…

But that wouldn't protect against out-of boundary access (which is the whole point of segments), would it?

thats enforced by the VM hardware - we just shuffle the PTEs around to match the appropriate segment view

Re: Linear Address Spaces: Unsafe at any speed (2022)

#158

Post by bri3d »

nine_k wrote: post #152
bri3d wrote: post #20

Earlier quoted context omitted.

I don’t think these devices represent a demand in the same way at all. Secure boot firmware is another “demand” here that’s not really a demand. All of these things, generally speaking, run unified, trusted applications, so there is no need for dynamic address space protection mechanisms or “OS level” safety. These systems can easily ban dynamic allocation, statically precompute all input sizes, and given enough effo…

In a way, I agree. If you can verify the entire system throughout, you can remove certain runtime checks, such as the separation between the OS and tasks. If you have only one program to run, you can use a unikernel. I suspect that specifically car / aircraft / spacecraft computers receive regular updates, and these updates change the smallest part they can. So they have separate programs / services running on top of…

> I suspect that specifically car / aircraft / spacecraft computers receive regular updates, and these updates change the smallest part they can.

In the space I am very familiar with, automotive, this is not true for code changes to most automotive control units; the "application software" code for each control unit is treated as a single entity and built, supplied, and modified at this level of granularity. Infotainment and digital cockpit is the only major exception, but even then, only for the "unsafe" part (Linux/QNX/Windows); the "safe" part is usually a single-image single-application running on a safety processor alongside.

Sometimes personalization/vehicle-specific "data sets" or calibration _data_ (ie ECU tunes) can be updated without updating the application software, but the application software for each unit is generally treated as a large unified firmware blob. For example in every ECU I am aware of, modifying the application software logic (which is usually modeled in something like like Simulink/ASCET, not code directly) triggers a full code regeneration, recompilation, and generates a complete new firmware image with an updated Application Software version. There isn't any notion of shipping a new "turbocharger control" code module, or a new "diagnostics" code module, or whatever, even if they are constructed at this granularity in the code generation suite or run at this task granularity in the RTOS.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#159

Post by antonvs »

senderista wrote: post #154
gpderetta wrote: post #145

Earlier quoted context omitted.

I think seamless persistent storage is also bound to fail. There are significant differences on how we treat ephemeral objects in programs and persistent storage. Ephemeral objects are low value, if something goes wrong we can just restart and recover from storage. Persistent storage is often high value, we make significant effort to guarantee its consistency and durability even in the presence of crashes.

“Persistent memory leaks” will be an interesting new failure mode.

Anyone using object storage at scale (e.g. S3 or GCS) is already likely to be familiar with this.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#160

Post by antonvs »

sph wrote: post #118

> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? What a weird question, conflating one thing with the other. I’m working on a object capability system, and trying hard to see if I can make it work using a linear address space so I don’t have to waste two or three pages per “process” [1][2] I really don’t see how objects have anything…

> What a weird question, conflating one thing with the other.

I can only imagine he means something different by “object-oriented” than the concept at the programming language level. And if he is referring to that, then I hope no-one ever lets him near anything resembling hardware design.

Post reply on HN