On 2/12/23 11:55, Jason McKesson via Std-Proposals wrote:
>>
>> My goal here is to find solutions to problems; not to find problems to
>> solutions.
>
> If you want a solution to be accepted by others, it needs to not have
> problems. I always thought that went without saying.

Again virtual operator new() and virtual operator delete() would
definitely fix the problem. But that would require a universal root
class similar to std::exception:

namespace std
{

class allocator
{
     static inline allocator _singleton;

protected:
     virtual allocator * singleton()
     {
         return & _singleton;
     }

public:
     virtual void * operator new (size_t s);
     virtual void operator delete (void *);

     friend void * std::operator new (size_t s); // global overrides
     friend void ::operator delete (void *);
};

inline void * operator new (size_t s)
{
     return allocator::singleton()->operator new (s);
}

inline void operator delete (void * p)
{
     allocator::singleton()->operator delete (p);
}

}

...

namespace MyApplication
{

class MyAllocator : std::allocator
{
     static inline MyAllocator _singleton;

protected:
     virtual MyAllocator * singleton()
     {
         return & _singleton;
     }

public:
     virtual void * operator new (size_t s); // replaces std::allocator
     virtual void operator delete (void *);
};

}

Sorry for the confusion.

>> Memory allocations are a huge cybersecurity problem (70%) and needs to
>> be fixed at all layers, starting with core allocations routines. That's
>> an undeniable fact.
>
> This is the first time you've mentioned "cybersecurity" as a
> justification. So which is it? Do you want this because
> "RtlAllocateHeap() and RtlFreeHeap() aren't reliable in extensive
> multithreading usages?" Or do you want it for "cybersecurity" reasons?

Cybersecurity includes erasing memory buffers after usages as well, not
only buffer overflows and all those.

I'm making cybersecurity part of the conversation because I'm looking
for perfection here which would solve a huge part of the existing problems.

> Also, is `RtlAllocateHeap`, or memory allocation functions in general,
> a point of attack for hackers? Sure, memory allocation is a security
> issue, but my understanding is that this usually manifests in how the
> allocated memory gets *used* (buffer overruns and the like), not the
> allocation functions themselves. But maybe I'm wrong; if it's such an
> "undeniable fact", then it should be pretty easy to cite some
> examples.
>
> And it would also be useful to explain how being able to swap the
> allocator would fix those examples.
>
> If you want people to buy into your solutions, you first need to
> explain what specific problems your solution intends to solve. And
> when someone questions a problem you cite, jumping to a different
> problem makes it seem like you're just trying to find some
> justification for a solution you've already decided is good.

I did not expand on all factors initially because I wasn't prepared to
answer all your questions but this problem is mostly cumulative over my
23 years of experience in the industry so I simply forgot to mention
cybersecurity in the first place.


Thanks,

-- 
Logo <https://www.fornux.com/>  
*Phil Bouchard*  facebook icon
<https://www.linkedin.com/in/phil-bouchard-5723a910/> 
CTO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
documents l'accompagnant, sont destinés uniquement aux personnes
identifiées et peuvent contenir des informations privilégiées,
confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named
recipients only and may contain privileged or confidential information
which is not to be disclosed. If you received this communication by
mistake please destroy all copies.