Post by Miguel OjedaHi Florian,
For your second point, I didn't think about it yet. So I didn't take it into consideration when I proposed the [[undead]] attribute. But if your goal is security, then you would also need to take into consideration this.
Let's imagine an attribute [[secret]].
Every object marked as [[secret]] will be cleaned before function exit.
This cleaning means set to zero every location that still contains the object (known to the compiler).
This sounds very similar to secure_val, but as a variable attribute.
Yes it is similar. But I think attribute is more appropriate because those security issues are not about C++: in order to read a destroyed value, you need to use undefined behavior somehow.
I am not sure what you mean by "are not about C++" or by "reading a
destroyed value". Do you mean you want to have compiler support so
that other languages (like C) can take advantage of it?
Note that there are C++-only attributes; and that, anyway, it would be
nice to have a concrete use case (e.g. secure_val) where such features
could be used.
Post by Miguel OjedaAlso, in order to not deduce the secret from other temporaries, any value depending on a [[secret]] object is also marked implicitly as [[secret]].
This does not address cache persistency, but it can be covered if the [[secret]] can take an optional argument to ensure cache lines related to this object are flushed (done by the compiler).
With this, you start to have a pretty strong security plan for stack objects. But the heap objects cannot be marked as secret. So for that, maybe you could mark the delete statement as [[secret]] and let the compiler do the same thing for heap objects.
I would say users should not care where or how the value is stored.
Having to mark delete statements with an attribute seems odd.
The problem is, when you create an object on the heap, on don't really own the object. that's why it needs a special treatment.
Maybe marking the pointer type as [[secret]] could solve the issue.
Yes, exactly, that is why secure_val is a template: in my view, it has
to be applied the type; not on statements (Daniel's original proposal)
or variables (your initial [[secret]] proposal). If you create a type
attribute, then it could be used itself to implement (part of)
secure_val.
If you delete a [[secret]] pointer, then the compiler needs to ensure every location is cleaned afterwards.
Post by Miguel OjedaAs a
user, I would simply prefer to be able to mark my type T with
[[secret]] and then *that* could be put into the heap. That is the
reason I went for a template, because it looked natural to wrap values
std::secure_val<int> my_very_secret_number;
std::secure_val<char [N]> my_private_key;
etc.
The problem with your template approach is: you don't have the cascade of the secret property, so temporaries depending on your secure_val will not be cleaned.
It depends. Note that the accesses to the secret value must go through
access(). This is intended so that code inside that block may be
treated specially by the compiler. The examples given in the proposal
about how this can be used are encryption (compiler support not needed
in principle), disabling speculation (compiler support needed), etc.
Also, your template is not safely implementable in C++: you need cooperation from the compiler in the same way as with the attribute, because of the possible mutliple locations of your object.
Of course it isn't, that is the whole point of secure_val. :-)
Let me put it this way: I would love secure_val to be implementable in
C++ (or at least part of it, e.g. the auto-clear [[secret]] part that
you are discussing). However, it is not clear yet how many things we
would need to add to the language or how. Some things, like
Spectre-class vulnerabilities, are still being researched. Therefore,
I suggested secure_val first to make the most common use case
concrete, and at the same time give developers a simple solution to
it. Since secure_val does not force almost anything on the vendors
(except the auto-clear), it can be updated to provide further
guarantees as time goes on.
Cheers,
Miguel
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72mHdtv1H87QQWjRQzAa_BkCgr4SU9C2iOr7aJxGJJqf%2Bw%40mail.gmail.com.