Git: Introduce Rust and announce it will become mandatory in the build system • Hacker News Board

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#431

Post by 1718627440 » Fri, Sep 26, 2025, 9:30 PM UTC

aw1621107 wrote: post #429

1718627440 wrote: post #425

Earlier quoted context omitted.

Yes, but this is not across a trust boundary. Since these are in the same process/program. Rust "only" applies checks at compile time, it doesn't enforce security. Not sure, if I'm clear. Rust is like cooperative multitasking, nice but not guaranteed. My claim here is, that we actually want preemptive multitasking.

I'm not quite sure I'm understanding your analogy here, but would that effectively mean each allocation lives in its own process?

Maybe? If we try to backport it to the current hardware/software. It would be an improvement to configure the MMU to enforce boundaries below a process.

However my point was that not every allocation is a trust boundary. What a program does in its own memory doesn't matter at all, this is gone in an instant. Everything that matters is I/O and this goes through syscalls, so there security can be enforced.

Why do you care about corrupting process memory? The memory state itself is totally irrelevant. What annoys you is when it e.g. deletes a file it is not supposed to. Would you rejoice when the file gets still deleted, but the process memory is totally fine? Of course not. The only thing that matters is the deletion of the file, you don't actually care about the memory safety. Thus, what you actually want is the computer to know that the file is not supposed to be deleted, when you have that, the memory can be trashed like the program likes to.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#432

Post by aw1621107 » Sat, Sep 27, 2025, 4:23 AM UTC

1718627440 wrote: post #430

aw1621107 wrote: post #428

Earlier quoted context omitted.

> In SPlint you would describe something as `special` and then describe the individual elements. Interesting. That does seem to provide more flexibility, though based on what the manual says I still feel like it's not quite to the same level as named lifetimes since `special` looks like it revolves around allocation/initialization? At least based on a quick skim of the manual structs with non-owning pointers still se…

> At least based on a quick skim of the manual structs with non-owning pointers still seems like a potential difference since from what I can tell struct field checks are either for ownership (/@only@/ for fields by default), initialization/allocation (`partial`, state clauses), or requires overhead (/@refs@/). Nothing quite like "the data here will live for some arbitrary lifetime(s) dictated by the use context". Th…

> As to my understanding, the lifetime of an object is bound by the lifetime of the underlying allocation and is the time during which the storage of the allocation is initialized without interruption.

I think that's more or less the same definition used by Rust. It's just that the borrow checker gives you some more options to use/manipulate lifetimes.

Not entirely sure this would help, the consider this type from earlier:

    struct ByteSlice {
        slice: &'a [u8],
    }

This describes a struct containing a non-owning reference to a slice of bytes where the reference has some "placeholder" lifetime 'a (where 'a could be checked at the point of use and in a more abstract way without necessarily knowing about an actual underlying object). This could be handy if you need to refer to multiple subsets of a whole and don't want to make a copy - say, if you were writing a zero-copy parser. The borrow checker will ensure that the underlying data will always be valid for as long as this struct is used.

I didn't see an obvious analogous annotation in the Splint user manual that lets it check this kind of construct. This struct doesn't own the data it references, so /*@only@*/ doesn't apply. The reference itself as well as the data it references will be initialized since `MaybeUninit` isn't involved, so `partial` and state clauses don't apply. And no reference counting is involved, so /*@refs@*/ doesn't apply either. `dependent` seems like it might fit, but that isn't checked.

The names also let you be more specific with your lifetimes. For example, you could create a struct with references with two different but overlapping lifetimes (though I think such cases would be rare in practice):

    struct ByteSlices {
        first: &'a [u8],
        second: &'b [u8],
    }

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#433

Post by aw1621107 » Mon, Sep 29, 2025, 5:19 AM UTC

1718627440 wrote: post #431

aw1621107 wrote: post #429

Earlier quoted context omitted.

I'm not quite sure I'm understanding your analogy here, but would that effectively mean each allocation lives in its own process?

Maybe? If we try to backport it to the current hardware/software. It would be an improvement to configure the MMU to enforce boundaries below a process. However my point was that not every allocation is a trust boundary. What a program does in its own memory doesn't matter at all, this is gone in an instant. Everything that matters is I/O and this goes through syscalls, so there security can be enforced. Why do you c…

> Everything that matters is I/O and this goes through syscalls, so there security can be enforced.

I don't think "good" I/O and "bad" I/O are necessarily distinguishable by the OS ahead of time and/or in general. The OS isn't going to know whether the program wrote out a proper file or complete gibberish, or whether the numbers you're displaying were derived from uninitialized values, or whether what you're sending over the wire is what you intended (e.g., Heartbleed), etc., but those are very much things one should care about!

> Why do you care about corrupting process memory? The memory state itself is totally irrelevant.

Strong disagree here. If memory is corrupted all bets are off, especially if you know your program is actually supposed to perform some I/O.

> The only thing that matters is the deletion of the file, you don't actually care about the memory safety.

You would care if memory safety issues directly led to file deletion!

> Thus, what you actually want is the computer to know that the file is not supposed to be deleted, when you have that, the memory can be trashed like the program likes to.

So what happens if you know a file is supposed to be deleted but memory corruption led to the wrong one being deleted?