From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FEFDC43381 for ; Mon, 22 Feb 2021 11:53:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3E3D64EF5 for ; Mon, 22 Feb 2021 11:53:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230133AbhBVLxX (ORCPT ); Mon, 22 Feb 2021 06:53:23 -0500 Received: from mail.kernel.org ([198.145.29.99]:41432 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230128AbhBVLxL (ORCPT ); Mon, 22 Feb 2021 06:53:11 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4C1A964DA5; Mon, 22 Feb 2021 11:52:30 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lE9lL-00FJGC-R2; Mon, 22 Feb 2021 11:52:28 +0000 Date: Mon, 22 Feb 2021 10:56:57 +0000 Message-ID: <87h7m41ibq.wl-maz@kernel.org> From: Marc Zyngier To: pnagar@codeaurora.org Cc: Ard Biesheuvel , Will Deacon , arnd@arndb.de, jmorris@namei.org, serge@hallyn.com, paul@paul-moore.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-arch@vger.kernel.org, casey@schaufler-ca.com, ndesaulniers@google.com, dhowells@redhat.com, ojeda@kernel.org, psodagud@codeaurora.org, nmardana@codeaurora.org, johan@kernel.org, joe@perches.com, jeyu@kernel.org, linux-kernel@vger.kernel.org, Quentin Perret Subject: Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page In-Reply-To: <5f33e59bf9c01ed5c33a9c3cbe277615@codeaurora.org> References: <1613470672-3069-1-git-send-email-pnagar@codeaurora.org> <20210217094205.GA3570@willie-the-truck> <09bd49a4d8fcb1bebaa4f40fd5c6eac3@kernel.org> <5f33e59bf9c01ed5c33a9c3cbe277615@codeaurora.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: pnagar@codeaurora.org, ardb@kernel.org, will@kernel.org, arnd@arndb.de, jmorris@namei.org, serge@hallyn.com, paul@paul-moore.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-arch@vger.kernel.org, casey@schaufler-ca.com, ndesaulniers@google.com, dhowells@redhat.com, ojeda@kernel.org, psodagud@codeaurora.org, nmardana@codeaurora.org, johan@kernel.org, joe@perches.com, jeyu@kernel.org, linux-kernel@vger.kernel.org, qperret@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Mon, 22 Feb 2021 04:58:41 +0000, pnagar@codeaurora.org wrote: > > On 2021-02-17 15:45, Marc Zyngier wrote: [...] > > +1 on that. Even if, as I suspect, this is targeting some unspecified > > hypervisor that is not KVM, the first course of action should be for > > this to be implemented in the kernel's own hypervisor first so that > > anyone can review understand what is at play. > > > > Thanks, > > > > M. > > Thank you for your comments. The key value add of the feature is a > third party independent entity keeping a watch on crucial kernel > assets, such that in case the kernel itself is compromised, still, > the protection can remain intact. Can this be achieved if the > implementation is done in KVM? I've limited knowledge of KVM > currently, can surely look into more details for a better > understanding. [+Quentin] KVM/arm64 doesn't currently support Stage-2 mappings on the host side, but there are patches[1] on the list that implement this functionality, and that I'm hoping to get in 5.13 (no pressure, Quentin... ;-). This could also be implemented with the current KVM code though, as a PV service to guests, and I'd suggest looking into that as an initial approach. Thanks, M. [1] https://lore.kernel.org/r/20210108121524.656872-1-qperret@google.com -- Without deviation from the norm, progress is not possible.