Memory safety

Mlibu

Hi there, I am developing a potentially secure app and so I have been paying attention to all the concern about memory safety and Rust etc etc. C++ is not a 'memory safe' language of course because it is a low level language and just doesn't care what you do. But could Qt itself be considered memory safe assuming the developer doesn't fall into any dangling pointer traps and always uses QObject handling etc?

Pl45m4

@Mlibu said in Memory safety:

But could Qt itself be considered memory safe assuming the developer doesn't fall into any dangling pointer traps and always uses QObject handling etc?

No.
Qt is a GUI Framework in/for C++.

Yes, there is a QObject object tree which includes parent/child relations, so child-QObjects are destroyed, when the parent is, but you can still do the same random stuff and leak memory as everywhere else.

Mlibu

@Pl45m4 But I specifically asked if it was memory safe if you didn't do the 'same random stuff'.

JonB

@Mlibu
@Pl45m4's answer is correct. If you write perfect C++ code with Qt it will be memory safe. But then that's true without Qt. Qt is of course written in C++ and has the concomitant risks. QObject hierarchies help a bit, though you can certainly abuse that and cause memory access errors if you fail to use it correctly, but object handling is only one part of Qt. You can assume that Qt code is well tested and any internal problems addressed promptly. But it's just a C++ library.

SimonSchroeder

I'll answer in two parts: Part 1 is about modern C++ and Part 2 is about Qt which does not work well with Part 1.

In modern C++ the general rule is to never use new (or its C cousin malloc()) directly. Stick to the C++ core guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) on how to use pointers properly. Purposefully use owner, not_null, span, unique_ptr, shared_ptr, and references (e.g., see rules F.7 and F.22-F.27 of the guidelines). Some of these are taken from the GSL (guideline support library). In many cases you can create objects on the stack directly (no pointers involved!). If you can, do it! If you need a unique or shared pointer always use make_unique or make_shared and never new to avoid some corner cases. If you are interfacing with plain old C and have C++23 available, consider using out_ptr and inout_ptr as well. Basically, all these rules for modern C++ boil down to: Never use a plain pointers to imply ownership and never use plain new (or malloc).

However, Qt is much older than modern C++. Not all Qt classes inherit QObject. When using classes like QVector and QString all the above still applies. But, using classes derived from QObject you must use new. A few QObjects can be allocated on the stack or using plain C++ smart pointers. One example would be your main window which most of the time should be on the stack. Doing proper layouts with widgets always reparents them and thus automatically deletes them. If you consistently stick to this (and if Qt is entirely bug-free in this area) you will not have any memory leaks. Since in any Qt code you'll be using containers and strings you need to have two separate rules inside your head at all times: one set of rules for general C++ and another set for QObject-derived classes. Adding the human element into this, I would claim that Qt is not memory safe. I assume that there will be good tools in the future to check for the core guidelines, but there won't be good tools for checking Qt's memory handling at the same time.

That being said: if you are writing a secure app and you are aware of the pitfalls, you might be able to perfectly juggle the two sets of rules. I expect programmers to be more careful when writing critical applications.

JonB

@SimonSchroeder , @Mlibu

void Class::foo()
{
    QObject obj1;
    QObject obj2;
    obj1.setParent(&obj2);
}

or

Class::QTimer timer;
void Class::foo()
{
    int i = 10;
    connect(&this->timer, &QTimer::timeout, this, [&]() { i++; qDebug() << i; } );
    timer.start(100);
}

or

QImage *Class::foo()
{
    uchar data[width * height];
    QImage *image = new QImage(data, width, height, QImage::Format_ARGB32);
    return image;
}

or

// build for Release
QList<int> list;
list[1000] = 10;
qDebug() << list[1000];

All witnessed (and many others) in Qt code written by people. How memory safe are these?

Mlibu

@JonB Ok so I guess the general answer from the crowd is that there is no way to 'just' use Qt so you have to be aware of everything else anyway. And that C++ is just as safe as Rust provided you follow all best practices.

I did C++ a very long time ago (trained in C), though I have done everything else since but it has been a long time since I have been this low level. It seems like there is a set of rules that you need to make sure you go by and then you are good. Or else there are analysis tools to detect memory leaks. Or do I have this wrong?

