linux-kernel - Re: [PATCH 2/2] powerpc/rtas: block error injection when locked down

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] [day] [month] [year] [list]

Date:   Fri, 23 Sep 2022 13:42:43 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Nathan Lynch <nathanl@...ux.ibm.com>
Cc:     Michael Ellerman <mpe@...erman.id.au>,
        linuxppc-dev@...ts.ozlabs.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, jmorris@...ei.org, serge@...lyn.com,
        ajd@...ux.ibm.com, gcwilson@...ux.ibm.com, nayna@...ux.ibm.com
Subject: Re: [PATCH 2/2] powerpc/rtas: block error injection when locked down

On Fri, Sep 23, 2022 at 11:40 AM Nathan Lynch <nathanl@...ux.ibm.com> wrote:
> Michael Ellerman <mpe@...erman.id.au> writes:
> > Paul Moore <paul@...l-moore.com> writes:
> >> On Thu, Sep 22, 2022 at 3:38 PM Nathan Lynch <nathanl@...ux.ibm.com> wrote:
> >>>
> >>> The error injection facility on pseries VMs allows corruption of
> >>> arbitrary guest memory, potentially enabling a sufficiently privileged
> >>> user to disable lockdown or perform other modifications of the running
> >>> kernel via the rtas syscall.
> >>>
> >>> Block the PAPR error injection facility from being opened or called
> >>> when locked down.
> >>>
> >>> Signed-off-by: Nathan Lynch <nathanl@...ux.ibm.com>
> >>> ---
> >>>  arch/powerpc/kernel/rtas.c | 25 ++++++++++++++++++++++++-
> >>>  include/linux/security.h   |  1 +
> >>>  security/security.c        |  1 +
> >>>  3 files changed, 26 insertions(+), 1 deletion(-)
> >>
> >> ...
> >>
> >>> diff --git a/include/linux/security.h b/include/linux/security.h
> >>> index 1ca8dbacd3cc..b5d5138ae66a 100644
> >>> --- a/include/linux/security.h
> >>> +++ b/include/linux/security.h
> >>> @@ -123,6 +123,7 @@ enum lockdown_reason {
> >>>         LOCKDOWN_BPF_WRITE_USER,
> >>>         LOCKDOWN_DBG_WRITE_KERNEL,
> >>>         LOCKDOWN_DEVICE_TREE,
> >>> +       LOCKDOWN_RTAS_ERROR_INJECTION,
> >>
> >> With the understanding that I've never heard of RTAS until now, are
> >> there any other RTAS events that would require a lockdown reason?  As
> >> a follow up, is it important to distinguish between different RTAS
> >> lockdown reasons?
>
> 1. Not to my current knowledge.
> 2. Yes, I think so, see below.
>
> >>
> >> I'm trying to determine if we can just call it LOCKDOWN_RTAS.
> >
> > Yes I think we should.
> >
> > Currently it only locks down the error injection calls, not all of RTAS.
> >
> > But firmware can/will add new RTAS calls in future, so it's always
> > possible something will need to be added to the list of things that need
> > to be blocked during lockdown.
> >
> > So I think calling it LOCKDOWN_RTAS would be more general and future
> > proof, and can be read to mean "lockdown the parts of RTAS that need
> > to be locked down".
>
> RTAS provides callable interfaces for a broad variety of functions,
> including device configuration, halt/reboot/suspend, CPU online/offline,
> NVRAM access, firmware upgrade, platform diagnostic data retrieval, and
> others.
>
> Currently I don't know of other RTAS-provided functions that should be
> restricted. But if we were to add more, then -- in answer to Paul -- yes
> I think it would be important to have distinct reasons and
> messages. Taking the point of view of someone diagnosing lockdown denial
> messages and relating them to kernel code and user space activity, I
> would rather we err toward specificity.

As I said before, RTAS is a great mystery to me, if it can be extended
in the future then having a targeted lockdown name makes perfect
sense.

> So a single RTAS catch-all lockdown reason doesn't appeal to me, but
> lockdown reasons and messages aren't ABI (right?) ...

Correct.  Or at least that is my understanding, but there have been
some odd rulings on lockdown in the past so my advice would be to make
*very* sure you get this right the first time.  From what you and
Michael have said, it seems like a function specific name is the way
to go here, and based on your explanations of the situation it seems
like putting this in the integrity bin is the right way to go.

-- 
paul-moore.com