linux-kernel - Re: [PATCH] RTIC: selinux: ARM64: Move selinux

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:   Mon, 22 Feb 2021 10:56:57 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     pnagar@...eaurora.org
Cc:     Ard Biesheuvel <ardb@...nel.org>, Will Deacon <will@...nel.org>,
        arnd@...db.de, jmorris@...ei.org, serge@...lyn.com,
        paul@...l-moore.com, stephen.smalley.work@...il.com,
        eparis@...isplace.org, linux-security-module@...r.kernel.org,
        selinux@...r.kernel.org, linux-arch@...r.kernel.org,
        casey@...aufler-ca.com, ndesaulniers@...gle.com,
        dhowells@...hat.com, ojeda@...nel.org, psodagud@...eaurora.org,
        nmardana@...eaurora.org, johan@...nel.org, joe@...ches.com,
        jeyu@...nel.org, linux-kernel@...r.kernel.org,
        Quentin Perret <qperret@...gle.com>
Subject: Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page

On Mon, 22 Feb 2021 04:58:41 +0000,
pnagar@...eaurora.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.