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

size_t-to-int vulnerability in Linux’s filesystem layer

openwall.com

Post reply on HN
Print view View original

71–80 of 280 posts

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#71

Post by CuriousCosmic »

tialaramex wrote: post #58
derefr wrote: post #32

Earlier quoted context omitted.

> Some Rust developers argue that even "size as i32" should be avoided, and "size.try_into()" should be used instead, since it forces the programmer to treat an overflow explicitly at runtime, instead of silently wrapping. It's important to still have the option for efficient truncating semantics, though; some software (e.g. emulators) needs to chunk large integers into 2/4/8 smaller ones, and rotation + truncating a…

Right, this is a small infelicity in Rust, it is easier to write let x = size as i32; ... even if what you meant was closer to let x: i32 = size.try_into().expect("We are 100% sure size is small enough to fit into x"); But at least it isn't C or C++ where you might accidentally write x = size; ... and the compiler doesn't even warn you that size is bigger than x and you need to think about what you intended. It's rea…

It can impact compile time performance but Boost Safe Numerics provides some nice wrappers to prevent narrowing (or restrict it to specific classes of narrowing) and throw warnings or errors at compile time similar to what you see in Rust.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#72

Post by simias »

dkirill wrote: post #63
tialaramex wrote: post #58

Earlier quoted context omitted.

Right, this is a small infelicity in Rust, it is easier to write let x = size as i32; ... even if what you meant was closer to let x: i32 = size.try_into().expect("We are 100% sure size is small enough to fit into x"); But at least it isn't C or C++ where you might accidentally write x = size; ... and the compiler doesn't even warn you that size is bigger than x and you need to think about what you intended. It's rea…

> and the compiler doesn't even warn you that size is bigger than x That's not true tho, compiler with reasonable flags set will definitely warn you and if you really don't like this kind of code you can force compiler to issue an error instead

What flags you have in mind? Because this code doesn't generate any warning with GCC 11.1.0 with -Wall -Wextra:

    int main(void) {
        int some_int = 1234567;
        char c = some_int;

        return c;
    }

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#73

Post by vbezhenar »

OnlyLys wrote: post #48
gruez wrote: post #41

Earlier quoted context omitted.

>that can grow like in js I thought js "integers" are just floating point numbers?

I believe the poster you were replying to was talking about JS's new `BigInt` type. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Good example of that feature is Python. Also, AFAIR, Scheme (and probably some other lisps) support it.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#74

Post by [deleted] »

derefr wrote: post #62
londons_explore wrote: post #46

Earlier quoted context omitted.

It would be nice if CPU's had an instruction for "read the low 8 bits of this register, and require the high bits all be zeros (otherwise throw an exception)". Then safety is free...

What does "otherwise throw an exception" mean at the CPU level? I know Erlang's BEAM VM has a "fail jump pointer register", where instructions that can fail have relative-jump offsets encoded as immediates for those instructions, and if the instruction "fails" in whatever semantic sense, it takes the jump. But most CPUs don't have anything like that. Would you want it to trap, like with integer division by zero? CPU…

[deleted]

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#75

Post by simias »

derefr wrote: post #62
londons_explore wrote: post #46

Earlier quoted context omitted.

It would be nice if CPU's had an instruction for "read the low 8 bits of this register, and require the high bits all be zeros (otherwise throw an exception)". Then safety is free...

What does "otherwise throw an exception" mean at the CPU level? I know Erlang's BEAM VM has a "fail jump pointer register", where instructions that can fail have relative-jump offsets encoded as immediates for those instructions, and if the instruction "fails" in whatever semantic sense, it takes the jump. But most CPUs don't have anything like that. Would you want it to trap, like with integer division by zero? CPU…

I assume they meant throwing an exception like divisions by zero usually do, i.e. a hardware trap.

I always thought that overflows should be checked in hardware, I suppose it's not a stretch to extend that to truncation. It's controversial though, and obviously mostly a thought experiment anyway unless we manage to convince some CPU manufacturer to extend their ISA that way.

MIPS does have (optional) trapping overflow on signed add/sub overflow, so at least there's a small precedent for it.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#76

Post by ridiculous_fish »

simias wrote: post #72
dkirill wrote: post #63

Earlier quoted context omitted.

> and the compiler doesn't even warn you that size is bigger than x That's not true tho, compiler with reasonable flags set will definitely warn you and if you really don't like this kind of code you can force compiler to issue an error instead

What flags you have in mind? Because this code doesn't generate any warning with GCC 11.1.0 with -Wall -Wextra: int main(void) { int some_int = 1234567; char c = some_int; return c; }

-Wconversion will do it.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#77

Post by masklinn »

ridiculous_fish wrote: post #36
est31 wrote: post #26

Earlier quoted context omitted.

Rust doesn't allow them either: https://play.rust-lang.org/?version=stable&mode=debug&editio... Adding .into() works though, which is the recommended method if the conversion can be statically guaranteed (otherwise try_into should be used, which will become easier in the 2021 edition as the TryInto trait will become part of the prelude).

into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-us...

> It's rather frustrating in practice.

All explicit conversions, more so fallible, are "frustrating in practice" especially when coming from a language without those foibles.

But given the semantics of usize/isize, it is perfectly reasonable, nay, a good thing, that they're considered neither widenings nor narrowings of other numeric types.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#78

Post by eloff »

dathinab wrote: post #65
derefr wrote: post #32

Earlier quoted context omitted.

> Some Rust developers argue that even "size as i32" should be avoided, and "size.try_into()" should be used instead, since it forces the programmer to treat an overflow explicitly at runtime, instead of silently wrapping. It's important to still have the option for efficient truncating semantics, though; some software (e.g. emulators) needs to chunk large integers into 2/4/8 smaller ones, and rotation + truncating a…

As a interesting side note: The "as" operator is often considered to have been a mistake. Both because of unchecked casts and because of "doing to much". So I wouldn't be surprised if in the (very) long term there will be a rust edition deprecating `as` casts (after we have alternatives to all cast done with `as`, which are: Pointer casts, dyn casts/explicit coercion and truncating integer casts, for some we already…

I would prefer not to see that happen, I'm fine with as and the safer options as they are currently. It would be a big job to update all the code in the wild when you want to move to the newer edition.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#80

Post by ridiculous_fish »

simias wrote: post #75
derefr wrote: post #62

Earlier quoted context omitted.

What does "otherwise throw an exception" mean at the CPU level? I know Erlang's BEAM VM has a "fail jump pointer register", where instructions that can fail have relative-jump offsets encoded as immediates for those instructions, and if the instruction "fails" in whatever semantic sense, it takes the jump. But most CPUs don't have anything like that. Would you want it to trap, like with integer division by zero? CPU…

I assume they meant throwing an exception like divisions by zero usually do, i.e. a hardware trap. I always thought that overflows should be checked in hardware, I suppose it's not a stretch to extend that to truncation. It's controversial though, and obviously mostly a thought experiment anyway unless we manage to convince some CPU manufacturer to extend their ISA that way. MIPS does have (optional) trapping overflo…

Swift checks all arithmetic by default: https://swift.godbolt.org/z/rW614G5aq

It seems obvious that future Apple CPUs will have hardware support for this, if they don't already.

Post reply on HN