From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752118AbdCMNWd (ORCPT ); Mon, 13 Mar 2017 09:22:33 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:36506 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbdCMNWX (ORCPT ); Mon, 13 Mar 2017 09:22:23 -0400 Date: Mon, 13 Mar 2017 13:21:50 +0000 From: Mark Brown To: Brian Starkey Cc: Benjamin Gaignard , Laura Abbott , Michal Hocko , Sumit Semwal , Riley Andrews , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Rom Lemarchand , devel@driverdev.osuosl.org, Linux Kernel Mailing List , "linaro-mm-sig@lists.linaro.org" , Greg Kroah-Hartman , linux-arm-kernel@lists.infradead.org, "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Daniel Vetter , linux-mm@kvack.org Message-ID: <20170313132150.324h7em7c3iowmwj@sirena.org.uk> References: <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <20170313105433.GA12980@e106950-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jmd3p5wa7z2gqxvc" Content-Disposition: inline In-Reply-To: <20170313105433.GA12980@e106950-lin.cambridge.arm.com> X-Cookie: No shirt, no shoes, no service. User-Agent: NeoMutt/20161126 (1.7.1) X-SA-Exim-Connect-IP: 2001:470:1f1d:6b5::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --jmd3p5wa7z2gqxvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: > On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > > Another point is how can we put secure rules (like selinux policy) on > > heaps since all the allocations > > go to the same device (/dev/ion) ? For example, until now, in Android > > we have to give the same > > access rights to all the process that use ION. > > It will become problem when we will add secure heaps because we won't > > be able to distinguish secure > > processes to standard ones or set specific policy per heaps. > > Maybe I'm wrong here but I have never see selinux policy checking an > > ioctl field but if that > > exist it could be a solution. > I might be thinking of a different type of "secure", but... > Should the security of secure heaps be enforced by OS-level > permissions? I don't know about other architectures, but at least on > arm/arm64 this is enforced in hardware; it doesn't matter who has > access to the ion heap, because only secure devices (or the CPU > running a secure process) is physically able to access the memory > backing the buffer. > In fact, in the use-cases I know of, the process asking for the ion > allocation is not a secure process, and so we wouldn't *want* to > restrict the secure heap to be allocated from only by secure > processes. I think there's an orthogonal level of OS level security that can be applied here - it's reasonable for it to want to say things like "only processes that are supposed to be implementing functionality X should be able to try to allocate memory set aside for that functionality". This mitigates against escallation attacks and so on, it's not really directly related to secure memory as such though. --jmd3p5wa7z2gqxvc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAljGnO0ACgkQJNaLcl1U h9ADTgf/cen1KJxzB5DyzPjdff5+hLmkjHDPrpZVfe7FMCTp8wYRsf1OHGAMsHx0 KsoTEdpQmt6ao4EEQGYPZWs1VSYE12tXejBGQJ0Av8duNXg1BUUUnLJi+xz/sIGb tDX3trnLxByCfqFdZEtXuFpErBUtyt3tv5nrcLYzWFcgWaK+Xuf+5WsPZ4McTJCF KK7j22M9qZ5J/0C/DyTM2H8EaBb6NjSDfDBnydDYCzYrf+YkxwAdcj8qta9toRyV qfBVsD/kkx8dHPPYZG+WXeQCzkQPoluN94P2cN2Ni990mzSAKtgS8maXRJ9MRUBV 5F4uW1syDtEsiZPAdFPeC/ZXISn65g== =C/hC -----END PGP SIGNATURE----- --jmd3p5wa7z2gqxvc-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@kernel.org (Mark Brown) Date: Mon, 13 Mar 2017 13:21:50 +0000 Subject: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging In-Reply-To: <20170313105433.GA12980@e106950-lin.cambridge.arm.com> References: <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <20170313105433.GA12980@e106950-lin.cambridge.arm.com> Message-ID: <20170313132150.324h7em7c3iowmwj@sirena.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: > On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > > Another point is how can we put secure rules (like selinux policy) on > > heaps since all the allocations > > go to the same device (/dev/ion) ? For example, until now, in Android > > we have to give the same > > access rights to all the process that use ION. > > It will become problem when we will add secure heaps because we won't > > be able to distinguish secure > > processes to standard ones or set specific policy per heaps. > > Maybe I'm wrong here but I have never see selinux policy checking an > > ioctl field but if that > > exist it could be a solution. > I might be thinking of a different type of "secure", but... > Should the security of secure heaps be enforced by OS-level > permissions? I don't know about other architectures, but at least on > arm/arm64 this is enforced in hardware; it doesn't matter who has > access to the ion heap, because only secure devices (or the CPU > running a secure process) is physically able to access the memory > backing the buffer. > In fact, in the use-cases I know of, the process asking for the ion > allocation is not a secure process, and so we wouldn't *want* to > restrict the secure heap to be allocated from only by secure > processes. I think there's an orthogonal level of OS level security that can be applied here - it's reasonable for it to want to say things like "only processes that are supposed to be implementing functionality X should be able to try to allocate memory set aside for that functionality". This mitigates against escallation attacks and so on, it's not really directly related to secure memory as such though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Date: Mon, 13 Mar 2017 13:21:50 +0000 Message-ID: <20170313132150.324h7em7c3iowmwj@sirena.org.uk> References: <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <20170313105433.GA12980@e106950-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7224144503561247222==" Return-path: In-Reply-To: <20170313105433.GA12980@e106950-lin.cambridge.arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Brian Starkey Cc: devel@driverdev.osuosl.org, Rom Lemarchand , Linux Kernel Mailing List , Riley Andrews , "dri-devel@lists.freedesktop.org" , Michal Hocko , "linaro-mm-sig@lists.linaro.org" , linux-mm@kvack.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Benjamin Gaignard , Greg Kroah-Hartman , Daniel Vetter , Sumit Semwal , linux-arm-kernel@lists.infradead.org, "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org --===============7224144503561247222== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jmd3p5wa7z2gqxvc" Content-Disposition: inline --jmd3p5wa7z2gqxvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: > On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > > Another point is how can we put secure rules (like selinux policy) on > > heaps since all the allocations > > go to the same device (/dev/ion) ? For example, until now, in Android > > we have to give the same > > access rights to all the process that use ION. > > It will become problem when we will add secure heaps because we won't > > be able to distinguish secure > > processes to standard ones or set specific policy per heaps. > > Maybe I'm wrong here but I have never see selinux policy checking an > > ioctl field but if that > > exist it could be a solution. > I might be thinking of a different type of "secure", but... > Should the security of secure heaps be enforced by OS-level > permissions? I don't know about other architectures, but at least on > arm/arm64 this is enforced in hardware; it doesn't matter who has > access to the ion heap, because only secure devices (or the CPU > running a secure process) is physically able to access the memory > backing the buffer. > In fact, in the use-cases I know of, the process asking for the ion > allocation is not a secure process, and so we wouldn't *want* to > restrict the secure heap to be allocated from only by secure > processes. I think there's an orthogonal level of OS level security that can be applied here - it's reasonable for it to want to say things like "only processes that are supposed to be implementing functionality X should be able to try to allocate memory set aside for that functionality". This mitigates against escallation attacks and so on, it's not really directly related to secure memory as such though. --jmd3p5wa7z2gqxvc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAljGnO0ACgkQJNaLcl1U h9ADTgf/cen1KJxzB5DyzPjdff5+hLmkjHDPrpZVfe7FMCTp8wYRsf1OHGAMsHx0 KsoTEdpQmt6ao4EEQGYPZWs1VSYE12tXejBGQJ0Av8duNXg1BUUUnLJi+xz/sIGb tDX3trnLxByCfqFdZEtXuFpErBUtyt3tv5nrcLYzWFcgWaK+Xuf+5WsPZ4McTJCF KK7j22M9qZ5J/0C/DyTM2H8EaBb6NjSDfDBnydDYCzYrf+YkxwAdcj8qta9toRyV qfBVsD/kkx8dHPPYZG+WXeQCzkQPoluN94P2cN2Ni990mzSAKtgS8maXRJ9MRUBV 5F4uW1syDtEsiZPAdFPeC/ZXISn65g== =C/hC -----END PGP SIGNATURE----- --jmd3p5wa7z2gqxvc-- --===============7224144503561247222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel --===============7224144503561247222==--