5 ms·

> I wonder if it's feasible to use Fil-C to do multitasking between mutually untrusted processes on a computer without an MMU? You could. That said, FUGC’s gut

> I wonder if it's feasible to use Fil-C to do multitasking between mutually untrusted processes on a computer without an MMU? You could. That said, FUGC’s guts rely on OS features that in turn rely on an MMU. But you could make a version of FUGC that has no such dependency. As for perf - 4x is the worst case and that number is out there because I reported it. And I report worst case perf because that’s how obsessive I am about realistically measuring, and then fanatically resolving, perf issues Fact is, I can live on the Fil-C versions of a lot of my favorite software and not tell the difference

kragen 1y ago
Yeah, I meant to be clear that 4× was the worst case, and I think it's an impressive achievement already, and perfectly fine for almost everything. After all, running single-threaded software on an 8-core CPU is already an 8× slowdown, right? And people do that all the time! What's the minimal code size overhead for FUGC?
- pizlonator 1y ago
  > What's the minimal code size overhead for FUGC? I don’t have good data on this. The FUGC requires the compiler to emit extra metadata and that metadata is hilariously inefficient right now. I haven’t bothered to optimize it. And the FUGC implementation pulls in all of libpas even though it almost certainly doesn’t have to. So I don’t know what minimal looks like right now
  - gr4vityWall 1y ago
    It's refreshing to see a honest, no-nonsense, not full of marketing-speak reply for once. Your replies on this thread have been great. :)
  - kragen 1y ago
    I see, thanks!
modeless 1y ago
A Fil-C kernel that ran the whole system in the same address space, safely, would sure be something. Getting rid of the overhead of hardware isolation could compensate for some of the overhead of the software safety checks. That was the dream of Microsoft's Singularity project back in the day. I guess there would be no way to verify that precompiled user programs actually enforce the security boundaries. The only way to guarantee safety in such a system would be to compile everything from source yourself.
- pizlonator 1y ago
  You could have enforcement that binaries use Fil-C rules suing proof carrying code
  - kragen 1y ago
    I'm skeptical that PCC can work in practice with existing social practices around software development, because neither users nor implementors can tell the difference between a correct verifier and one that has flaws that aren't being actively exploited yet, but they can sure tell the difference between a fast system and a slow one. The incentives are strong to drive the runtime cost as close to zero as possible, which involves making your proof-checking system so expressive that it's hard to get right. The closer you get to zero, the more performance-sensitive your userbase gets. No part of your userbase is actively testing the parts of your verifier that reject programs; they try to avoid generating programs that get rejected, and as the verifier gets larger and larger, it requires more and more effort to generate code that exploits one of its bugs, although there are more and more of them. As the effort required to slip malicious code past the verifier grows, the secret in-house tools developed by attackers gives them a larger and larger advantage over the defenders. Continued "maintenance" applied to the verifier drive its size and complexity up over time, driving the probability of a flaw inexorably toward 100%, while, if it is not "maintained" through continuous changes, it will break as its dependencies change, it will be considered outdated, and nobody will understand it well enough to fix a bug if it does surface. We've seen this happen with Java, and although it's clearly not unavoidable in any kind of logical sense, it's a strong set of social pressures. Dynamic checking seems much more memetically fit: developers will regularly write code that should fail the dynamic checks, and, if it passes instead, they will send you an annoyed bug report about how they had to spend their weekend debugging.
willvarfar 1y ago
When you run the Fil-C versions of your favourite software, does it have a sanitizer mode that reports bugs like missing free() etc? And have you found any bugs this way?
- pizlonator 1y ago
  Well missing free is just swallowed by the GC - the leak gets fixed without any message. I have found bugs in the software that I’ve ported, yeah.
  - purpleidea 1y ago
    This is neat work. I noticed on your software page some patches you had to make to get those things to compile. Have you sent those upstream? Eg, I noticed a simple 1 line bash change for example.
  - writebetterc 1y ago
    To add on top of this: This is a tracing GC. It only ever visits the live data, not the dead data. In other words, it would need a lot more special support if it wanted to report the dead objects.
    - kragen 1y ago
      Really? How does a non-moving GC make dead objects available for reallocation without visiting them?
      - torginus 1y ago
        Why would it need to visit them? It just marks the address ranges as available in its internal bookkeeping (bitmaps etc).
        kragen 1y ago
        In the general case there are as many newly available address ranges as dead objects, so that counts as visiting them in this context.
