Date: Sat, 25 Apr 2020 02:28:04 +0200
On Sat, Apr 25, 2020 at 1:21 AM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
>
> I'm strongly opposed to adding such facilities without
> changing the abstract machine description in the core
> language section. Some hand-waving in the library
> section is not enough.
Please describe precisely why the "hand-waving" would not be enough.
Pointers to standing, official policies would be very welcome. In
particular, note that subjective claims about "purity", "beauty", etc.
of the abstract machine should not be part of the discussion.
On this subject, note that ISO's goal is to develop "market relevant
standards" that "provide solutions to global challenges" in the
industry, not to do PL/CS research. If someone has the will,
knowledge, time and resources to craft wording changes to the abstract
machine that are concise/simple enough to warrant the complexity
increase, I am sure they will be very welcome and agreed upon by
everyone. Otherwise, please do not delay standardization of a
practical solution of what the industry already does today and needs
yesterday.
> Since secure_clear takes trivially copyable arguments,
> the compiler is free to make arbitrary additional copies
> on the stack, in registers, or elsewhere. Clearing
> just one of the instances is not enough to achieve the
> stated use-cases of this function.
I suggest you read the proposal again.
The proposal nowhere claims to clear stack, registers, extra copies or
anything like that. In fact, it enumerates such issues (and more).
However, as the proposal explains, that is out of scope given current
implementations and usage in well-known systems do not attempt to
solve them. When they do, we should indeed talk about standardizing
that too.
> A security feature
> that doesn't reliably deliver should not exist in the
> first place.
Then none of the projects out there are "reliably delivering", either.
Yet it is what they all do and what should be standardized. If you
think those projects are in the wrong, then please take it up with
them, not with WG21.
Also please note that, as the proposal explains, *not* having this in
the standard has already caused actual bugs in the wild. If we have
had the solution already in the standard, those would have been
prevented.
Cheers,
Miguel
>
> I'm strongly opposed to adding such facilities without
> changing the abstract machine description in the core
> language section. Some hand-waving in the library
> section is not enough.
Please describe precisely why the "hand-waving" would not be enough.
Pointers to standing, official policies would be very welcome. In
particular, note that subjective claims about "purity", "beauty", etc.
of the abstract machine should not be part of the discussion.
On this subject, note that ISO's goal is to develop "market relevant
standards" that "provide solutions to global challenges" in the
industry, not to do PL/CS research. If someone has the will,
knowledge, time and resources to craft wording changes to the abstract
machine that are concise/simple enough to warrant the complexity
increase, I am sure they will be very welcome and agreed upon by
everyone. Otherwise, please do not delay standardization of a
practical solution of what the industry already does today and needs
yesterday.
> Since secure_clear takes trivially copyable arguments,
> the compiler is free to make arbitrary additional copies
> on the stack, in registers, or elsewhere. Clearing
> just one of the instances is not enough to achieve the
> stated use-cases of this function.
I suggest you read the proposal again.
The proposal nowhere claims to clear stack, registers, extra copies or
anything like that. In fact, it enumerates such issues (and more).
However, as the proposal explains, that is out of scope given current
implementations and usage in well-known systems do not attempt to
solve them. When they do, we should indeed talk about standardizing
that too.
> A security feature
> that doesn't reliably deliver should not exist in the
> first place.
Then none of the projects out there are "reliably delivering", either.
Yet it is what they all do and what should be standardized. If you
think those projects are in the wrong, then please take it up with
them, not with WG21.
Also please note that, as the proposal explains, *not* having this in
the standard has already caused actual bugs in the wild. If we have
had the solution already in the standard, those would have been
prevented.
Cheers,
Miguel
Received on 2020-04-24 19:31:14