5 ms·

In which case you can always implement a hardened vec that clears itself, like the parent commenter said. That comment had two parts, it first said that if you

In which case you can always implement a hardened vec that clears itself, like the parent commenter said. That comment had two parts, it first said that if your code is memory safe (even explicitly calling out unsafe code!) then it's not a problem, and then saying you can do it at a lower level if you have to. You can do it at a lower level either by changing the allocator, or by having a hardened vec that does a volatile write in its destructor. Look again at the text right before your quote "then the contents of deallocated memory shouldn't be internally observable."; it explicitly addresses this exact concern.

mehrdadn 9y ago
What I am trying to say is that that "if the program is memory-safe" condition is never satisfied in reality. You will be calling unsafe code no matter what you do -- not only will any non-trivial program itself have unsafe code as already called out, but because even a trivial "hello, world" would need to invoke a syscall which will not be written in Rust (until the time comes when we get a Rust kernel...) and hence not proven memory-safe. Does this make sense? Yes, if your program was secure then you wouldn't need to worry about security, but that's not the world we live in.
- Manishearth 9y ago
  Sure. At which point, again, there is still a solution, just that Vec itself won't help here. However, it's worth noting that at this level of "everything is unsafe" the problem is intractable. Just as you trust Rust's stdlib to have safely-crafted syscalls, you trust Rust's compiler to generate the right code if you tell it to do a volatile clear on a drop/resize. You have to define your trust level somewhere. For some, it is "I have audited my small amount of unsafe code (if any), and I trust Rust's stdlib". The parent's comment was addressing that level of trust. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code; at which point the most you can do is try to keep things safe, you can never succeed short of auditing the generated asm extensively.
  - mehrdadn 9y ago
    > You have to define your trust level somewhere. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code. Aw, come on. Why are you resorting to these inane arguments? Yes, people trust their compilers to be bug-free. No, that does not -- in any way, shape or form -- logically imply that they should also trust every single version of every kernel and ALSO every single kernel-module from every possible vendor and ALSO every single user-level library that their program might run on top of, whether from the past or the future, to be bug-free. To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous.
    - Manishearth 9y ago
      > To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous I'm not, I'm saying they are for some. Different folks have different trust models. I'm saying that it's a logical threat/trust model where you both trust the compiler and the kernel. This isn't everyone's model. This is clearly not yours. But this wasn't clear in the original comment and cwzwarich addressed this model (as well as yours!) and that's what I was saying. Defense in depth is good, but, again, that wasn't what was being _asked for_. You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. I don't really see the point in this discussion -- it's a metadiscussion about whether or not including an "assuming safety" portion in a comment was appropriate, and doesn't add anything.
      - mehrdadn 9y ago
        > You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. Huh? My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. People ask for that because so many attacks we see today are in external libraries and kernel-mode, and hence people are worried about that. That is not something in my fantasy; that's the model of the world we live in. You guys decided to deliberately ignore that and pretend a safe language implies worrying about attacks in external code is ridiculous. I was trying to steer back the discussion to that model. Apparently I failed; you guys win. Rust programs are invincible by definition. [1] https://news.ycombinator.com/item?id=15967604 https://news.ycombinator.com/item?id=15967604
- sitkack 9y ago
  Security is a spectrum. It appears your argument has become, "no secure programs can exist because of syscalls". Seems circular and overly reductionist.
  - mehrdadn 9y ago
    > Security is a spectrum. It appears your argument has become, "no secure programs can exist because of syscalls". Seems circular and overly reductionist. ...what? Did you read the discussion? The entire discussion was about the need to zero memory for security, despite the safety of the programming language. This entire time I've been claiming the ability to zero memory is necessary because you cannot guarantee control flow integrity when you have syscalls, external libraries, etc. Nowhere did I ever throw my hands up and make a blanket claim that secure programs cannot exist. That wasn't even the subject of the discussion.

mehrdadn 9y ago

What I am trying to say is that that "if the program is memory-safe" condition is never satisfied in reality. You will be calling unsafe code no matter what you do -- not only will any non-trivial program itself have unsafe code as already called out, but because even a trivial "hello, world" would need to invoke a syscall which will not be written in Rust (until the time comes when we get a Rust kernel...) and hence not proven memory-safe. Does this make sense? Yes, if your program was secure then you wouldn't need to worry about security, but that's not the world we live in.

Manishearth 9y ago
Sure. At which point, again, there is still a solution, just that Vec itself won't help here. However, it's worth noting that at this level of "everything is unsafe" the problem is intractable. Just as you trust Rust's stdlib to have safely-crafted syscalls, you trust Rust's compiler to generate the right code if you tell it to do a volatile clear on a drop/resize. You have to define your trust level somewhere. For some, it is "I have audited my small amount of unsafe code (if any), and I trust Rust's stdlib". The parent's comment was addressing that level of trust. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code; at which point the most you can do is try to keep things safe, you can never succeed short of auditing the generated asm extensively.
- mehrdadn 9y ago
  > You have to define your trust level somewhere. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code. Aw, come on. Why are you resorting to these inane arguments? Yes, people trust their compilers to be bug-free. No, that does not -- in any way, shape or form -- logically imply that they should also trust every single version of every kernel and ALSO every single kernel-module from every possible vendor and ALSO every single user-level library that their program might run on top of, whether from the past or the future, to be bug-free. To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous.
  - Manishearth 9y ago
    > To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous I'm not, I'm saying they are for some. Different folks have different trust models. I'm saying that it's a logical threat/trust model where you both trust the compiler and the kernel. This isn't everyone's model. This is clearly not yours. But this wasn't clear in the original comment and cwzwarich addressed this model (as well as yours!) and that's what I was saying. Defense in depth is good, but, again, that wasn't what was being _asked for_. You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. I don't really see the point in this discussion -- it's a metadiscussion about whether or not including an "assuming safety" portion in a comment was appropriate, and doesn't add anything.
    - mehrdadn 9y ago
      > You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. Huh? My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. People ask for that because so many attacks we see today are in external libraries and kernel-mode, and hence people are worried about that. That is not something in my fantasy; that's the model of the world we live in. You guys decided to deliberately ignore that and pretend a safe language implies worrying about attacks in external code is ridiculous. I was trying to steer back the discussion to that model. Apparently I failed; you guys win. Rust programs are invincible by definition. [1] https://news.ycombinator.com/item?id=15967604 https://news.ycombinator.com/item?id=15967604
sitkack 9y ago
Security is a spectrum. It appears your argument has become, "no secure programs can exist because of syscalls". Seems circular and overly reductionist.
- mehrdadn 9y ago
  > Security is a spectrum. It appears your argument has become, "no secure programs can exist because of syscalls". Seems circular and overly reductionist. ...what? Did you read the discussion? The entire discussion was about the need to zero memory for security, despite the safety of the programming language. This entire time I've been claiming the ability to zero memory is necessary because you cannot guarantee control flow integrity when you have syscalls, external libraries, etc. Nowhere did I ever throw my hands up and make a blanket claim that secure programs cannot exist. That wasn't even the subject of the discussion.