From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752090AbcKOLPX (ORCPT ); Tue, 15 Nov 2016 06:15:23 -0500 Received: from g2t1383g.austin.hpe.com ([15.233.16.89]:6211 "EHLO g2t1383g.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbcKOLPU (ORCPT ); Tue, 15 Nov 2016 06:15:20 -0500 Subject: Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO) To: Kees Cook References: <20160914071901.8127-1-juerg.haefliger@hpe.com> <20161104144534.14790-1-juerg.haefliger@hpe.com> <20161104144534.14790-2-juerg.haefliger@hpe.com> Cc: LKML , Linux-MM , "kernel-hardening@lists.openwall.com" , linux-x86_64@vger.kernel.org, vpk@cs.columbia.edu From: Juerg Haefliger Message-ID: Date: Tue, 15 Nov 2016 12:15:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MMA5n0WALLx3TQ9tiMHKXcQ7909wPUkXE" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MMA5n0WALLx3TQ9tiMHKXcQ7909wPUkXE Content-Type: multipart/mixed; boundary="Hdqn216xR43vntA6rDQsbXD8mI2B2GFMR"; protected-headers="v1" From: Juerg Haefliger To: Kees Cook Cc: LKML , Linux-MM , "kernel-hardening@lists.openwall.com" , linux-x86_64@vger.kernel.org, vpk@cs.columbia.edu Message-ID: Subject: Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO) References: <20160914071901.8127-1-juerg.haefliger@hpe.com> <20161104144534.14790-1-juerg.haefliger@hpe.com> <20161104144534.14790-2-juerg.haefliger@hpe.com> In-Reply-To: --Hdqn216xR43vntA6rDQsbXD8mI2B2GFMR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for the late reply, I just found your email in my cluttered inbox. On 11/10/2016 08:11 PM, Kees Cook wrote: > On Fri, Nov 4, 2016 at 7:45 AM, Juerg Haefliger wrote: >> This patch adds support for XPFO which protects against 'ret2dir' kern= el >> attacks. The basic idea is to enforce exclusive ownership of page fram= es >> by either the kernel or userspace, unless explicitly requested by the >> kernel. Whenever a page destined for userspace is allocated, it is >> unmapped from physmap (the kernel's page table). When such a page is >> reclaimed from userspace, it is mapped back to physmap. >> >> Additional fields in the page_ext struct are used for XPFO housekeepin= g. >> Specifically two flags to distinguish user vs. kernel pages and to tag= >> unmapped pages and a reference counter to balance kmap/kunmap operatio= ns >> and a lock to serialize access to the XPFO fields. >=20 > Thanks for keeping on this! I'd really like to see it land and then > get more architectures to support it. Good to hear :-) >> Known issues/limitations: >> - Only supports x86-64 (for now) >> - Only supports 4k pages (for now) >> - There are most likely some legitimate uses cases where the kernel = needs >> to access userspace which need to be made XPFO-aware >> - Performance penalty >=20 > In the Kconfig you say "slight", but I'm curious what kinds of > benchmarks you've done and if there's a more specific cost we can > declare, just to give people more of an idea what the hit looks like? > (What workloads would trigger a lot of XPFO unmapping, for example?) That 'slight' wording is based on the performance numbers published in th= e referenced paper. So far I've only run kernel compilation tests. For that workload, the big= performance hit comes from disabling >4k page sizes (around 10%). Adding XPFO on top causes 'only' a= nother 0.5% performance penalty. I'm currently looking into adding support for larger page sizes = to see what the real impact is and then generate some more relevant numbers. =2E..Juerg > Thanks! >=20 > -Kees >=20 --Hdqn216xR43vntA6rDQsbXD8mI2B2GFMR-- --MMA5n0WALLx3TQ9tiMHKXcQ7909wPUkXE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYKu5DAAoJEHVMOpb5+LSMzQ8P+wWBd+Sen2m8U4Q7HjsdGCoB 9fHq5r8x/bt+WvqF2i8vMR5Txrfn/EoOAkxkOu8tYiq7ECnHSnETAR8NVR2ckp0M cizhmBdOiiMcOUiLSnPGxEx9390Qdx5li0ODwqQS5dSa9qCkBbbv6qf7ri5CzDFH VO+OIAHI/kChTi4baKENq3UNHh0+8s/M0dykDwStIjrDG4Nh+IcEWOeDvOBWZ5HG qxZQEg20reipzZTcba7paJ/pJQZBuKg/AFdQW/RFBFK3O0JngWKp67ZmxSU7PHw+ xr9qpKy+N9Yk3q5id7q2f2zA7eq3a3uYTNC+8d7zc6KQJIofnCLX/3dtuIEwS9rR QSxQIPtk2sFmPLy/kXpU2RihdIJijJtx7RmbW7KEiuUMwUO+dDjjwJul9SNxlYWg gYjUxPAGP6jxfGL443YKNbss2e5KfIh6LXlJpbtnD0WEfYiI7Ef2Y2qRrXpCkcw/ Z2kBLojOJOn8HagkHJiiw8lTwgDm2+YNcUWQoDgaTK9xOoAfMssETJfFaiGt6hsG 7VJot9jHg33kSZDyiTVBV6nwmCkOqtgXINYj8Q82iRmWUKPq2VEQEWWlvg31N9eu S1L7EFIaAzZvt+6qc/GCrjjQzgOz+En/UyfmPoojJ+A6dx8/gM6oWkOOZDsG614J 9rFANUbutWyZav73fc/L =Wzyi -----END PGP SIGNATURE----- --MMA5n0WALLx3TQ9tiMHKXcQ7909wPUkXE--