torginus 1y ago
How would you go about writing a program/function that runs as close to native speed as possible on Fil-C? How much more memory do GC programs tend to use? Curious, how do you deal with interior pointers, and not being able to store type info in object headers, like most GC languages do (considering placement new is a thing, you can't have malloc allocate a header then return the following memory, and pointer types can lie about what they contain)? You mention 'accurate' by which I assume you use the compiler to keep track of where the pointers are (via types/stackmaps). How do you deal with pointers that get cast to ints, and then back?
- pizlonator 1y ago
  > How would you go about writing a program/function that runs as close to native speed as possible on Fil-C? Avoid pointer chasing. Use SIMD. > How much more memory do GC programs tend to use? I would estimate 2x Fil-C has additional overheads not related to GC, so maybe it’s higher. I haven’t started measuring and optimizing memory use in anger. > Curious, how do you deal with interior pointers, and not being able to store type info in object headers, like most GC languages do (considering placement new is a thing, you can't have malloc allocate a header then return the following memory, and pointer types can lie about what they contain)? See https://fil-c.org/invisicaps https://fil-c.org/invisicaps
foldr 1y ago
> As for perf - 4x is the worst case and that number is out there because I reported it I love the concept of Fil-C but I find that with the latest release, a Fil-C build of QuickJS executes bytecode around 30x slower than a regular build. Admittedly this is an informal benchmark running on a GitHub CI runner. I’m not sure if virtualization introduces overheads that Fil-C might be particularly sensitive to (?). But I’ve sadly yet to see anything close to a 4x performance difference. Perhaps I will try running the same benchmark on native non-virtualized x86 later today. Also, so I am not just whining, my Fil-C patch to the QuickJS main branch contains a fix for an issue that’s only triggered by regex backtracking, and which I think you might have missed in your own QuickJS patch: http://github.com/addrummond/jsockd/blob/main/fil-c-quickjs.patch http://github.com/addrummond/jsockd/blob/main/fil-c-quickjs....
- pizlonator 1y ago
  30x? Oof I know that I regressed quickjs recently when I fixed handling of unions. It’s a fixable issue, I just haven’t gone back and fixed it yet. I definitely don’t see 30x overhead on anything else I run. But thanks for pointing that out, I should probably actually fix the union handling the right way. (What’s happening is every time quickjs bit casts doubles to pointers, that’s currently doing a heap allocation. And it’s obviously not needed. The simplest compiler analysis would kill it. I just turned off the previous instance of that analysis because it had a soundness issue)
  - foldr 1y ago
    Thanks for the response, that’s useful to know. It’s honestly amazing (to me) that Fil-C works at all, and I’m sure the performance will continue to improve.
    - pizlonator 1y ago
      I just made quickjs 6.3x faster by fixing that bug
- kragen 1y ago
  I look forward to seeing how this shakes out. Fanatically, I hope?

kragen 1y ago

Yeah, I meant to be clear that 4× was the worst case, and I think it's an impressive achievement already, and perfectly fine for almost everything. After all, running single-threaded software on an 8-core CPU is already an 8× slowdown, right? And people do that all the time! What's the minimal code size overhead for FUGC?

pizlonator 1y ago
> What's the minimal code size overhead for FUGC? I don’t have good data on this. The FUGC requires the compiler to emit extra metadata and that metadata is hilariously inefficient right now. I haven’t bothered to optimize it. And the FUGC implementation pulls in all of libpas even though it almost certainly doesn’t have to. So I don’t know what minimal looks like right now
- gr4vityWall 1y ago
  It's refreshing to see a honest, no-nonsense, not full of marketing-speak reply for once. Your replies on this thread have been great. :)
- kragen 1y ago
  I see, thanks!

modeless 1y ago

A Fil-C kernel that ran the whole system in the same address space, safely, would sure be something. Getting rid of the overhead of hardware isolation could compensate for some of the overhead of the software safety checks. That was the dream of Microsoft's Singularity project back in the day. I guess there would be no way to verify that precompiled user programs actually enforce the security boundaries. The only way to guarantee safety in such a system would be to compile everything from source yourself.

pizlonator 1y ago
You could have enforcement that binaries use Fil-C rules suing proof carrying code
- kragen 1y ago
  I'm skeptical that PCC can work in practice with existing social practices around software development, because neither users nor implementors can tell the difference between a correct verifier and one that has flaws that aren't being actively exploited yet, but they can sure tell the difference between a fast system and a slow one. The incentives are strong to drive the runtime cost as close to zero as possible, which involves making your proof-checking system so expressive that it's hard to get right. The closer you get to zero, the more performance-sensitive your userbase gets. No part of your userbase is actively testing the parts of your verifier that reject programs; they try to avoid generating programs that get rejected, and as the verifier gets larger and larger, it requires more and more effort to generate code that exploits one of its bugs, although there are more and more of them. As the effort required to slip malicious code past the verifier grows, the secret in-house tools developed by attackers gives them a larger and larger advantage over the defenders. Continued "maintenance" applied to the verifier drive its size and complexity up over time, driving the probability of a flaw inexorably toward 100%, while, if it is not "maintained" through continuous changes, it will break as its dependencies change, it will be considered outdated, and nobody will understand it well enough to fix a bug if it does surface. We've seen this happen with Java, and although it's clearly not unavoidable in any kind of logical sense, it's a strong set of social pressures. Dynamic checking seems much more memetically fit: developers will regularly write code that should fail the dynamic checks, and, if it passes instead, they will send you an annoyed bug report about how they had to spend their weekend debugging.

willvarfar 1y ago

When you run the Fil-C versions of your favourite software, does it have a sanitizer mode that reports bugs like missing free() etc? And have you found any bugs this way?

pizlonator 1y ago
Well missing free is just swallowed by the GC - the leak gets fixed without any message. I have found bugs in the software that I’ve ported, yeah.
- purpleidea 1y ago
  This is neat work. I noticed on your software page some patches you had to make to get those things to compile. Have you sent those upstream? Eg, I noticed a simple 1 line bash change for example.
- writebetterc 1y ago
  To add on top of this: This is a tracing GC. It only ever visits the live data, not the dead data. In other words, it would need a lot more special support if it wanted to report the dead objects.
  - kragen 1y ago
    Really? How does a non-moving GC make dead objects available for reallocation without visiting them?
    - torginus 1y ago
      Why would it need to visit them? It just marks the address ranges as available in its internal bookkeeping (bitmaps etc).
      - kragen 1y ago
        In the general case there are as many newly available address ranges as dead objects, so that counts as visiting them in this context.

torginus 1y ago

How would you go about writing a program/function that runs as close to native speed as possible on Fil-C? How much more memory do GC programs tend to use? Curious, how do you deal with interior pointers, and not being able to store type info in object headers, like most GC languages do (considering placement new is a thing, you can't have malloc allocate a header then return the following memory, and pointer types can lie about what they contain)? You mention 'accurate' by which I assume you use the compiler to keep track of where the pointers are (via types/stackmaps). How do you deal with pointers that get cast to ints, and then back?

pizlonator 1y ago
> How would you go about writing a program/function that runs as close to native speed as possible on Fil-C? Avoid pointer chasing. Use SIMD. > How much more memory do GC programs tend to use? I would estimate 2x Fil-C has additional overheads not related to GC, so maybe it’s higher. I haven’t started measuring and optimizing memory use in anger. > Curious, how do you deal with interior pointers, and not being able to store type info in object headers, like most GC languages do (considering placement new is a thing, you can't have malloc allocate a header then return the following memory, and pointer types can lie about what they contain)? See https://fil-c.org/invisicaps https://fil-c.org/invisicaps

foldr 1y ago

> As for perf - 4x is the worst case and that number is out there because I reported it I love the concept of Fil-C but I find that with the latest release, a Fil-C build of QuickJS executes bytecode around 30x slower than a regular build. Admittedly this is an informal benchmark running on a GitHub CI runner. I’m not sure if virtualization introduces overheads that Fil-C might be particularly sensitive to (?). But I’ve sadly yet to see anything close to a 4x performance difference. Perhaps I will try running the same benchmark on native non-virtualized x86 later today. Also, so I am not just whining, my Fil-C patch to the QuickJS main branch contains a fix for an issue that’s only triggered by regex backtracking, and which I think you might have missed in your own QuickJS patch: http://github.com/addrummond/jsockd/blob/main/fil-c-quickjs.patch http://github.com/addrummond/jsockd/blob/main/fil-c-quickjs....

pizlonator 1y ago
30x? Oof I know that I regressed quickjs recently when I fixed handling of unions. It’s a fixable issue, I just haven’t gone back and fixed it yet. I definitely don’t see 30x overhead on anything else I run. But thanks for pointing that out, I should probably actually fix the union handling the right way. (What’s happening is every time quickjs bit casts doubles to pointers, that’s currently doing a heap allocation. And it’s obviously not needed. The simplest compiler analysis would kill it. I just turned off the previous instance of that analysis because it had a soundness issue)
- foldr 1y ago
  Thanks for the response, that’s useful to know. It’s honestly amazing (to me) that Fil-C works at all, and I’m sure the performance will continue to improve.
  - pizlonator 1y ago
    I just made quickjs 6.3x faster by fixing that bug
kragen 1y ago
I look forward to seeing how this shakes out. Fanatically, I hope?