3 ms·

Probably you're right, it's about the same thing as it is now. I was thinking in this terms: If a program A depends on a function D, this function is another pr

Probably you're right, it's about the same thing as it is now. I was thinking in this terms: If a program A depends on a function D, this function is another program D, when I run program A, it looks for function D, now normally in compile time I have a full path to dependency, now instead a system has a set of functions running, let's say that one of those is function D, how do I ensure as a user that function D is not mimicking something it is not? And I guess it's the same of right now, just make sure to don't run malicious software, but I was also thinking that probably it could be much harder to track programs as functions reusable from other functions(apps)

xpe 3y ago
The specific mechanisms are key to understanding. Your question prompted me to review the details of how system calls and linking works in Linux and think about it in a broader context. Programming languages also have considerable variation when it comes to dependency management. There is a menu of options w.r.t. symbol lookup and dispatch, ranging from static to dynamic. I’ve mostly been an application level developer. Something interesting about OS development is system function calls behave differently when called in different contexts (privilege levels, capabilities). One mechanism in play is dynamic dispatch. The end effect is that the underlying details of a system call can be quite different for different callers. (The Unison language has some innovative ideas IMO.) If you come across a good resource that covers these topics as a “design menu” across different OS styles and/or a historical look at security mitigations (as opposed to only a summary of what is used now in Linux), could you share it?