Date: Sat, 30 Jan 2021 16:01:34 +0000
Am Samstag, den 30.01.2021, 16:27 +0100 schrieb Corentin via Liaison:
> On Sat, Jan 30, 2021 at 4:19 PM Arvid Norberg via Liaison <
> liaison_at_[hidden]> wrote:
>
> > On Sat, Jan 30, 2021 at 2:56 PM Uecker, Martin via Liaison <
> > liaison_at_[hidden]> wrote:
> >
...
>
> It is probably a stupid question, but, do we not that that VLAs in C++
> could lead to additional security issues and vulnerabilities caused by hard
> to handle stack overflows?
Hard to handle stack overflows are also caused by function calls
and large objects on the stack. This needs a more generic
solution (maybe annotations for compile-time guarantees on
stack usage). For VLAs there is also some existing compiler
support to prevent this.
When talking about this issue, it is often overlooked that the
alternative to placing the VLA on the stack is to place a larger
fixed size array on the stack. This will use more stack not
less.
The other common misconception is that VLAs need to be on
the stack.
Best,
Martin
> On Sat, Jan 30, 2021 at 4:19 PM Arvid Norberg via Liaison <
> liaison_at_[hidden]> wrote:
>
> > On Sat, Jan 30, 2021 at 2:56 PM Uecker, Martin via Liaison <
> > liaison_at_[hidden]> wrote:
> >
...
>
> It is probably a stupid question, but, do we not that that VLAs in C++
> could lead to additional security issues and vulnerabilities caused by hard
> to handle stack overflows?
Hard to handle stack overflows are also caused by function calls
and large objects on the stack. This needs a more generic
solution (maybe annotations for compile-time guarantees on
stack usage). For VLAs there is also some existing compiler
support to prevent this.
When talking about this issue, it is often overlooked that the
alternative to placing the VLA on the stack is to place a larger
fixed size array on the stack. This will use more stack not
less.
The other common misconception is that VLAs need to be on
the stack.
Best,
Martin
Received on 2021-01-30 10:01:40