From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 00:59:01 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E09106566B; Thu, 16 Jun 2011 00:59:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9838FC1A; Thu, 16 Jun 2011 00:59:00 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p5G0wtX0003294; Wed, 15 Jun 2011 18:58:56 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4DF951E3.7010209@freebsd.org> Date: Wed, 15 Jun 2011 18:58:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110614161105.GA17306@onelab2.iet.unipi.it> <4A46AC77-BEE5-4401-8896-4E4F1A5304B0@samsco.org> <4DF951E3.7010209@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Luigi Rizzo , "K. Macy" , current@FreeBSD.org Subject: Re: fast/syscall-free gettimeofday ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 00:59:01 -0000 On Jun 15, 2011, at 6:44 PM, Julian Elischer wrote: >> If this was to be extended with cached global syscall information = like gettimeofday, would we want that to be in a separate page that is = marked non-executable? Is there any way to trick the kernel into = leaking arbitrary (and thus executable) code? Also, would it matter for = jails? Per-process info like getpid would obviously have to be a = separate per-process page. >>=20 >> Scott >>=20 > In the talk about this sort of topic I have seen mention at various = times > of a page per system, a page per jail, a page per process and a page = per thread. >=20 > I'm not saying we want this all just that I've seen it mentionned.. >=20 > The per-thread one is the most intersting to do challenge wise. I guess that per-thread would be done via a pointer off of the TLS data, = or would it be yet another bumping of the stack? It would be = interesting to see how expensive it is to go that direction. Scott