On Fri, Jun 08, 2018 at 07:57:22AM -0700, Andy Lutomirski wrote:

On Fri, Jun 8, 2018 at 5:24 AM H.J. Lu [off-list ref] wrote:

quoted

On Thu, Jun 7, 2018 at 9:38 PM, Andy Lutomirski [off-list ref] wrote:

quoted

On Thu, Jun 7, 2018 at 9:10 PM H.J. Lu [off-list ref] wrote:

quoted

On Thu, Jun 7, 2018 at 4:01 PM, Andy Lutomirski [off-list ref] wrote:

By the time malicious code issue its own syscalls, you've already lost
the battle.  I could probably be convinced that a lock-CET-on feature
that applies *only* to the calling thread and is not inherited by
clone() is a decent idea, but I'd want to see someone who understands
the state of the art in exploit design justify it.  You're also going
to need to figure out how to make CRIU work if you allow locking CET
on.

A priori, I think we should just not provide a lock mechanism.

We need a door for CET.  But it is a very bad idea to leave it open
all the time.  I don't know much about CRIU,  If it is Checkpoint/Restore
In Userspace.  Can you free any application with AVX512 on AVX512
machine and restore it on non-AVX512 machine?

Presumably not -- if the program uses AVX512 and AVX512 goes away,
then the program won't be happy.

Yes. In most scenarios we require the fpu capability to be the same
on both machines (in case of migration) or/and not being changed
between c/r cycles.
...

As an aside, where are the latest CET docs?  I've found the "CET
technology preview 2.0", but it doesn't seem to be very clear or
entirely complete.

+1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html