4 ms·

It's not hard to make an ftrace facility for C functions. I did it with [1] and [2] (using a concept I call "stackpools") for this comment since I've had it in

It's not hard to make an ftrace facility for C functions. I did it with [1] and [2] (using a concept I call "stackpools") for this comment since I've had it in mind for a while, and this post pushed me to do it. What jart's does better than mine is that hers is not opt-in; you don't have to put special macros for it. Mine requires that. Hers also can instrument all functions; mine does not get external functions. What mine does better is that it is not a security issue wrt W^X, and it also implements scope- and function-based RAII. For example, now that I have implemented it, I can change all of my direct calls to unlock mutexes at the end of a function into destructors, and change the lock calls to use the stackpools. After doing that, then any function that buys into the system I have, and that takes a lock, will release the lock by the end of the function without anything special, just like using RAII with locks in C++. I can turn ftracing on and off at build time as well. [3] Using the tests/gaml/gaml_fuzz program, which is still incomplete, you can see this. Assuming the build directory is `build/`, running: cat ../build.gaml | tests/gaml/gaml_fuzz with ftracing turned on will give you an ftrace that looks like: main() y_fs_filebytes_fread() y_strucon_handleError() y_strucon_handleError() y_fs_filebytes_fread() y_strucon_status() y_strucon_status() y_exit() I could make it prettier, and I probably will in subsequent commits. In other words, it's not magic, and in my opinion, it's not really a good idea because of the security implications because while you could argue that it's only for development, it's still another route to gain access to a developer's machine or a CI machine. [1]: https://git.yzena.com/Yzena/Yc/src/commit/80713280c4298505539fd0c1402585a7d8ba0456/src/pool/stackpool.c#L496-L561 https://git.yzena.com/Yzena/Yc/src/commit/80713280c429850553... [2]: https://git.yzena.com/Yzena/Yc/src/commit/80713280c4298505539fd0c1402585a7d8ba0456/src/concurrency/strucon.h#L403-L523 https://git.yzena.com/Yzena/Yc/src/commit/80713280c429850553... [3]: https://git.yzena.com/Yzena/Yc/src/commit/80713280c4298505539fd0c1402585a7d8ba0456/CMakeLists.txt#L64-L70 https://git.yzena.com/Yzena/Yc/src/commit/80713280c429850553...

jart 4y ago
Why is it a security risk? The point of the .privileged section is that it remains in the W^X state the whole time. OpenBSD permits doing code morphing that way, so it must be secure. Code morphing is pretty much essential to how things like virtual machines work too. Would you say that JIT is insecure?
- gavinhoward 4y ago
  Just because OpenBSD does it does not mean it's not a security issue. It just means that they have to. OpenBSD is not some impenetrable vault of an OS. Yes, JIT is insecure. You best hope that you don't have some kind of vulnerability in your JIT or an attacker can do return-oriented programming by making their own gadgets, i.e., they don't have to find the gadget they want, they can just create it. In fact, this exact problem with JIT's is why I don't implement interpreters with JIT's. Instead, I generate bytecode and then run that because I can more easily sandbox it that way. But that is ignoring the biggest elephant in the room. You're doing this in a libc. The libc is where attackers usually search for gadgets. It's not a good combination to have a libc, one of the highest value targets, to allow self-modifying code with an easy way to activate it. I remember trying Cosmopolitan once. Ran into a bug right away. It couldn't handle spaces in a filename. I can only imagine what kinds of bugs it still has and continues to get as you add features. And what bugs of those will allow creation and exploitation of gadgets now that you have this? We had a conversation on lobste.rs where I talked about why I don't think what you're doing is a good idea. You deleted everything you said. That's not a good look. The bug I ran into trying Cosmopolitan was not a good look. Not understanding the risks of what you are doing is not a good look. All of that has made Cosmopolitan radioactive to me. I won't touch it.
  - jart 4y ago
    > It couldn't handle spaces in a filename. Then show me the GitHub issue you filed that proves it. If you're talking about the Makefile configuration, I don't care. > I can only imagine what kinds of bugs it still has and continues to get as you add features. [...] All of that has made Cosmopolitan radioactive to me. I won't touch it. Good. Please stop following me.
    - gavinhoward 4y ago
      > Then show me the GitHub issue you filed that proves it. If you're talking about the Makefile configuration, I don't care. You already fixed it [1], which was good. I left that experience with a neutral feeling; it was good that you fixed it, but it was not good that such a common thing was not handled. I decided to keep a watch on Cosmopolitan with a bit of happy anticipation. (It was later seeing you on this site and lobste.rs that left a bad taste in my mouth.) You're right, though, that a Makefile won't be able to handle it, and that that's not Cosmopolitan's problem, though I would suggest a different build system. > Good. Please stop following me. Oh, I don't follow you. But I check this site and lobste.rs regularly, and I see you post. Since I believe that Cosmopolitan is the wrong direction for the industry to go, I express that opinion. Nothing wrong with that, especially since you do the opposite by so zealously marketing Cosmopolitan. And it's easy to notice one of your submissions; your domain is instantly recognizable, as is your username. Basically, Cosmopolitan may be radioactive to me, but that doesn't mean I won't express my opinion about it when I see a submission about it, and that does not mean I'm "following" you; it just means I'm an opportunist. If expressing my opinion of your software makes you unhappy, that's not my problem, it is yours. [1]: https://github.com/jart/cosmopolitan/issues/11 https://github.com/jart/cosmopolitan/issues/11

