3 ms·

`gcc` still as bugs. `clang` still has bugs. There was one recently on HN where one pass in clang caused undefined behavior in another. Are these not yet ready

`gcc` still as bugs. `clang` still has bugs. There was one recently on HN where one pass in clang caused undefined behavior in another. Are these not yet ready for prime time? Furthermore, this is a known bug, and not too high priority probably since it's pretty rare to stack allocate something huge and then use it in a way that could cause a vulnerability (instead of crashing). The fix would involve replacing the segfault with a stack overflow, which also causes a crash.

Annatar 11y ago
> `gcc` still as bugs. `clang` still has bugs. There was one recently on HN where one pass in clang caused undefined behavior in another. Are these not yet ready for prime time? I thought Rust was a language billing itself as safe. GCC and Clang are compilers, they have not mounted a campaign to bill themselves as safe, nor are they trying to bill themselves as the best thing since sliced bread.
- Manishearth 11y ago
  Yes, and this is a compiler bug. It is not a bug in the language, and it can be fixed once LLVM gets stack probes for platforms other than Windows (on which it already works). On Windows with rustc you can't cause this issue currently IIRC. (It can be fixed in rustc itself by inserting stack probes on large stack allocations, but it won't be able to catch cases where LLVM moves things around and in the process creates a new large stack allocation; i.e. after tons of inlining) Ultimately, it's very hard to weaponize a segfault caused by a stack overflow (and causing a segfault through a guard-page-skipping overflow itself is a rare thing), so as far as practical aspects are concerned, this doesn't really matter. Like everyone has said so far, it's a bug, a bug which can and will be fixed.
- dbaupp 11y ago
  In this case, it's not actually that much of a bug: the segfault is entirely controlled. Threads' stacks are allocated with a guard page at the end that is marked as inaccessible (at the OS level), so any access---read or write---will make the OS kill the process, via a segfault. This particular type of segfault differs to typical segfaults in other languages because it is guaranteed to happen and guaranteed to be a segfault/kill the program. Segfaults in C code often hint at more serious bugs (e.g. use after free) that can be exploited for remote code execution etc. The bug is that the stack overflow detection isn't perfect: if writes to particularly large stack frames happen in just the wrong way, then a program can write beyond the guard page instead of being killed. This is obviously unfortunate, and the fix is ensuring LLVM has support for stack problems on all platforms (it currently has them on Windows).

Annatar 11y ago

> `gcc` still as bugs. `clang` still has bugs. There was one recently on HN where one pass in clang caused undefined behavior in another. Are these not yet ready for prime time? I thought Rust was a language billing itself as safe. GCC and Clang are compilers, they have not mounted a campaign to bill themselves as safe, nor are they trying to bill themselves as the best thing since sliced bread.

Manishearth 11y ago
Yes, and this is a compiler bug. It is not a bug in the language, and it can be fixed once LLVM gets stack probes for platforms other than Windows (on which it already works). On Windows with rustc you can't cause this issue currently IIRC. (It can be fixed in rustc itself by inserting stack probes on large stack allocations, but it won't be able to catch cases where LLVM moves things around and in the process creates a new large stack allocation; i.e. after tons of inlining) Ultimately, it's very hard to weaponize a segfault caused by a stack overflow (and causing a segfault through a guard-page-skipping overflow itself is a rare thing), so as far as practical aspects are concerned, this doesn't really matter. Like everyone has said so far, it's a bug, a bug which can and will be fixed.
dbaupp 11y ago
In this case, it's not actually that much of a bug: the segfault is entirely controlled. Threads' stacks are allocated with a guard page at the end that is marked as inaccessible (at the OS level), so any access---read or write---will make the OS kill the process, via a segfault. This particular type of segfault differs to typical segfaults in other languages because it is guaranteed to happen and guaranteed to be a segfault/kill the program. Segfaults in C code often hint at more serious bugs (e.g. use after free) that can be exploited for remote code execution etc. The bug is that the stack overflow detection isn't perfect: if writes to particularly large stack frames happen in just the wrong way, then a program can write beyond the guard page instead of being killed. This is obviously unfortunate, and the fix is ensuring LLVM has support for stack problems on all platforms (it currently has them on Windows).