I am aware of most of the pitfalls, and yes I understand now that not all Qt objects are QObjects (shout out to KDAB) and also referencing and de-referencing is now bad. I am interested in doing it the right way, or at least being very cautious. Or is it just better to use Rust?

And thank you for the information by the way.

JonB

@Mlibu said in Memory safety:

And that C++ is just as safe as Rust provided you follow all best practices.

I didn't say that. I said if you write "perfect" C++ code it might be as safe. Not just "best practice". By which I meant it doesn't happen.

I am no fan of Rust, I haven't even used it. I don't know what the requirements are for "a potentially secure app". But if "memory safety" were my top priority I would prefer Rust over C++. And there is no current Rust binding of Qt. If it's not "top priority" then obviously Qt has a lot else to offer. And there must be a hell of a lot of C++ programs out there which are considered "secure".

As an aside, it might even turn out that the Python/PySide binding of Qt is technically more "memory safe" than the base C++ one. That has a layer of Python memory management on top of it, hopefully to "protect" you. Not that I would recommend actually doing this, and I can't believe it would be good for a "secure" app, but just musing.

Mlibu

@JonB Actually I have been reading that Python is considered memory safe which surprised me. Unfortunately Python is just too slow for backing a user interface.

If i used rust it would be handling most of the secure parts and pass through a layer of c++ for the qt bindings. But i haven't really thought that out too far.

You already gave me the real answer i was looking for anyway. People use Qt/C++ for secure applications and it turns out just fine. That says it for me i think.

Mlibu

@Mlibu After reading about all of the issues, I have come to the conclusion that the whole memory safety issue is overblown. Hire programmers that know what they are doing down to the very system level and give them time to do their work and you won't have these problems.

Giving everyone training wheels because some kids are falling over is a stupid way to solve the problem. Just train people properly, pay them well to do their jobs, and memory safety becomes a nonissue.

jeremy_k

@Mlibu said in Memory safety:

@Mlibu After reading about all of the issues, I have come to the conclusion that the whole memory safety issue is overblown. Hire programmers that know what they are doing down to the very system level and give them time to do their work and you won't have these problems.

Giving everyone training wheels because some kids are falling over is a stupid way to solve the problem. Just train people properly, pay them well to do their jobs, and memory safety becomes a nonissue.

In theory*, yes. In practice, safety and correctness is hard. I naively presumed that this was the source of the inquiry. Guard rails, whether technical or philosophical, can make it easier to make reasonable choices.

One of those guard rails that is generally taken for granted is virtual memory and memory protection. Most software runs in an environment where reading or writing arbitrary locations is inhibited. I don't think many people would dream of throwing that away to avoid page fault overhead.

* - still a work in progress?

Mlibu

@jeremy_k Yeah it is something I hadn't really thought about until these articles started coming out. Thanks for the insight.

SimonSchroeder

@JonB said in Memory safety:

All witnessed (and many others) in Qt code written by people. How memory safe are these?

Oh well, these are bad. This stems from a lack of understanding of C++ or Qt (especially the first one is related to Qt only).

@Mlibu said in Memory safety:

Or is it just better to use Rust?

Disclaimer: I'm a C++ guy; I'm following Rust; but I haven't used Rust. There have been recent discussions that Rust does not have a widely adapted GUI library. You would have to write your software using at least two programming languages (as you have mentioned in one of your posts). I don't think this is a very good idea. If you want a secure application you need programmers that know all of the intricacies of the programming language(s), that know all of the pitfalls. Have you seen Java programmers write C++? Have you seen C programmers write C++? It is not the best and/or safest C++ code around (in general). They bring their concepts and ideas they have internalized over many years and try to apply them to C++. How would that be different if you take a C++ programmer and have him write Rust code? You would need an experienced Rust programmer for the secure parts of the apps and an experienced C++ programmer for the GUI (if you are using Qt). Most of the time this is not the same person.

I have heard that Rust does not play too well with libraries written in other languages. A lot of times you'll access them through a non-secure part of code. C++ has interfacing with C libraries (and a lot of libraries are written in C/have a C API) in mind. The recent addition of out_ptr and inout_ptr shows that. I expect this to be a lot safer in C++ than in Rust. (Back to the disclaimer: I don't know Rust.)

