"Users who often read vulnerability reports come across terms over and over again. Terms like buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free --all describe memory safety vulnerabilities.
Speaking at the BlueHat security conference in Israel last week, Microsoft security engineer Matt Miller said that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs."
MiraclePtr< T> to address UseAfterFree bugs in Chrome ā¦
āThe BackupRefPtr algorithm is based on reference counting. It uses support of Chromeās own heap allocator, PartitionAlloc, which carves out a little extra space for a hidden reference count for each allocation.
Raw_ptr< T> increments or decrements the reference count when itās constructed, destroyed or modified.
When the application calls free/delete and the reference count is greater than 0, PartitionAlloc quarantines that memory region instead of immediately releasing it. The memory region is then only made available for reuse once the reference count reaches 0.ā
Surely the only point youāve made from this thread is to show Delphi isnāt memory safe and shouldnāt be on the list. Where Delphi doesnāt typically suffer from buffer overflow bugs (the only reason I can think of for it being on the list) it certainly doesnāt protect from many of the other issues like use after free etc
Some basic changes to the language like automatically initialising local variables would go a long way to helping make things much safer.
Agree, in so far as I donāt understand the reasons it ended up in the list. My de facto position before any of this came up was that OP is a nicer, more elegant, less spiky C++. So it was a surprise to me, as I said, to see it there.
That said, people put effort into these reports. Someone had reasons for making that evaluation, so we should probably figure out explicitly the pros and cons for our language in this context. AND create and promote guidelines for how to best utilise it for a certain level of āsafeā outcome.
Also ā¦ hopefully, between this in the news,
and the efforts updating the C++Builder product line, Embarcadero will be energised to put new development attention into our favourite language.
The advertising has been done, essentially.
We have a chance to try to live up to it.
The link above about MiraclePtr suggests eg that maybe FastMM could be modified to do something similar.
@GrahameDGrieve already gave us a presentation that involved him doing his own memory manager. Maybe we need another talk on that subject.
The link above about MiraclePtr suggests eg that maybe FastMM could be modified to do something similar.
There is a great feature in C++Builder called CodeGuard which has been there for 25-odd years (but seems to be a bit flakey in recent times and now requires not using runtime libraries, I havenāt used it for a long time) that can catch a lot of memory safety issues. Using it does affect runtime performance but it can be enabled/disabled.
FastMM does some of those things, but others are very hard indeed for a memory manager to do. Or impossible.
I have written my own memory manager, but not anymore - I use fastMM. I do have a base object that does tracking / manual reference counting / debugging leak support, and I have talked a little about this. Iām happy to talk again about it, but itāll have to virtual - Iām on the road for the next 9 months
FastMM does some of those things, but others are very hard indeed for a memory manager to do. Or impossible.
I believe that some of them work as follows (Iād have to check my old article on CodeGuard to see if I knew how they worked back then - my memory manager deallocated that knowledge years ago ):
Access in freed memory: when a block is freed the mm overwrites the block with a pattern and delays actually releasing the memory for a while. Later, when it is time to release the memory it checks that the pattern is still intact and actually releases the memory. If the pattern was modified then an invalid write occurred. This doesnāt catch read access though. This technique detects write access to freed memory if it would have otherwise been reallocated for another purpose
Method called on freed object: Hook all class member functions. When the hook function is called check the implicit Self parameter against valid memory blocks and call the original function
Access overrun (also available in FastMM) and underrun: Add some guard memory to the start and end of each allocated block and fill with a pattern. When the object is freed check that the patterns are still intact. Again, wonāt catch an invalid read
Access uninitialized/invalid stack: Function hooks, check stack pointer and frame have just been initialized, maybe push a pattern on the stack, call the original function, maybe check pattern on return
To help catch access in freed memory immediately, at least where the memory is not reallocated, and to catch reads, you could use something to trigger AVās like the following instead of calling .Free:
procedure FreeAndInvalidate(var Obj);
var
Temp: TObject;
begin
Temp := TObject(Obj);
Pointer(Obj) := $C0FFEE;
Temp.Free;
end;
var o := TThing.Create;
...
FreeAndInvalidate(o);
...
// Access member field or call a method that does = AV: read of address 00C0FFEE
if o.Something = 42 then ...
Calling FreeAndNil() also works but that would get mixed in with āaccess before allocatedā or other uninitialised ref code.
Delphi is usually pretty good at warning about uninitialised variables.
I will just add an appropriate var := value; statement, even when (rarely) I think it has it wrong.
Sometimes annoying when a newer version of the compiler warns that the initialisation value is not usedā¦ What to do then? Probably just leave it in, with a comment.
):
