lkml.org 
[lkml]   [2010]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disabling group leader perf_event
> 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


\
 
 \ /
  Last update: 2010-09-07 17:39    [W:0.081 / U:46.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site