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

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

441–450 of 504 posts

Re: Getting Past C

#441

Post by pjmlp »

falcolas wrote: post #9
jerf wrote: post #6

Earlier quoted context omitted.

In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so. Also, it has been suggested by some experiences that o…

Well, it's not just older architectures which are not currently supported, it's architectures used in IOT devices, mainframes, and other non-commodity hardware. Specific to LLVM based languages, if it's not a priority to Apple (or the other big LLVM players), it infrequently gets done. Specific to IOT devices, I would personally love to see secure everyting . NTP, TLS, SSH, etc.

We are getting some piece of it with companies that still sell safe system programming languages (e.g. MikroElektronika, Astrobe), expose mostly via Java or its variants (e.g. Oracle, Aicas, Aonix, IBM, IS2T, Google), .NET (Microsoft).

Re: Getting Past C

#442

Post by awinter-py »

Manishearth wrote: post #378
steveklabnik wrote: post #349

Earlier quoted context omitted.

Close, but not quite: unless the type is NonZero, you need space for the tag. c-style unions are in nightly behind a flag; they're not stable yet.

I think they meant that the use case corresponds closely, not the representation. Generally C unions get used the same place Rust unions would in a rust program (not vice versa though), unless they're being used for type punning, which is pretty rare anyway.

I meant if you have a large program where many types are C unions like:

    struct TaggedUnion {
        enum {T1, T2} type_id;
        union {type1 t1; type2 t2;} u;
    }
If the goal is to translate automatically to a rust enum declaration, that will be (a) possible to do with an automatic tool and (b) will give enhanced safety because it will force the type to be checked everywhere these values are used.

Re: Getting Past C

#443

Post by rat87 »

MaulingMonkey wrote: post #328
scott_karana wrote: post #249

Earlier quoted context omitted.

Hate to tell you, but JavaScript implementations virtually all rely on C or C++ as well. And it's not limited to the VM itself: check out npm "native extensions" like `json`. Not to mention glibc, or the OSes themselves. By your definition, nothing is safe. And you're right ;)

I'm aware. I note that Firefox is using some Rust code now - so perhaps that will change at some point, for at least one of the common JavaScript implementations, in the not too distant future. I don't imagine we'll see it for the majority within the decade - but who knows, maybe I'll be pleasantly surprised. I have less hope for the widespread adoption of OS kernels written in safer languages - given the general unw…

> I note that Firefox is using some Rust code now - so perhaps that will change at some point, for at least one of the common JavaScript implementations, in the not too distant future. I don't imagine we'll see it for the majority within the decade - but who knows, maybe I'll be pleasantly surprised.

Maybe

I think currently there's no plan for it. Maybe after they finish servo to the degree where it supports all modern html features

Re: Getting Past C

#444

Post by MaulingMonkey »

pjmlp wrote: post #434
ue_ wrote: post #419

Earlier quoted context omitted.

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

Safety has to do with memory corruption that lead to security exploits and unrecoverable data, not panics.

Panics can be a vector for denial-of-service attacks. OTOH that's still better than remote-code-execution, and unwinding panics can be caught. OTOH I see failing to do so across a FFI boundary is UB, which could get back into RCE territory through sufficiently convoluted shenanigans...

Re: Getting Past C

#445

Post by jjnoakes »

ue_ wrote: post #419
kqr wrote: post #392

Earlier quoted context omitted.

> I work on a C codebase that does this […]. Yes, there is quite a lot of NIH. With essentially-uniform use of checked data structures, and an extremely comprehensive suite of automated tests getting run under ASAN (originally Valgrind) […]. This is a complex, >1M SLOC distributed system that has seen several years of production use at this point […]. > > […] it just needs to be done from the start, and then you just…

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

What do you expect a language to do if you index an array using a runtime-calculated value?

Rust checks at runtime and panics if your program exceeds the bounds. You can opt-in to asking if the bounds are exceeded and fail gracefully if you like, or if you want to promise the compiler you know for sure your bounds are tight, you can use unsafe blocks and act like C. Opt-in to danger.

C lets you do it with no checks. You have to opt in to the safe path of checking and failing. You don't automatically segfault if you exceed the bounds; instead you read arbitrary memory. Welcome to the land of undefined behavior. You may crash, but more likely, you will read some value from an unexpected place, and carry on executing incorrectly for who knows how long. Opt-in to safety.

That's what people mean by Rust is safe by default. And that's just bounds checks. Carry that notion over to pointers, references, threads, lifetimes, ...

