All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	Andres Rodriguez <andresx7@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@suse.com>,
	Kees Cook <keescook@chromium.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer)
Date: Thu, 12 Jul 2018 13:37:46 -0700	[thread overview]
Message-ID: <20180712203746.GG545@tuxbook-pro> (raw)
In-Reply-To: <1531425793.3568.275.camel@linux.ibm.com>

On Thu 12 Jul 13:03 PDT 2018, Mimi Zohar wrote:

> On Wed, 2018-07-11 at 08:24 +0200, Ard Biesheuvel wrote:
> > On 10 July 2018 at 21:19, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> 
> > > Tbh the only case I can think of where there would be a "race condition"
> > > here is if we have a device that is polling the last byte of a
> > > predefined firmware memory area for the firmware loader to read some
> > > specific data into it. In cases where the firmware request is followed
> > > by some explicit signalling to the device (or a power on sequence) I'm
> > > unable to see the issue discussed here.
> > >
> > 
> > I agree. But the latter part is platform specific, and so it requires
> > some degree of trust in the driver author on the part of the IMA
> > routines that request_firmware() is called at an appropriate time.
> 
> Exactly.  Qualcomm could be using the pre-allocated buffer
> appropriately, but that doesn't guarantee how it will be used in the
> future.
> 

Agreed.

But a device that starts operate on the firmware memory before it's
fully loaded (and verified) will likely hit other nasty issues. Using a
traditional request_firmware() and memcpy() or simply mapping the buffer
into the remote piecemeal would have the same issue.

So I think that regardless of using IMA, if you don't have the ability
to control your device's view of the entire firmware buffer atomically
you must write your device drivers accordingly.

Regards,
Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: bjorn.andersson@linaro.org (Bjorn Andersson)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer)
Date: Thu, 12 Jul 2018 13:37:46 -0700	[thread overview]
Message-ID: <20180712203746.GG545@tuxbook-pro> (raw)
In-Reply-To: <1531425793.3568.275.camel@linux.ibm.com>

On Thu 12 Jul 13:03 PDT 2018, Mimi Zohar wrote:

> On Wed, 2018-07-11 at 08:24 +0200, Ard Biesheuvel wrote:
> > On 10 July 2018 at 21:19, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> 
> > > Tbh the only case I can think of where there would be a "race condition"
> > > here is if we have a device that is polling the last byte of a
> > > predefined firmware memory area for the firmware loader to read some
> > > specific data into it. In cases where the firmware request is followed
> > > by some explicit signalling to the device (or a power on sequence) I'm
> > > unable to see the issue discussed here.
> > >
> > 
> > I agree. But the latter part is platform specific, and so it requires
> > some degree of trust in the driver author on the part of the IMA
> > routines that request_firmware() is called at an appropriate time.
> 
> Exactly. ?Qualcomm could be using the pre-allocated buffer
> appropriately, but that doesn't guarantee how it will be used in the
> future.
> 

Agreed.

But a device that starts operate on the firmware memory before it's
fully loaded (and verified) will likely hit other nasty issues. Using a
traditional request_firmware() and memcpy() or simply mapping the buffer
into the remote piecemeal would have the same issue.

So I think that regardless of using IMA, if you don't have the ability
to control your device's view of the entire firmware buffer atomically
you must write your device drivers accordingly.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	Andres Rodriguez <andresx7@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@suse.com>,
	Kees Cook <keescook@chromium.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer)
Date: Thu, 12 Jul 2018 13:37:46 -0700	[thread overview]
Message-ID: <20180712203746.GG545@tuxbook-pro> (raw)
In-Reply-To: <1531425793.3568.275.camel@linux.ibm.com>

On Thu 12 Jul 13:03 PDT 2018, Mimi Zohar wrote:

> On Wed, 2018-07-11 at 08:24 +0200, Ard Biesheuvel wrote:
> > On 10 July 2018 at 21:19, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> 
> > > Tbh the only case I can think of where there would be a "race condition"
> > > here is if we have a device that is polling the last byte of a
> > > predefined firmware memory area for the firmware loader to read some
> > > specific data into it. In cases where the firmware request is followed
> > > by some explicit signalling to the device (or a power on sequence) I'm
> > > unable to see the issue discussed here.
> > >
> > 
> > I agree. But the latter part is platform specific, and so it requires
> > some degree of trust in the driver author on the part of the IMA
> > routines that request_firmware() is called at an appropriate time.
> 
> Exactly.  Qualcomm could be using the pre-allocated buffer
> appropriately, but that doesn't guarantee how it will be used in the
> future.
> 

Agreed.

But a device that starts operate on the firmware memory before it's
fully loaded (and verified) will likely hit other nasty issues. Using a
traditional request_firmware() and memcpy() or simply mapping the buffer
into the remote piecemeal would have the same issue.

So I think that regardless of using IMA, if you don't have the ability
to control your device's view of the entire firmware buffer atomically
you must write your device drivers accordingly.

Regards,
Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Andres Rodriguez <andresx7@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@suse.com>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Eric Biederman <ebiederm@xmission.com>
Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer)
Date: Thu, 12 Jul 2018 13:37:46 -0700	[thread overview]
Message-ID: <20180712203746.GG545@tuxbook-pro> (raw)
In-Reply-To: <1531425793.3568.275.camel@linux.ibm.com>

On Thu 12 Jul 13:03 PDT 2018, Mimi Zohar wrote:

