From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
"hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org"
<hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
Leif Lindholm
<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org"
<tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation
Date: Sun, 24 Apr 2016 22:22:41 +0100 [thread overview]
Message-ID: <20160424212241.GO2829@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu8FGpZK4yDito2jKTbjuyE2jojj5tZhCa2qUwKdWL9+ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 22 Apr, at 04:12:59PM, Ard Biesheuvel wrote:
> On 22 April 2016 at 15:51, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > Some firmware erroneously unmask IRQs (and potentially other architecture
> > specific exceptions) during runtime services functions, in violation of both
> > common sense and the UEFI specification. This can result in a number of issues
> > if said exceptions are taken when they are expected to be masked, and
> > additionally can confuse IRQ tracing if the original mask state is not
> > restored prior to returning from firmware.
> >
> > In practice it's difficult to check that firmware never unmasks exceptions, but
> > we can at least check that the IRQ flags are at least consistent upon entry to
> > and return from a runtime services function call. This series implements said
> > check in the shared EFI runtime wrappers code, after an initial round of
> > refactoring such that this can be generic.
> >
> > I have left ia64 as-is, without this check, as ia64 doesn't currently use the
> > generic runtime wrappers, has many special cases for the runtime calls which
> > don't fit well with the generic code, and I don't expect a new, buggy ia64
> > firmware to appear soon.
> >
> > The first time corruption of the IRQ flags is detected, we dump a stack trace,
> > and set TAINT_FIRMWARE_WORKAROUND. Additionally, and in all subsequent cases,
> > we log (with ratelimiting) the specific corruption of the flags, and restore
> > the expected flags to avoid redundant warnings elsewhere.
> >
> > Since v1 [1]:
> > * Fix thinko: s/local_irq_save/local_save_flags/
> > * Remove ifdefs after conversion
> > * Remove reundant semicolon from x86 patch
> > * Move efi_call_virt_check_flags before first use
> > * Add Acked-bys and Reviewed-bys
> >
> > Ard, I assume that your Reviewed-by still stands for the final patch, even
> > though efi_call_virt_check_flags moved. Please shout if that's not the case!
> >
>
> No, that's fine. Thanks for respinning so quickly.
>
> > Hopefully you're also happy to extend that to the new patch removing the
> > ifdefs once they become superfluous.
> >
>
> Matt: in case your review bandwidth is limited atm, I'd much prefer
> this series making v4.7 than the GOP stuff or the other stuff i have
> been posting over the past weeks.
I like this series a lot (well, ignoring the fact that the firmware is
trying to eat itself). The runtime call code is much cleaner now, and
this is a great precedent for any future multi-architecture quirks we
may need.
Queued for v4.7, thanks everyone!
WARNING: multiple messages have this Message-ID (diff)
From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation
Date: Sun, 24 Apr 2016 22:22:41 +0100 [thread overview]
Message-ID: <20160424212241.GO2829@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu8FGpZK4yDito2jKTbjuyE2jojj5tZhCa2qUwKdWL9+ng@mail.gmail.com>
On Fri, 22 Apr, at 04:12:59PM, Ard Biesheuvel wrote:
> On 22 April 2016 at 15:51, Mark Rutland <mark.rutland@arm.com> wrote:
> > Some firmware erroneously unmask IRQs (and potentially other architecture
> > specific exceptions) during runtime services functions, in violation of both
> > common sense and the UEFI specification. This can result in a number of issues
> > if said exceptions are taken when they are expected to be masked, and
> > additionally can confuse IRQ tracing if the original mask state is not
> > restored prior to returning from firmware.
> >
> > In practice it's difficult to check that firmware never unmasks exceptions, but
> > we can at least check that the IRQ flags are at least consistent upon entry to
> > and return from a runtime services function call. This series implements said
> > check in the shared EFI runtime wrappers code, after an initial round of
> > refactoring such that this can be generic.
> >
> > I have left ia64 as-is, without this check, as ia64 doesn't currently use the
> > generic runtime wrappers, has many special cases for the runtime calls which
> > don't fit well with the generic code, and I don't expect a new, buggy ia64
> > firmware to appear soon.
> >
> > The first time corruption of the IRQ flags is detected, we dump a stack trace,
> > and set TAINT_FIRMWARE_WORKAROUND. Additionally, and in all subsequent cases,
> > we log (with ratelimiting) the specific corruption of the flags, and restore
> > the expected flags to avoid redundant warnings elsewhere.
> >
> > Since v1 [1]:
> > * Fix thinko: s/local_irq_save/local_save_flags/
> > * Remove ifdefs after conversion
> > * Remove reundant semicolon from x86 patch
> > * Move efi_call_virt_check_flags before first use
> > * Add Acked-bys and Reviewed-bys
> >
> > Ard, I assume that your Reviewed-by still stands for the final patch, even
> > though efi_call_virt_check_flags moved. Please shout if that's not the case!
> >
>
> No, that's fine. Thanks for respinning so quickly.
>
> > Hopefully you're also happy to extend that to the new patch removing the
> > ifdefs once they become superfluous.
> >
>
> Matt: in case your review bandwidth is limited atm, I'd much prefer
> this series making v4.7 than the GOP stuff or the other stuff i have
> been posting over the past weeks.
I like this series a lot (well, ignoring the fact that the firmware is
trying to eat itself). The runtime call code is much cleaner now, and
this is a great precedent for any future multi-architecture quirks we
may need.
Queued for v4.7, thanks everyone!
WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"hpa@zytor.com" <hpa@zytor.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation
Date: Sun, 24 Apr 2016 22:22:41 +0100 [thread overview]
Message-ID: <20160424212241.GO2829@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu8FGpZK4yDito2jKTbjuyE2jojj5tZhCa2qUwKdWL9+ng@mail.gmail.com>
On Fri, 22 Apr, at 04:12:59PM, Ard Biesheuvel wrote:
> On 22 April 2016 at 15:51, Mark Rutland <mark.rutland@arm.com> wrote:
> > Some firmware erroneously unmask IRQs (and potentially other architecture
> > specific exceptions) during runtime services functions, in violation of both
> > common sense and the UEFI specification. This can result in a number of issues
> > if said exceptions are taken when they are expected to be masked, and
> > additionally can confuse IRQ tracing if the original mask state is not
> > restored prior to returning from firmware.
> >
> > In practice it's difficult to check that firmware never unmasks exceptions, but
> > we can at least check that the IRQ flags are at least consistent upon entry to
> > and return from a runtime services function call. This series implements said
> > check in the shared EFI runtime wrappers code, after an initial round of
> > refactoring such that this can be generic.
> >
> > I have left ia64 as-is, without this check, as ia64 doesn't currently use the
> > generic runtime wrappers, has many special cases for the runtime calls which
> > don't fit well with the generic code, and I don't expect a new, buggy ia64
> > firmware to appear soon.
> >
> > The first time corruption of the IRQ flags is detected, we dump a stack trace,
> > and set TAINT_FIRMWARE_WORKAROUND. Additionally, and in all subsequent cases,
> > we log (with ratelimiting) the specific corruption of the flags, and restore
> > the expected flags to avoid redundant warnings elsewhere.
> >
> > Since v1 [1]:
> > * Fix thinko: s/local_irq_save/local_save_flags/
> > * Remove ifdefs after conversion
> > * Remove reundant semicolon from x86 patch
> > * Move efi_call_virt_check_flags before first use
> > * Add Acked-bys and Reviewed-bys
> >
> > Ard, I assume that your Reviewed-by still stands for the final patch, even
> > though efi_call_virt_check_flags moved. Please shout if that's not the case!
> >
>
> No, that's fine. Thanks for respinning so quickly.
>
> > Hopefully you're also happy to extend that to the new patch removing the
> > ifdefs once they become superfluous.
> >
>
> Matt: in case your review bandwidth is limited atm, I'd much prefer
> this series making v4.7 than the GOP stuff or the other stuff i have
> been posting over the past weeks.
I like this series a lot (well, ignoring the fact that the firmware is
trying to eat itself). The runtime call code is much cleaner now, and
this is a great precedent for any future multi-architecture quirks we
may need.
Queued for v4.7, thanks everyone!
next prev parent reply other threads:[~2016-04-24 21:22 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 13:51 [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` [PATCHv2 1/6] efi/runtime-wrappers: add {__,}efi_call_virt templates Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-24 21:12 ` Matt Fleming
2016-04-24 21:12 ` Matt Fleming
2016-04-22 13:51 ` [PATCHv2 2/6] arm64/efi: move to generic {__,}efi_call_virt Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` [PATCHv2 3/6] arm/efi: " Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` [PATCHv2 4/6] x86/efi: " Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` [PATCHv2 5/6] efi/runtime-wrappers: remove redundant ifdefs Mark Rutland
2016-04-22 13:51 ` Mark Rutland
2016-04-22 13:51 ` [PATCHv2 6/6] efi/runtime-wrappers: detect FW irq flag corruption Mark Rutland
2016-04-22 13:51 ` Mark Rutland
[not found] ` <1461333083-15529-7-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
2016-04-24 21:17 ` Matt Fleming
2016-04-24 21:17 ` Matt Fleming
2016-04-24 21:17 ` Matt Fleming
[not found] ` <1461333083-15529-1-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
2016-04-22 14:12 ` [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation Ard Biesheuvel
2016-04-22 14:12 ` Ard Biesheuvel
2016-04-22 14:12 ` Ard Biesheuvel
[not found] ` <CAKv+Gu8FGpZK4yDito2jKTbjuyE2jojj5tZhCa2qUwKdWL9+ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-24 21:22 ` Matt Fleming [this message]
2016-04-24 21:22 ` Matt Fleming
2016-04-24 21:22 ` Matt Fleming
[not found] ` <20160424212241.GO2829-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-04-25 10:15 ` Matt Fleming
2016-04-25 10:15 ` Matt Fleming
2016-04-25 10:15 ` Matt Fleming
[not found] ` <20160425101527.GP2829-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-04-25 10:21 ` Ard Biesheuvel
2016-04-25 10:21 ` Ard Biesheuvel
2016-04-25 10:21 ` Ard Biesheuvel
[not found] ` <CAKv+Gu8OfqdJp-VhC3o-tie4mRZXsF5ESKkZbsjnBHDY4xbXvQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-25 10:28 ` Matt Fleming
2016-04-25 10:28 ` Matt Fleming
2016-04-25 10:28 ` Matt Fleming
[not found] ` <20160425102821.GQ2829-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-04-25 10:40 ` Mark Rutland
2016-04-25 10:40 ` Mark Rutland
2016-04-25 10:40 ` Mark Rutland
2016-04-25 10:51 ` Matt Fleming
2016-04-25 10:51 ` Matt Fleming
2016-04-25 10:51 ` Matt Fleming
[not found] ` <20160425105153.GR2829-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-04-25 11:04 ` Mark Rutland
2016-04-25 11:04 ` Mark Rutland
2016-04-25 11:04 ` Mark Rutland
2016-04-25 11:19 ` Matt Fleming
2016-04-25 11:19 ` Matt Fleming
2016-04-25 11:19 ` Matt Fleming
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=20160424212241.GO2829@codeblueprint.co.uk \
--to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
/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.