On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez
> > wrote:
> > > Android became the primary user of
On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez
> > wrote:
> > > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
> > >
> > > It
On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez wrote:
> > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
> >
> > It would be good for us to hear from Android folks if their current
On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez wrote:
> > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
> >
> > It would be good for us to hear from Android folks if their current use of
> >
On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez wrote:
> Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
>
> It would be good for us to hear from Android folks if their current use of
> request_firmware_into_buf() is designed in practice to *never*
On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez wrote:
> Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
>
> It would be good for us to hear from Android folks if their current use of
> request_firmware_into_buf() is designed in practice to *never* use the direct
>
On Thu, May 3, 2018 at 5:21 PM, Luis R. Rodriguez wrote:
> Android folks, poke below. otherwise we'll have no option but to seriously
> consider Mimi's patch to prevent these calls when IMA appraisal is enforced:
Sorry, figuring out who's the right person to answer this, will
On Thu, May 3, 2018 at 5:21 PM, Luis R. Rodriguez wrote:
> Android folks, poke below. otherwise we'll have no option but to seriously
> consider Mimi's patch to prevent these calls when IMA appraisal is enforced:
Sorry, figuring out who's the right person to answer this, will get
back to you
Android folks, poke below. otherwise we'll have no option but to seriously
consider Mimi's patch to prevent these calls when IMA appraisal is enforced:
http://lkml.kernel.org/r/1525182503-13849-7-git-send-email-zo...@linux.vnet.ibm.com
Please read below
On Wed, Apr 25, 2018 at 05:55:57PM
Android folks, poke below. otherwise we'll have no option but to seriously
consider Mimi's patch to prevent these calls when IMA appraisal is enforced:
http://lkml.kernel.org/r/1525182503-13849-7-git-send-email-zo...@linux.vnet.ibm.com
Please read below
On Wed, Apr 25, 2018 at 05:55:57PM
On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
> On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
> > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > > On 23-04-18 23:11, Luis R. Rodriguez
On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
> On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
> > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > > On 23-04-18 23:11, Luis R. Rodriguez
On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
> On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > > > Hans, please see use of
On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
> On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > > > Hans, please see use of
On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > > Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a
> > > new ID
> > > and security for this
On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > > Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a
> > > new ID
> > > and security for this
Hi,
On 24-04-18 18:07, Mimi Zohar wrote:
On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the
Hi,
On 24-04-18 18:07, Mimi Zohar wrote:
On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the
On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> Hi,
>
> On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new
> > ID
> > and security for this type of request so IMA can reject it if the policy is
> > configured for
On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> Hi,
>
> On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new
> > ID
> > and security for this type of request so IMA can reject it if the policy is
> > configured for
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the policy is
configured for it.
Hmm, interesting, actually it seems like the whole existence
of
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the policy is
configured for it.
Hmm, interesting, actually it seems like the whole existence
of
Hi,
On 16-04-18 10:28, Ard Biesheuvel wrote:
On 8 April 2018 at 19:40, Hans de Goede wrote:
Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometimes may contain data which is
Hi,
On 16-04-18 10:28, Ard Biesheuvel wrote:
On 8 April 2018 at 19:40, Hans de Goede wrote:
Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometimes may contain data which is useful/necessary for
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the policy is
configured for it.
Please Cc Kees in future patches.
Luis
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the policy is
configured for it.
Please Cc Kees in future patches.
Luis
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out;
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out;
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out;
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out;
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
> static void firmware_free_data(const struct firmware *fw)
> {
> @@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
> const char *name,
> goto out;
>
> ret =
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
> static void firmware_free_data(const struct firmware *fw)
> {
> @@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
> const char *name,
> goto out;
>
> ret =
On 8 April 2018 at 19:40, Hans de Goede wrote:
> Just like with PCI options ROMs, which we save in the setup_efi_pci*
> functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
> sometimes may contain data which is useful/necessary for peripheral drivers
>
On 8 April 2018 at 19:40, Hans de Goede wrote:
> Just like with PCI options ROMs, which we save in the setup_efi_pci*
> functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
> sometimes may contain data which is useful/necessary for peripheral drivers
> to have access to.
>
>
Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometimes may contain data which is useful/necessary for peripheral drivers
to have access to.
Specifically the EFI code may contain an embedded copy of
Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometimes may contain data which is useful/necessary for peripheral drivers
to have access to.
Specifically the EFI code may contain an embedded copy of
36 matches
Mail list logo