Re: disabling group leader perf_event

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> Safety of #1 (x86 bytecode passed in by untrusted user-space, verified 
> and saved by the kernel and executed natively as an x86 function if it 
> passes the security checks) is trivial but obviously needs quite a bit 
> of work.

Hardly trivial - and it will always be buggy.

As well as the fact your interpreter is going to have bugs its also no
longer portable. If you have a sane input code and verify that then
compile it you get portability and verifiability.

> > Can you point me to any research?
> 
> Nope, havent seen this 'safe native x86 bytecode' idea 
> mentioned/researched anywhere yet.

Its been done as a linux arch experiment using a trusted assembler.

> I think some Java-like bytecode is roughly the same amount of conceptual 
> work as an x86 bytecode verifier, with the big disadvantage that even 
> with a JIT it's much slower [and a JIT is far from simple] - not to 
> mention the non-technical complications of Java.

The Java JIT is horrible. A better intermediate with compiler available
looks more promising. How about the qemu or valgrind intermediates ?

> 
> > I have a truly marvellous patch that fixes the bug which this 
> > signature is too narrow to contain.
> 
> Make sure you write down a short but buggy version of the patch on the 
> margin of a book. Pass on the book to your heirs and enjoy the centuries 
> long confusion from the heavens.

I'm sure the perl version will fit ;)

Alan