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

Linux eliminates the strncpy API after six years of work, 360 patches

phoronix.com

Post reply on HN
Print view View original

221–230 of 340 posts

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#221

Post by GabrielTFS »

GTP wrote: post #217

I always thought that srncpy was the safe alternative to strcpy. Now that I think of it, I'm unsure if the NUL terminator is counted into strncpy's size or not, which would be a likely source of errors. But, could someone explain better what the problems were? And also, would have to pick the right function in the list of given alternatives much better?

The issue with strncpy is that it doesn't actually necessarily terminate - in fact in any case where the source is larger than the destination it will just leave it unterminated (like, it will copy the last character it can from the source instead of terminating the destination string with a NUL)

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#222

Post by david-gpu »

anal_reactor wrote: post #192
sirwhinesalot wrote: post #140

I have in the past made fun of the Linux kernel devs, supposedly some of the best C developers in the world, for not knowing how to make stringbuffer and stringview types, but to be fair to them we didn't have the consensus we have today on the topic. You know who did have the right idea though? Dennis Ritchie, who proposed a fat pointer type for C all the way back in 1990. Would have made for a perfect addition to C…

> but to be fair to them we didn't have the consensus we have today on the topic. This is my pet peeve of teamwork. We can choose solutions A, B or C. Each has upsides and downsides. We debate for two weeks, then we choose nothing.

Isn't that due to a lack of leadership, rather than a problem with teamwork itself? Somebody has to be ultimately in charge and willing to put a stop to endless debate.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#223

Post by jiggawatts »

layer8 wrote: post #171
mrlonglong wrote: post #2

the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.

There is a middle ground that Visual Basic (and then COM) took, with the BSTR type: It’s still a pointer to a zero-terminated char array, but there is a length field immediately preceding the first pointed-to byte. This is still compatible with a C string (assuming no embedded null characters), but BSTR-typed functions can take advantage of the length value.

These are great for "data smuggling" attacks where one layer of code assumes the length is 'x' and another layer assumes it is 'y'.

It makes hybrids like this very dangerous for anything even remotely security-adjacent, such as roles, tokens, etc.

This kind of thing caused the CVE-2009-2408 and CVE-2009-2510 "Null Truncation in X.509 Common Name Vulnerability."

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#224

Post by crackez »

asdfasgasdgasdg wrote: post #87
smackeyacky wrote: post #80

Earlier quoted context omitted.

Zero terminated strings were the basis for an awful lot of useful software. Calling them the biggest mistake in computing is a bit OTT. I haven’t programmed anything Pascal related for 30+ years but I dimly remember thinking at the time that I wished the string system wasn’t so hard to use.

That useful software would not have been less useful if the strings in it were represented as size + buf.

Oh really? Have you tried to rewrite anything to put your theory to the test? I don't think it's as straight forward as you think it is...

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#225

Post by rurban »

GTP wrote: post #217

I always thought that srncpy was the safe alternative to strcpy. Now that I think of it, I'm unsure if the NUL terminator is counted into strncpy's size or not, which would be a likely source of errors. But, could someone explain better what the problems were? And also, would have to pick the right function in the list of given alternatives much better?

No, the safe alternatives end with _s. They do check matching buffer sizes, and enforce zero-termination. Unfortunately WG14 hates them also, because Microsoft. Microsoft did indeed break some of the, but you can use better alternatives, like my safeclib

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#226

Post by skywhopper »

flohofwoe wrote: post #199
rswail wrote: post #160

Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…

> non UTF-8 encoded strings on input/output UTF-8 on stdin/stdout works perfectly fine (unless you are on Windows of course, which is stuck in in the early 90s when it comes to international text encoding). > Using LF or CR or CRLF as line terminators This is also an operating system convention, and it would be better if programming languages wouldn't try to "guess" the correct line endings, since this causes more pr…

What programming languages try to guess line endings? Or are even aware of them?

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#227

Post by AlienRobot »

lelanthran wrote: post #168
AlienRobot wrote: post #16

Earlier quoted context omitted.

>The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately. That isn't really a problem. The problem with null-terminated strings is specifically what happens when you reach the end of the allocated array and there ISN'T a NULL character. Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of…

> Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of the NULL character, What sort of situation are you envisioning where a hacker can remove the sentinel (in the case of nul-termination) but not modify the length bytes (in the case of fat pointers)?

A situation in which a string is manipulated with buggy code that can remove the sentinel, e.g. the program uses strncpy, there is a bug in how it uses it, the hacker exploits the bug.

By contrast it's pretty unlikely for buggy code to mess the length. Add an element? +1. Remove an element? -1. Number of elements larger than capacity? Allocate a new array. Not much room for error.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#228

Post by codedokode »

rswail wrote: post #160

Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…

> non UTF-8 encoded strings on input/output

I would just use UTF-8 everywhere.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#229

Post by thiht »

> In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies

What a nightmare, does it have to be so convoluted?

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#230

Post by zaik »

twothreeone wrote: post #78

wow, very humbling. I'm actually amazed how many people contributed to this. It's easy to get attribution for "cool new features", but arguable removing bad features is even more important for something as fundamental as the kernel. Cudos! I'm sure these are the sorts of things that will go down as folklore from the "founding ages", when everyone will have forgotten how to understand source code in 50 years and the C…

> everyone will have forgotten how to understand source code in 50 years

I don't think this will happen. Human desire to understand how things work will still be around in 50 years.

Post reply on HN