@Mlibu said in Memory safety:

People use Qt/C++ for secure applications and it turns out just fine.

C++ is used in automotive and medical applications. So, yes it is possible to write secure applications. If you want to get really secure there is the MISRA coding guidelines for these kinds of applications (haven't checked them out myself).

Asperamanca

@Mlibu said in Memory safety:

Hi there, I am developing a potentially secure app and so I have been paying attention to all the concern about memory safety and Rust etc etc. C++ is not a 'memory safe' language of course because it is a low level language and just doesn't care what you do. But could Qt itself be considered memory safe assuming the developer doesn't fall into any dangling pointer traps and always uses QObject handling etc?

First off, safety and security are not the same.
In very short, security protects against tampering (=intentionally caused harm), while safety more generally ensures an application will not cause harm. In that way, you must include security when achieving safety, but you can be secure without being safe.

Second, memory safety is only a part of the story. If this is the point you want to focus on in this thread, that's fine - I just want to point out there are other aspects to consider.

If you write "potentially secure app" - what does that mean? If you guarantee a level of safety or security, that usually means fulfilling some kind of norm or passing a conformance test. Such a norm or test protocol may give you a hint on what requirements are being put on language and libraries.

Mlibu

@Asperamanca Fair enough. What I mean that is I am interested in memory safety for the reason that it eliminates a lot of attack vectors which are a security vulnerability. I don't necessarily care about the fact that it prevents bugs because I can test for those. I just want to make sure that I have done a reasonably thorough investigation on how to make an application as tight as possible. But from what I have seen on the internet, there are a few things to worry about but nothing that is an incredible chore or particularly devious.

Maybe I am ignorant. In all honesty I have never done any development with a group bigger than myself. But from the very first time I heard that a buffer overflow causes a security concern I wondered why those developers didn't just make a class that manages a C/C++ array in the most anal and safe way possible and just use that. Replace every instance of any variable def with [*] with it.

Same with links. If you want to have to have a link to a string and a corresponding read link, make a class that contains the source link with all referencing link and make sure the class has a solid lifecycle that ends the links properly. You could even use the SOLID principle and make a class for SourceString and for ReadString and bring them together in a SafeString or something.

Don't people just do these things?

Asperamanca

@Mlibu
I think the following factors come into play:

Some people have old code, and they need to interface with it.
Some people learned programming 20 years ago. They consider themselves pros, and don't need to learn new things. Why use fancy new std::span, when I can just as well use a pointer and a size_t?
Sometimes, you have to interface with a low-level API, and need raw pointers and stuff for that
Using e.g. algorithms instead of raw loops takes a lot of time to get used to

So, sometimes you just have to do the dirty stuff. Sometimes you just don't know better.

You might find some useful material here: Papers and Presentations by Sean Parent
Particularly, "All the safeties"

Asperamanca

@Mlibu
I can also recommend JF Bastien's C++now 2023 keynote on safety and security

And about Qt specifically:

Implicit sharing offers a good model to build value type trees, that allow you to treat your whole project data as a value
Qt is used in the automotive industry, which is naturally safety-affine

SimonSchroeder

@Mlibu said in Memory safety:

I just want to make sure that I have done a reasonably thorough investigation on how to make an application as tight as possible.

That is a good idea and totally possible. Just a few years back (2023 or 2022?) the US government declared C/C++ to not be a memory safe language. Bjarne Stroustrup has taken this upon himself to defend C++ from these allegations. There is no language called C/C++. There is only C and C++. And what holds true of C does not necessarily hold true of C++. Maybe have a look at Bjarne's talks from the last two years. You might find something interesting concerning memory safety in C++. (Mostly he is pushing for C++ profiles that have different defaults than now or that forbid certain old code that might be problematic. Basically, like Rust has an "unsafe" mode you could turn on a "safe" profile in C++. Let's hope that this will come eventually. Another way would be Herb Sutter's new C++ syntax with cppfront. This would make it easier right now to write memory safe applications (though there is no guarantee that this syntax will continue to exist in the future, but you can always translate the new syntax to code using current C++ syntax).)

SimonSchroeder

Coincidentally, today my colleague sent me a Google paper about memory safety in C++: https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/