Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Rust Guidelines

anssi-fr.github.io

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Secure Rust Guidelines

#11

Post by masklinn »

heavenlyblue wrote: post #9
masklinn wrote: post #7

Earlier quoted context omitted.

> First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option . emphasis mine > Also, in rust if we don't want to panic we need to never use array indexing and…

What do you do when your algorithm works with array indexing and you are never supposed to handle than None within the Option? Ie if you have indexed array out of bounds that’s a developer’s mistake and not a “condition to be handled up the stack”. It’s ok to panic if you agree that it’s better to panic rather than end up in a state that will probably cause even more issues down the line

> What do you do when your algorithm works with array indexing and you are never supposed to handle than None within the Option?

That's where the first clause comes into play:

> Array indexing must be properly tested

Although

> Ie if you have indexed array out of bounds that’s a developer’s mistake

Which developer would be my question.

If it's the person who reified the "algorithm [which] works with array indexing" then fair's fair, it's a bug in the implementation and should not happen, which is why the guideline specifically says:

> should never use functions or instructions that can fail and cause the code to panic

which, assuming the word is used in the RFC 2119 sense means there can be case where calling panic-ing functions is the right thing to do.

If it's the developer who calls the function implementing the algorithm, then either algorithm is failable (and thus so's the function) or the algorithm should take in more specific data structures which statically exclude failing cases. For instance `max` on an empty collection will fail, so either `max` should be failable (which e.g. `Iterator::max` is) or it should only be callable on some sort of `NonEmpty*`.

Re: Secure Rust Guidelines

#12

Post by masklinn »

gardaani wrote: post #10

I'm having problems fulfilling this requirement in my libs: "Crates providing libraries should never use functions or instructions that can fail and cause the code to panic." The Rust standard library Vec, HashMap etc. can cause a panic in Rust, if the device (such as a mobile phone with a small memory) runs out of memory. C and C++ standard libraries (malloc, std::vector, std::map..) can handle those situations by r…

Yes that is one of the primary failures of Rust at the moment: to my knowledge it currently has no good way to safely manage allocation failures (it also has serious issues with stack overflows).

This is an issue with all heap-allocating construct, not just collections but also Box or Rc.

> I wish Rust had some easy way to recover from out-of-memory situations when using the standard library. I have been considering writing my own out-of-memory safe Vec, HashMap etc, but it can't be the right way to do it..

Maybe look at the embedded space there? There might be no_std third-party libraries which handle these issues. Possibly on top of alloc as the (unstable[0] and obviously unsafe) `Alloc` trait does have a concept of allocation failure.

[0] https://github.com/rust-lang/rust/issues/32838

Re: Secure Rust Guidelines

#13

Post by gardaani »

masklinn wrote: post #12
gardaani wrote: post #10

I'm having problems fulfilling this requirement in my libs: "Crates providing libraries should never use functions or instructions that can fail and cause the code to panic." The Rust standard library Vec, HashMap etc. can cause a panic in Rust, if the device (such as a mobile phone with a small memory) runs out of memory. C and C++ standard libraries (malloc, std::vector, std::map..) can handle those situations by r…

Yes that is one of the primary failures of Rust at the moment: to my knowledge it currently has no good way to safely manage allocation failures (it also has serious issues with stack overflows). This is an issue with all heap-allocating construct, not just collections but also Box or Rc. > I wish Rust had some easy way to recover from out-of-memory situations when using the standard library. I have been considering…

Actually, I have found FallibleVec written by Mozilla [1] but I haven't found anything for other containers, yet.

[1] https://github.com/mozilla/mp4parse_fallible

Re: Secure Rust Guidelines

#14

Post by steveklabnik »

masklinn wrote: post #12
gardaani wrote: post #10

I'm having problems fulfilling this requirement in my libs: "Crates providing libraries should never use functions or instructions that can fail and cause the code to panic." The Rust standard library Vec, HashMap etc. can cause a panic in Rust, if the device (such as a mobile phone with a small memory) runs out of memory. C and C++ standard libraries (malloc, std::vector, std::map..) can handle those situations by r…

Yes that is one of the primary failures of Rust at the moment: to my knowledge it currently has no good way to safely manage allocation failures (it also has serious issues with stack overflows). This is an issue with all heap-allocating construct, not just collections but also Box or Rc. > I wish Rust had some easy way to recover from out-of-memory situations when using the standard library. I have been considering…

> Yes that is one of the primary failures of Rust at the moment: to my knowledge it currently has no good way to safely manage allocation failures

So, sort of yes and sort of no.

The data structures that allocate in the standard library do not let you handle allocation failure. However, if you write your own, the global allocator lets you determine if failure happened, and then you can do whatever you want with it.

Re: Secure Rust Guidelines

#15

Post by SkyMarshal »

masklinn wrote: post #7
CJefferson wrote: post #5

I personally strongly disagree with: Functions or instructions that can cause the code to panic at runtime must not be used. First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". Personally, I often write panicing code -- if the code gets in a state where I have no idea how to fix it, I panic. F…

> First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option . emphasis mine > Also, in rust if we don't want to panic we need to never use array indexing and…

You're skipping half the recommendation though:

> Array indexing must be properly tested, or the get method should be used to return an Option.

