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 <hjl.tools@xxxxxxxxx> wrote: > > > > On Thu, Jun 7, 2018 at 9:38 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > On Thu, Jun 7, 2018 at 9:10 PM H.J. Lu <hjl.tools@xxxxxxxxx> wrote: > > >> > > >> On Thu, Jun 7, 2018 at 4:01 PM, Andy Lutomirski <luto@xxxxxxxxxx> 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