What ever made you think "Safe Rust" meant "compile time checks of runtime values are possible" or "C is just as safe because it lets you index outside an array"?

Re: Getting Past C

#446

Post by MaulingMonkey »

jjnoakes wrote: post #445
ue_ wrote: post #419

Earlier quoted context omitted.

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

What do you expect a language to do if you index an array using a runtime-calculated value? Rust checks at runtime and panics if your program exceeds the bounds. You can opt-in to asking if the bounds are exceeded and fail gracefully if you like, or if you want to promise the compiler you know for sure your bounds are tight, you can use unsafe blocks and act like C. Opt-in to danger. C lets you do it with no checks.…

> What do you expect a language to do if you index an array using a runtime-calculated value?

Optimizers already try to prove index bounds to eliminate unnecessary checks, and static analysis tools to demand necessary checks. Turning the latter into compile time errors is a reasonable approach if your language can provide sufficient information to deal with false positives - likely by forcing you to add your own bounds checking to explicitly handle out-of-bounds cases.

A language John Carmack was using or researching at one point comes to mind, which had this kind of thing going on IIRC. I'm afraid I can't find it off hand, so I might recall in error.

Re: Getting Past C

#447

Post by ue_ »

jjnoakes wrote: post #445
ue_ wrote: post #419

Earlier quoted context omitted.

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe. Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

What do you expect a language to do if you index an array using a runtime-calculated value? Rust checks at runtime and panics if your program exceeds the bounds. You can opt-in to asking if the bounds are exceeded and fail gracefully if you like, or if you want to promise the compiler you know for sure your bounds are tight, you can use unsafe blocks and act like C. Opt-in to danger. C lets you do it with no checks.…

>You don't automatically segfault if you exceed the bounds; instead you read arbitrary memory.

GCC and clang both have sanitizers either built in or available for them. Sure, it's not default, but let's not act like there is no choice in C but to account for every OOB access while programming or to read memory you don't want to.

Furthermore, I never said that compile time checks of variables are possible, but rather we could move to using dependent typing, or at least a way to judge whether a variable would work as a subscript based on the type of the array and variable.

The Rust designers didn't do that. Instead they put in a feature common in the two most popular C compilers to "panic" at runtime instead of accessing memory. That's nothing. It's rubbish. And if you know to "catch" the panic, why don't you check the value of what you're subscripting with? Saying you can catch the panic is missing the point of unintentional OOB accesses, which is that they're unintentional.

C is just as safe with regard to OOB accessing, and to be honest that's pretty poor in 2017.

Re: Getting Past C

#448

Post by EugeneOZ »

cesarb wrote: post #425
EugeneOZ wrote: post #415

Earlier quoted context omitted.

You still think in C limits of possibilities. Rust could just return Option as a result for [x] syntax.

And then people would simply call .unwrap() on the return of the [] operator, leading to the same situation. It's extremely common for an array dereference to always be within the bounds, by code construction (I'm iterating over the indexes of the array, or I have an index into the array saved inside some other structure, and so on). The programmer knows it will never be out of bounds. The assert!() within the [] ope…

There is HUGE difference between "unwrap" (which can found by grep) and mutual dangerous behavior. Programmer can only assume, not know, without additional checks. "Polluting with error" is much better than panicking.

Re: Getting Past C

#449

Post by nsuser2 »

amadvance wrote: post #404

Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security. It doesn't have to deal with 40 years of bad legacy code written by sloppy developers. You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't ev…

> And Rust doesn't help in this regard.

From: https://doc.rust-lang.org/nomicon/races.html

Data races are mostly prevented through rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits (see https://doc.rust-lang.org/nomicon/races.html).

Re: Getting Past C

#450

Post by arunmu »

Manishearth wrote: post #390
arunmu wrote: post #384

Earlier quoted context omitted.

> Moves are runtime moves, so you can still attempt to access the value at compile time. What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ? Then yes, it is a possible scenario for error but also a performance advantage in some cases.

> What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ? You can still access a value after it has been moved out. use-after-move is allowed by the compiler. It places (stdlib) types in an unspecified but valid state (I've seen C++ code reusing these types and assuming that the state after move is something in particular -- it's not). Most optimizations you can do by reusing…

> Most optimizations you can do by reusing a moved value could be done automatically by the compiler

Not if constructing the object is costly. It is very well possible for an object not to have a default constructor.

Post reply on HN