linux-kernel - Re: disabling group leader perf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100908014409.GA17010@brick.ozlabs.ibm.com>
Date:	Wed, 8 Sep 2010 11:44:09 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>, Pekka Enberg <penberg@...helsinki.fi>,
	Tom Zanussi <tzanussi@...il.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-perf-users@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: disabling group leader perf_event

On Tue, Sep 07, 2010 at 05:44:17AM +0200, Ingo Molnar wrote:

> No, it's machine code. It's 'safe x86 bytecode executed natively by the 
> kernel as a function'.

I'm curious - how are you going to prove that addresses for the MOV
instruction are safe, using just a static pre-execution scan of the
code?  If you only allow things that you can prove are safe, then
either you'll have a very large and complex verifier, or you'll end up
disallowing interesting and useful cases.

The other alternative is to do runtime verification of addressses,
which is much more straightforward (and it's also much easier to prove
it's secure).  But it does mean that you can't run the code as-is.

> It needs a verification pass (because the code can come from untrusted 
> apps) so that we can copy, verify and trust it (so obviously it's not 
> _arbitrary_ x86 machine code - a safe subset of x86) - maybe with a sha1 
> based cache for already-verified snippets (or a fast verifier).
> 
> > x86 is quite unpleasant.
> 
> Any machine code that is fast and compact is unpleasant almost by 
> definition: it's a rather non-obvious Huffman encoding embedded in an 
> instruction architecture.

>From the point of view of having to emulate or translate x86 code (as
we would have to do on powerpc), it's not the compactness that's
unpleasant, it's things like not being able to tell whether the
condition codes set by an instruction are ever going to be used.  Many
x86 instructions set the condition codes but for most instructions the
condition codes that are set are never used.  So when emulating or
translating, you either waste time computing condition code values
that are never used, or you have to do complex lifetime analysis to
work out which instructions do need to compute the condition codes.

> We start with trivial (and useless) special case of something like:
> 
> #define MAX_BYTECODE_SIZE 256
> 
> int x86_bytecode_verify(char *opcodes, unsigned int len)
> {
> 
> 	if (len-1 > MAX_BYTECODE_SIZE-1)
> 		return -EINVAL;
> 
> 	if (opcodes[0] != 0xc3) /* RET instruction */
> 		return -EINVAL;
> 
> 	return 0;
> }
> 
> ... and then we add checks for accepted/safe x86 patterns of 
> instructions step by step - always keeping it 100% correct.

So... I would be interested to see you add the case for the MOV
instruction. :)

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/