jart 4y ago

Why is it a security risk? The point of the .privileged section is that it remains in the W^X state the whole time. OpenBSD permits doing code morphing that way, so it must be secure. Code morphing is pretty much essential to how things like virtual machines work too. Would you say that JIT is insecure?

gavinhoward 4y ago
Just because OpenBSD does it does not mean it's not a security issue. It just means that they have to. OpenBSD is not some impenetrable vault of an OS. Yes, JIT is insecure. You best hope that you don't have some kind of vulnerability in your JIT or an attacker can do return-oriented programming by making their own gadgets, i.e., they don't have to find the gadget they want, they can just create it. In fact, this exact problem with JIT's is why I don't implement interpreters with JIT's. Instead, I generate bytecode and then run that because I can more easily sandbox it that way. But that is ignoring the biggest elephant in the room. You're doing this in a libc. The libc is where attackers usually search for gadgets. It's not a good combination to have a libc, one of the highest value targets, to allow self-modifying code with an easy way to activate it. I remember trying Cosmopolitan once. Ran into a bug right away. It couldn't handle spaces in a filename. I can only imagine what kinds of bugs it still has and continues to get as you add features. And what bugs of those will allow creation and exploitation of gadgets now that you have this? We had a conversation on lobste.rs where I talked about why I don't think what you're doing is a good idea. You deleted everything you said. That's not a good look. The bug I ran into trying Cosmopolitan was not a good look. Not understanding the risks of what you are doing is not a good look. All of that has made Cosmopolitan radioactive to me. I won't touch it.
- jart 4y ago
  > It couldn't handle spaces in a filename. Then show me the GitHub issue you filed that proves it. If you're talking about the Makefile configuration, I don't care. > I can only imagine what kinds of bugs it still has and continues to get as you add features. [...] All of that has made Cosmopolitan radioactive to me. I won't touch it. Good. Please stop following me.
  - gavinhoward 4y ago
    > Then show me the GitHub issue you filed that proves it. If you're talking about the Makefile configuration, I don't care. You already fixed it [1], which was good. I left that experience with a neutral feeling; it was good that you fixed it, but it was not good that such a common thing was not handled. I decided to keep a watch on Cosmopolitan with a bit of happy anticipation. (It was later seeing you on this site and lobste.rs that left a bad taste in my mouth.) You're right, though, that a Makefile won't be able to handle it, and that that's not Cosmopolitan's problem, though I would suggest a different build system. > Good. Please stop following me. Oh, I don't follow you. But I check this site and lobste.rs regularly, and I see you post. Since I believe that Cosmopolitan is the wrong direction for the industry to go, I express that opinion. Nothing wrong with that, especially since you do the opposite by so zealously marketing Cosmopolitan. And it's easy to notice one of your submissions; your domain is instantly recognizable, as is your username. Basically, Cosmopolitan may be radioactive to me, but that doesn't mean I won't express my opinion about it when I see a submission about it, and that does not mean I'm "following" you; it just means I'm an opportunist. If expressing my opinion of your software makes you unhappy, that's not my problem, it is yours. [1]: https://github.com/jart/cosmopolitan/issues/11 https://github.com/jart/cosmopolitan/issues/11