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]

Date:	Wed, 8 Sep 2010 08:44:27 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Paul Mackerras <paulus@...ba.org>, 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

* Pekka Enberg <penberg@...nel.org> wrote:

> 2010/9/8 Paul Mackerras <paulus@...ba.org>:
> >> 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. :)
> 
> Heh, which one of them - there are tons of variants under 'mov' on 
> x86? On a more serious note: the biggest problem is that you need to 
> do verification during execution because you don't know the exact 
> address until then for most addressing modes that use registers.

Well, the main model and usecase would be to provide some sort of 
function (in the mathematical sense), which is dependent on fixed-size 
input and stores a fixed-size output somewhere.

For that category to restrict both the input and output space initially, 
wouldnt be a big restriction. I.e. dont allow register addresses, only 
stack addresses or fixed addresses to the user-space parameter space.

These functions are supposed to be short and generally they dont change 
state (they dont have access to locking in any case - we want to be able 
to call them from atomic contexts, etc.).

Thus instructions like 'mov (%rax), ...' would be handled by not 
allowing them, only addresses which do not change from execution state.

That still gives plenty of flexibility to implement filters or other 
kinds of input/output calculation/netfilter-rule kind of logic.

Do you know some interesting usecase that would be excluded via such 
address restrictions? Things like flexible arrays or more complex data 
structures such as trees couldnt be used initially. More complex data 
structures would need locking in any case.

I.e. it would initially be restricted roughly to code where halting can 
be proven. Still looks interesting to me: most netfilter policy rules, 
trace filters or selinux rules could be implemented that way - an order 
of magnitude or two faster than the ad-hoc tracing, avc or iptables rule 
engines ...

Thanks,

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