3 ms·

Okay, let me know when I can call process_vm_writev or ptrace and have Fil-C verify safety properties on the result.

• jcranmer 3mo ago
  Don't forget reads and writes of /proc/self/mem! :-)
  • modeless 3mo ago
    Better include Rowhammer too. Maybe Fil-C should run a test and refuse to start on any system with bad RAM or unpatched CPU errata. It could also monitor the voltage to protect against undervolting attacks. And you'll need some cosmic ray shielding too. Of course I'm kidding, but it is absolutely the case that if you truly care about safety you need to consider more than the program source code and binary, but also the environment, including kernel and hardware. The user doesn't care if their web browser got hacked via stack buffer underflow or /dev/exynos-mem or Rowhammer; the result is the same.
    • pizlonator 3mo ago
      Sure all of those are escape hatches that work against any memory safety tech. Point is, Fil-C goes further than any other memory safety tech in terms of what it guards
      • modeless 3mo ago
        Fully agreed. At some point you have to draw a line and say that the rest is the responsibility of the kernel and hardware and user, and I think Fil-C drew that line in the right place.
      • josephg 3mo ago
        How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.
        • pizlonator 3mo ago
          Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those
          • josephg 3mo ago
            The number of lines of raw C isn’t the only way to measure the trustworthiness of a codebase. Go, C# and friends may be bigger projects. But they’re also more mature projects. At this point, far more eyeballs have scoured their codebases looking for security bugs. > Fil-C is safer than those Says you. It seems presumptuous to me to be so dismissive of their work. The Go and C# teams do good work. But I wasn’t even asking about safety. I’m curious about ergonomics and performance. Fil-C isn’t the only safe wrapper around raw syscalls. How is cross OS compatibility with Fil-C? How nice are the APIs to use? UNIX syscalls are pretty badly designed imo. The error paths alone are a mess.
          • ncruces 3mo ago
            Go doesn't rely on much C/C++, not recently at least. Particularly on Linux.
          • Splizard 3mo ago
            Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.
            • pizlonator 3mo ago
              Yeah what I said is true of TS and C#, but not of Go. Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.
              • quotemstr 3mo ago
                Races in Fil-C allow access to one object through a pointer to a different object if there's an attacker-controlled offset involved. Fil-C's safety guarantees therefore fail to apply in this situation.
      • quotemstr 3mo ago
        If we strip away the semantic maneuvering, your argument becomes this: Rust is unsafe because it lets people who aren't you, Pizlo, write unsafe code. Safety means trusting only you with machine code. Anyone could do the same with a Rust lint rule if he wanted. He wouldn't, because this policy is not the way to secure software.