Date: Sun, 12 Feb 2023 13:20:47 -0500
On 2/12/23 13:03, Jens Maurer wrote:
>
>
> On 12/02/2023 18.50, Phil Bouchard wrote:
>> On 2/12/23 12:44, Jens Maurer wrote:
>>> Beyond that, different people in the committee have different opinions
>>> what is in-scope for that portability goal and what isn't.
>>>
>>> Oh, and I don't know what you mean by "perfectly robust".
>>
>> Perfectly robust means to drop cybersecurity issues related to memory
>> allocation issues which is currently 70% down to 0% just by using the
>> cutting edge standards.
>
> Could you please elaborate on that with more details?
>
> How, exactly, should the standard be changed to reach that goal, and why
> do you believe such a change would fix all "cybersecurity" issues related
> to memory allocation? A pointer to some paper describing (and delineating)
> the security issues you refer to would be most welcome.
Not only using low-level memory allocation functions but higher-level
memory managers such as RootPtr I already mentioned before which would
fix everything else but would require a major overhaul of C++ to
integrate such memory manager. It would also open the doors to other
intermediate solutions as well, not only for RootPtr, but for solutions
such as run-time backtraces, etc.
But anyways let's first start with low-level allocation routines then we
can move on. First things first.
I need to run now for a bit but I'll follow up later.
> Thanks,
> Jens
>
>
>
> On 12/02/2023 18.50, Phil Bouchard wrote:
>> On 2/12/23 12:44, Jens Maurer wrote:
>>> Beyond that, different people in the committee have different opinions
>>> what is in-scope for that portability goal and what isn't.
>>>
>>> Oh, and I don't know what you mean by "perfectly robust".
>>
>> Perfectly robust means to drop cybersecurity issues related to memory
>> allocation issues which is currently 70% down to 0% just by using the
>> cutting edge standards.
>
> Could you please elaborate on that with more details?
>
> How, exactly, should the standard be changed to reach that goal, and why
> do you believe such a change would fix all "cybersecurity" issues related
> to memory allocation? A pointer to some paper describing (and delineating)
> the security issues you refer to would be most welcome.
Not only using low-level memory allocation functions but higher-level
memory managers such as RootPtr I already mentioned before which would
fix everything else but would require a major overhaul of C++ to
integrate such memory manager. It would also open the doors to other
intermediate solutions as well, not only for RootPtr, but for solutions
such as run-time backtraces, etc.
But anyways let's first start with low-level allocation routines then we
can move on. First things first.
I need to run now for a bit but I'll follow up later.
> Thanks,
> Jens
>
-- 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.
Received on 2023-02-12 18:20:49