> On Wed, 2018-07-11 at 08:24 +0200, Ard Biesheuvel wrote:
> > On 10 July 2018 at 21:19, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> 
> > > Tbh the only case I can think of where there would be a "race condition"
> > > here is if we have a device that is polling the last byte of a
> > > predefined firmware memory area for the firmware loader to read some
> > > specific data into it. In cases where the firmware request is followed
> > > by some explicit signalling to the device (or a power on sequence) I'm
> > > unable to see the issue discussed here.
> > >
> > 
> > I agree. But the latter part is platform specific, and so it requires
> > some degree of trust in the driver author on the part of the IMA
> > routines that request_firmware() is called at an appropriate time.
> 
> Exactly.  Qualcomm could be using the pre-allocated buffer
> appropriately, but that doesn't guarantee how it will be used in the
> future.
> 

Agreed.

But a device that starts operate on the firmware memory before it's
fully loaded (and verified) will likely hit other nasty issues. Using a
traditional request_firmware() and memcpy() or simply mapping the buffer
into the remote piecemeal would have the same issue.

So I think that regardless of using IMA, if you don't have the ability
to control your device's view of the entire firmware buffer atomically
you must write your device drivers accordingly.

Regards,
Bjorn

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2018-07-12 20:35 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02 14:37 [PATCH v5 0/8] kexec/firmware: support system wide policy requiring signatures Mimi Zohar
2018-07-02 14:37 ` Mimi Zohar
2018-07-02 14:37 ` Mimi Zohar
2018-07-02 14:37 ` [PATCH v5 1/8] security: define new LSM hook named security_kernel_load_data Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-02 18:45   ` J Freyensee
2018-07-02 18:45     ` J Freyensee
2018-07-02 18:45     ` J Freyensee
2018-07-02 18:45     ` J Freyensee
2018-07-03 12:35     ` Mimi Zohar
2018-07-03 12:35       ` Mimi Zohar
2018-07-03 12:35       ` Mimi Zohar
2018-07-03 12:35       ` Mimi Zohar
2018-07-02 14:37 ` [PATCH v5 2/8] kexec: add call to LSM hook in original kexec_load syscall Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-10 20:26   ` Mimi Zohar
2018-07-10 20:26     ` Mimi Zohar
2018-07-10 20:26     ` Mimi Zohar
2018-07-02 14:37 ` [PATCH v5 3/8] ima: based on policy require signed kexec kernel images Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-02 18:31   ` J Freyensee
2018-07-02 18:31     ` J Freyensee
2018-07-02 18:31     ` J Freyensee
2018-07-02 18:31     ` J Freyensee
2018-07-03 13:07     ` Mimi Zohar
2018-07-03 13:07       ` Mimi Zohar
2018-07-03 13:07       ` Mimi Zohar
2018-07-03 13:07       ` Mimi Zohar
2018-07-02 14:37 ` [PATCH v5 4/8] firmware: add call to LSM hook before firmware sysfs fallback Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-02 14:37   ` Mimi Zohar
2018-07-03 12:04   ` kbuild test robot
2018-07-03 12:04     ` kbuild test robot
2018-07-03 12:04     ` kbuild test robot
2018-07-03 12:04     ` kbuild test robot
2018-07-02 14:38 ` [PATCH v5 5/8] ima: based on policy require signed firmware (sysfs fallback) Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 14:38 ` [PATCH v5 6/8] ima: add build time policy Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 14:38 ` [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 15:30   ` Ard Biesheuvel
2018-07-02 15:30     ` Ard Biesheuvel
2018-07-02 15:30     ` Ard Biesheuvel
2018-07-09 19:41     ` Mimi Zohar
2018-07-09 19:41       ` Mimi Zohar
2018-07-09 19:41       ` Mimi Zohar
2018-07-09 19:41       ` Mimi Zohar
2018-07-10  6:51       ` Ard Biesheuvel
2018-07-10  6:51         ` Ard Biesheuvel
2018-07-10  6:51         ` Ard Biesheuvel
2018-07-10  6:56         ` Ard Biesheuvel
2018-07-10  6:56           ` Ard Biesheuvel
2018-07-10  6:56           ` Ard Biesheuvel
2018-07-10 18:47           ` Mimi Zohar
2018-07-10 18:47             ` Mimi Zohar
2018-07-10 18:47             ` Mimi Zohar
2018-07-10 18:47             ` Mimi Zohar
2018-07-10 19:19           ` Bjorn Andersson
2018-07-10 19:19             ` Bjorn Andersson
2018-07-10 19:19             ` Bjorn Andersson
2018-07-11  6:24             ` Ard Biesheuvel
2018-07-11  6:24               ` Ard Biesheuvel
2018-07-11  6:24               ` Ard Biesheuvel
2018-07-12 20:03               ` Mimi Zohar
2018-07-12 20:03                 ` Mimi Zohar
2018-07-12 20:03                 ` Mimi Zohar
2018-07-12 20:03                 ` Mimi Zohar
2018-07-12 20:37                 ` Bjorn Andersson [this message]
2018-07-12 20:37                   ` Bjorn Andersson
2018-07-12 20:37                   ` Bjorn Andersson
2018-07-12 20:37                   ` Bjorn Andersson
2018-07-02 14:38 ` [PATCH v5 8/8] module: replace the existing LSM hook in init_module Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-02 14:38   ` Mimi Zohar
2018-07-03  9:35   ` kbuild test robot
2018-07-03  9:35     ` kbuild test robot
2018-07-03  9:35     ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180712203746.GG545@tuxbook-pro \
    --to=bjorn.andersson@linaro.org \
    --cc=andresx7@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mcgrof@suse.com \
    --cc=sboyd@kernel.org \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.