When using kdump, SOMETIMES the "size not consistent" warning message
shows up when the crash kernel boots with early_ioremap_debug parameter:
WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 early_iounmap+0x4f/0x12c()
early_iounmap(ff200180, 0118) [0] size not consistent 0120
Hi, Ard,
On Tue, 2018-05-01 at 11:54 +0200, Ard Biesheuvel wrote:
> On 25 April 2018 at 05:10, Shunyong Yang com> wrote:
> >
> > It means firmware attempts to immediately process or launch the
> > capsule
> > when flags in capsule header is not set. Moreover, reset is not
> > needed
> > in this
On Tue, May 01, 2018 at 07:29:19PM +, Andy Lutomirski wrote:
> On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote:
> > + for (i = 0; i < size; i += 8) {
> > + if (*((u64 *)(mem + i)) != *((u64 *)desc->prefix))
> > + continue;
> > +
> > +
On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote:
> +The EFI embedded-fw code works by scanning all EFI_BOOT_SERVICES_CODE
memory
> +segments for an eight byte sequence matching prefix, if the prefix is
found it
> +then does a crc32 over length bytes and if that matches makes a copy of
length
>
On Tue, 2018-05-01 at 21:11 +0200, Hans de Goede wrote:
> Hi,
>
> On 01-05-18 16:36, Mimi Zohar wrote:
> > [Cc'ing linux-security]
> >
> > On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote:
> > [...]
> >> diff --git a/drivers/base/firmware_loader/fallback_efi.c
> >> b/drivers/base/firmware_
Hi,
On 01-05-18 16:36, Mimi Zohar wrote:
[Cc'ing linux-security]
On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote:
[...]
diff --git a/drivers/base/firmware_loader/fallback_efi.c
b/drivers/base/firmware_loader/fallback_efi.c
new file mode 100644
index ..82ba82f48a79
--- /dev/
[Cc'ing linux-security]
On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote:
[...]
> diff --git a/drivers/base/firmware_loader/fallback_efi.c
> b/drivers/base/firmware_loader/fallback_efi.c
> new file mode 100644
> index ..82ba82f48a79
> --- /dev/null
> +++ b/drivers/base/firmware_
From: Ard Biesheuvel
> Sent: 28 April 2018 07:41
> On 27 April 2018 at 23:35, Hans de Goede wrote:
> > setup_efi_pci() tries to save a copy of each PCI option ROM as this may
> > be necessary for the device driver for the PCI device to have access too.
> >
> > On some systems the efi_pci_io_protoc
On 1 May 2018 at 15:52, David Laight wrote:
> From: Ard Biesheuvel
>> Sent: 28 April 2018 07:41
>> On 27 April 2018 at 23:35, Hans de Goede wrote:
>> > setup_efi_pci() tries to save a copy of each PCI option ROM as this may
>> > be necessary for the device driver for the PCI device to have access
On Tue, Apr 24, 2018 at 08:39:09AM +0200, Ard Biesheuvel wrote:
> On 23 April 2018 at 21:38, Jarkko Sakkinen
> wrote:
> > On Mon, Apr 16, 2018 at 01:05:24PM +0200, Ard Biesheuvel wrote:
> >> On 22 March 2018 at 15:09, Jarkko Sakkinen
> >> wrote:
> >> > On Thu, 2018-03-22 at 16:06 +0200, Jarkko Sa
On 1 May 2018 at 11:48, Hans de Goede wrote:
> Hi,
>
> On 29-04-18 13:06, Ard Biesheuvel wrote:
>>
>> This is a continuation of Hans's work [0] to ignore bogus romimage/romsize
>> values in the EFI PCI I/O protocol instances exposed by some UEFI
>> firmwares
>> on x86.
>>
>> I have only build test
On 25 April 2018 at 05:10, Shunyong Yang wrote:
> It means firmware attempts to immediately process or launch the capsule
> when flags in capsule header is not set. Moreover, reset is not needed
> in this case. Current code will output log to indicate reset.
>
> This patch adds a branch to avoid r
Hi,
On 29-04-18 13:06, Ard Biesheuvel wrote:
This is a continuation of Hans's work [0] to ignore bogus romimage/romsize
values in the EFI PCI I/O protocol instances exposed by some UEFI firmwares
on x86.
I have only build tested this, both on 32 and 64 bit x86.
I've tested this on both a devi
13 matches
Mail list logo
