Am Donnerstag, dem 02.05.2024 um 18:34 +0100 schrieb Jonathan Wakely via Liaison:
>
>
> On Thu, 2 May 2024 at 18:29, Jonathan Wakely <cxx_at_[hidden]> wrote:
> >
> >
> > On Thu, 2 May 2024 at 18:11, Jens Maurer <jens.maurer_at_[hidden]> wrote:
> > >
> > >
> > > On 26/01/2024 13.29, Jonathan Wakely via Liaison wrote:
> > > > - memset_explicit
> > > > I assume we want this.
> > >
> > > I can't see how to specify these effects in the C++ abstract machine.
> > > If your array goes out-of-scope after the memset, there's no way to
> > > normatively prevent the dead-store elimination.
> > >
> >
> >
> > What about defining it in terms of writes to volatile objects?
> >
>
>
> That isn't even a terrible abuse of volatile semantics, because the observable side effects of writing to that memory really do matter. The entire purpose is to ensure that any secrets in
> those memory locations are not visible if there are reads that happen outside the abstract machine (e.g. reading those bytes after the object has gone out of scope, because exploit code
> doesn't care about our stinking "rules" and whether such reads would be undefined). Volatile semantics seem quite appropriate for writes that are non-elidable side effects and reads that
> happen outside the abstract machine.

The two problems we discussed for C were

1. even when we require those stores (I see no problem there),
it is difficult to make sure that the information does not
leak in a different way, e.g. because registers or other
stack area are not cleared. WG14 was content with making the
intent clear.

2. if there is UB afterwards then the extreme interpretation
of UB (which WG14 later rejected) makes the complete program have
no meaning.


Martin


>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2024/05/1395.php