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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