April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote: > On Fri, 11 Apr 2014 08:35:07 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote: > >> "Steven Schveighoffer" wrote in message news:op.xd3vzecweav7ka@stevens-macbook-pro.local... >> >>> No, the author of the @safe code expects bounds checking, it's part of the requirements. To compile his code with it off is like having >>> -compilergeneratedhash switch that overrides any toHash functions with a compiler generated one. You are changing the agreement between the compiler and the code. When I say @safe, I mean "I absolutely always want bounds checks." >> >> If you have code that would ever fail a bounds check, that is a program error, similar to code that may fail an assertion. >> >> And like assertions, if you would rather the code was as fast as possible instead of as safe as possible you can use a compiler switch to disable bound checks. >> >> The usual switch to do stuff like this is '-release', but because @safe functions should still have the 'no memory corruption' even in release mode, disabling those bounds checks was moved into another compiler switch. >> >>> If you want to eliminate bounds checks, use @trusted. >> >> No, @trusted means "don't check my code" while @safe + noboundschecks means (mostly) "only check my code at compile-time". > > Here is the horror scenario I envision: > > 1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?) > 2. They find that performance is lacking, maybe compared to a competitor's C++ based code. > 3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one). > 4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize. > 5. Buffer overflow attacks abound. > 6. D @safe is labeled a "joke" More likely: 6. This company's programming department is labeled a "joke". > There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. We have array.ptr[idx] |
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tommi | On Fri, 11 Apr 2014 09:35:12 -0400, Tommi <tommitissari@hotmail.com> wrote: > On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote: >> Here is the horror scenario I envision: >> >> 1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?) >> 2. They find that performance is lacking, maybe compared to a competitor's C++ based code. >> 3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one). >> 4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize. >> 5. Buffer overflow attacks abound. >> 6. D @safe is labeled a "joke" > > More likely: > 6. This company's programming department is labeled a "joke". Perhaps, but it doesn't change the idea that @safe code had memory bugs. What we are saying with @safe is that you CAN'T have memory bugs, no matter how incompetent your programmers are. >> There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. > > We have array.ptr[idx] Not allowed in @safe code. -Steve |
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | "Steven Schveighoffer" wrote in message news:op.xd5lomc1eav7ka@stevens-macbook-pro.local... > Here is the horror scenario I envision: > > 1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?) > 2. They find that performance is lacking, maybe compared to a competitor's C++ based code. > 3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one). > 4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize. > 5. Buffer overflow attacks abound. > 6. D @safe is labeled a "joke" Trying to prevent developer stupidity is a lost cause. Bounds checks are on by default. They are even on when you ask for 'fast-over-safe' aka -release. They get turned off when you explicitly ask for it. > But there is a cost, even to labeling the "one inner" function @trusted. Perhaps that function is extremely long and complex. There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. All other safety checks are really static, this is the only runtime penalty for safety. Something like (() @trusted => arr.ptr[index]) should do the trick. > The blunt flag approach is scary. @trusted is better, in that you can focus on one function at a time. But I think we need something more precise. Perhaps you should be able to have @trusted scopes, or @trusted expressions. @trusted delegates get you 99.99% of the way there. |
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Friday, 11 April 2014 at 13:44:09 UTC, Steven Schveighoffer wrote: > On Fri, 11 Apr 2014 09:35:12 -0400, Tommi <tommitissari@hotmail.com> wrote: > >> On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote: >>> [..] >>> 6. D @safe is labeled a "joke" >> >> More likely: >> 6. This company's programming department is labeled a "joke". > > Perhaps, but it doesn't change the idea that @safe code had memory bugs. What we are saying with @safe is that you CAN'T have memory bugs, no matter how incompetent your programmers are. You can't gurantee @safe to be memory-safe in the general case without disallowing calls to @trusted, because those incompenent programmers can write buggy @trusted functions and call them from @safe code. >>> There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. >> >> We have array.ptr[idx] > > Not allowed in @safe code. @trusted ref T unsafeIndex(T)(T[] array, ulong idx) { return array.ptr[idx]; } There you go. |
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On Friday, 11 April 2014 at 14:06:33 UTC, Daniel Murphy wrote:
> Trying to prevent developer stupidity is a lost cause.
>
> Bounds checks are on by default. They are even on when you ask for 'fast-over-safe' aka -release. They get turned off when you explicitly ask for it.
>
>> But there is a cost, even to labeling the "one inner" function @trusted. Perhaps that function is extremely long and complex. There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. All other safety checks are really static, this is the only runtime penalty for safety.
>
> Something like (() @trusted => arr.ptr[index]) should do the trick.
>
>> The blunt flag approach is scary. @trusted is better, in that you can focus on one function at a time. But I think we need something more precise. Perhaps you should be able to have @trusted scopes, or @trusted expressions.
>
> @trusted delegates get you 99.99% of the way there.
Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
@trusted
{
arr.ptr[index]
}
Could be lowered to (() @trusted => arr.ptr[index]).
|
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>
> @trusted
> {
> arr.ptr[index]
> }
>
> Could be lowered to (() @trusted => arr.ptr[index]).
I think it was rejected for the very reason that it gives nothing over writing this:
() @trusted
{
arr.ptr[index];
}();
It has resulted in some changes by Kenji though that guarantee that immediately-called delegate is always inlined. Hope those were merged.
|
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Friday, 11 April 2014 at 15:43:16 UTC, Dicebot wrote:
> On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
>> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>>
>> @trusted
>> {
>> arr.ptr[index]
>> }
>>
>> Could be lowered to (() @trusted => arr.ptr[index]).
>
> I think it was rejected for the very reason that it gives nothing over writing this:
>
> () @trusted
> {
> arr.ptr[index];
> }();
>
> It has resulted in some changes by Kenji though that guarantee that immediately-called delegate is always inlined. Hope those were merged.
Besides the fact that it's incredibly ugly.
|
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On Friday, 11 April 2014 at 15:45:41 UTC, Meta wrote:
> Besides the fact that it's incredibly ugly.
Which is not enough for introduction of any single new feature at current stage.
|
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Fri, 11 Apr 2014 11:43:15 -0400, Dicebot <public@dicebot.lv> wrote:
> On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
>> Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe:
>>
>> @trusted
>> {
>> arr.ptr[index]
>> }
>>
>> Could be lowered to (() @trusted => arr.ptr[index]).
>
> I think it was rejected for the very reason that it gives nothing over writing this:
>
> () @trusted
> {
> arr.ptr[index];
> }();
>
> It has resulted in some changes by Kenji though that guarantee that immediately-called delegate is always inlined. Hope those were merged.
If this works as seamlessly as a statement, that is a reasonable solution.
Re: ugliness, it's not important. These are not common situations.
-Steve
|
April 11, 2014 Re: A serious security bug... caused by no bounds checking. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | "Meta" wrote in message news:brrbqfpkfkevxbseoxiq@forum.dlang.org... > Hasn't there been a proposal before to allow @system/@trusted/@safe blocks, allowing it to be a bit more granular than at the function level? Maybe: > > @trusted > { > arr.ptr[index] > } > > Could be lowered to (() @trusted => arr.ptr[index]). It's a little prettier, but less powerful and not really something that _should_ be pretty. |
Copyright © 1999-2021 by the D Language Foundation