Fwiw, for anyone who’s dabbled with Haskell this is SOP. Any result that could be undefined is returned as a Maybe (Haskell’s version of Option). If this seems odd to anyone, understanding it in Haskell will probably help understand it better in Rust too:

http://learnyouahaskell.com/a-fistful-of-monads#getting-our-...

https://en.wikibooks.org/wiki/Haskell/Understanding_monads/M...

Re: Secure Rust Guidelines

#16

Post by geofft »

SkyMarshal wrote: post #15
masklinn wrote: post #7

Earlier quoted context omitted.

> First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option . emphasis mine > Also, in rust if we don't want to panic we need to never use array indexing and…

You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option. Fwiw, for anyone who’s dabbled with Haskell this is SOP. Any result that could be undefined is returned as a Maybe (Haskell’s version of Option). If this seems odd to anyone, understanding it in Haskell will probably help understand it better in Rust too: http://learnyouahask…

Er, don't Haskell's head and (!!) functions default to throwing an exception?

    $ ghci
    Prelude> let a = [3, 4, 5]
    Prelude> a !! 0
    3
    Prelude> a !! 3
    *** Exception: Prelude.(!!): index too large
    
    Prelude> head []
    *** Exception: Prelude.head: empty list
I don't think Haskell is really different from Rust in this respect. Both have a wrapper type for optional values with good syntax, but in both, there's still some syntax so common operations sometimes choose to skip it.

In fact, Hoogle doesn't seem to find me a function like Rust's .get() in the standard library, just a handful of third-party packages: https://hoogle.haskell.org/?hoogle=%5Ba%5D+-%3E+Int+-%3E+May...

Re: Secure Rust Guidelines

#17

Post by jeadfa »

SkyMarshal wrote: post #15
masklinn wrote: post #7

Earlier quoted context omitted.

> First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option . emphasis mine > Also, in rust if we don't want to panic we need to never use array indexing and…

You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option. Fwiw, for anyone who’s dabbled with Haskell this is SOP. Any result that could be undefined is returned as a Maybe (Haskell’s version of Option). If this seems odd to anyone, understanding it in Haskell will probably help understand it better in Rust too: http://learnyouahask…

The Travelers Talk – Getting Your Travel Information ... https://thetravelerstalk.com/

Re: Secure Rust Guidelines

#18

Post by Cyph0n »

gardaani wrote: post #10

I'm having problems fulfilling this requirement in my libs: "Crates providing libraries should never use functions or instructions that can fail and cause the code to panic." The Rust standard library Vec, HashMap etc. can cause a panic in Rust, if the device (such as a mobile phone with a small memory) runs out of memory. C and C++ standard libraries (malloc, std::vector, std::map..) can handle those situations by r…

Oh, I never even considered this... But how would Rust ever be able to signal allocation failures in such cases?

Re: Secure Rust Guidelines

#19

Post by rectang »

steveklabnik wrote: post #14
masklinn wrote: post #12

Earlier quoted context omitted.

Yes that is one of the primary failures of Rust at the moment: to my knowledge it currently has no good way to safely manage allocation failures (it also has serious issues with stack overflows). This is an issue with all heap-allocating construct, not just collections but also Box or Rc. > I wish Rust had some easy way to recover from out-of-memory situations when using the standard library. I have been considering…

> Yes that is one of the primary failures of Rust at the moment: to my knowledge it currently has no good way to safely manage allocation failures So, sort of yes and sort of no. The data structures that allocate in the standard library do not let you handle allocation failure. However, if you write your own, the global allocator lets you determine if failure happened, and then you can do whatever you want with it.

I think Rust got it right, here.

Dealing with allocation failure gracefully is hard and requires a lot of extra code.

For most applications the best default is to panic and handle it up the stack rather than pay the programming overhead of handling allocation failure explicitly in every last nook and cranny. The Rust standard library rightly optimizes for this use case.

For the embedded or critical-safety application spaces, where you really do want to handle allocation failure gracefully, you need something other than the standard library. Letting that "something" develop slowly out in the community is a good call.

Re: Secure Rust Guidelines

#20

Post by EvilTerran »

geofft wrote: post #16
SkyMarshal wrote: post #15

Earlier quoted context omitted.

You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option. Fwiw, for anyone who’s dabbled with Haskell this is SOP. Any result that could be undefined is returned as a Maybe (Haskell’s version of Option). If this seems odd to anyone, understanding it in Haskell will probably help understand it better in Rust too: http://learnyouahask…

Er, don't Haskell's head and (!!) functions default to throwing an exception? $ ghci Prelude> let a = [3, 4, 5] Prelude> a !! 0 3 Prelude> a !! 3 *** Exception: Prelude.(!!): index too large Prelude> head [] *** Exception: Prelude.head: empty list I don't think Haskell is really different from Rust in this respect. Both have a wrapper type for optional values with good syntax, but in both, there's still some syntax s…

> Hoogle doesn't seem to find me a function like Rust's .get() in the standard library

In practice, you don't really need one - the safe alternative to "xs !! n" is pattern-matching on the result of "drop n xs", as that's [] if xs has ≤n elements:

https://www.haskell.org/onlinereport/standard-prelude.html#$...

Post reply on HN