On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann jerry.hoemann@hpe.com wrote:
Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This interfaces allows linux to "call back" into firmware to source the cause of an NMI. This feature isn't fully utilized as the actual source of the NMI isn't printed, the driver only indicates that the source couldn't be determined when the call fails.
With the advent of Gen9, iCRU replaces the CRU. The call back feature is no longer available in firmware. To be compatible and not attempt to call back into firmware on system not supporting CRU, the SMBIOS table is consulted to determine if it is safe to make the call back or not.
This results in about half of the driver code being devoted to either making CRU calls or determing if it is safe to make CRU calls. As noted, the driver isn't really using the results of the CRU calls.
Furthermore, as a consequence of the Spectre security issue, the BIOS/EFI calls are being wrapped into Spectre-disabling section. Removing the call back in hpwdt_pretimeout assists in this effort.
As the CRU sourcing of the NMI isn't required for handling the NMI and there are security concerns with making the call back, remove the legacy (pre Gen9) NMI sourcing and the DMI code to determine if the system had the CRU interface.
Signed-off-by: Jerry Hoemann jerry.hoemann@hpe.com
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch that added the objtool warning message candidates for backports to stable kernels?
Arnd
On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann jerry.hoemann@hpe.com wrote:
Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This interfaces allows linux to "call back" into firmware to source the cause of an NMI. This feature isn't fully utilized as the actual source of the NMI isn't printed, the driver only indicates that the source couldn't be determined when the call fails.
With the advent of Gen9, iCRU replaces the CRU. The call back feature is no longer available in firmware. To be compatible and not attempt to call back into firmware on system not supporting CRU, the SMBIOS table is consulted to determine if it is safe to make the call back or not.
This results in about half of the driver code being devoted to either making CRU calls or determing if it is safe to make CRU calls. As noted, the driver isn't really using the results of the CRU calls.
Furthermore, as a consequence of the Spectre security issue, the BIOS/EFI calls are being wrapped into Spectre-disabling section. Removing the call back in hpwdt_pretimeout assists in this effort.
As the CRU sourcing of the NMI isn't required for handling the NMI and there are security concerns with making the call back, remove the legacy (pre Gen9) NMI sourcing and the DMI code to determine if the system had the CRU interface.
Signed-off-by: Jerry Hoemann jerry.hoemann@hpe.com
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch that added the objtool warning message candidates for backports to stable kernels?
Makes sense to me, but it is really a bit more than a bug fix, so I'll leave it up to Jerry/HPE to make the call in respect to hpwdt.
Guenter
On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:
On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann jerry.hoemann@hpe.com wrote:
Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This interfaces allows linux to "call back" into firmware to source the cause of an NMI. This feature isn't fully utilized as the actual source of the NMI isn't printed, the driver only indicates that the source couldn't be determined when the call fails.
With the advent of Gen9, iCRU replaces the CRU. The call back feature is no longer available in firmware. To be compatible and not attempt to call back into firmware on system not supporting CRU, the SMBIOS table is consulted to determine if it is safe to make the call back or not.
This results in about half of the driver code being devoted to either making CRU calls or determing if it is safe to make CRU calls. As noted, the driver isn't really using the results of the CRU calls.
Furthermore, as a consequence of the Spectre security issue, the BIOS/EFI calls are being wrapped into Spectre-disabling section. Removing the call back in hpwdt_pretimeout assists in this effort.
As the CRU sourcing of the NMI isn't required for handling the NMI and there are security concerns with making the call back, remove the legacy (pre Gen9) NMI sourcing and the DMI code to determine if the system had the CRU interface.
Signed-off-by: Jerry Hoemann jerry.hoemann@hpe.com
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch that added the objtool warning message candidates for backports to stable kernels?
Makes sense to me, but it is really a bit more than a bug fix, so I'll leave it up to Jerry/HPE to make the call in respect to hpwdt.
Generally speaking, HPE customers who run linux do so through a distro vendor and pick up patches from them. But I'm sure there are some customers who do things differently.
The distro vendor's have their own repos and we'll work with them to back port patches to their code base. So, I typically don't do a lot of kernel.org stable branch work.
Looks like objtool has been enhanced to find Spectre vulnerable code. Are the other kernel patches related to Spectre being back ported to stable release lines? If yes, it probably make sense to do the hpwdt change as well.
Is just the patch removing the firmware call back wanted/needed? Or the whole driver rewrite? (The older baseline don't have all the watchdog features that the patch set uses.)
Which stable baseline(s) would need to be patched? Priority?
Who does it? (i.e. do you want me to submit patches to the stable baseline?)
Thanks
On 02/26/2018 05:02 PM, Jerry Hoemann wrote:
On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:
On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann jerry.hoemann@hpe.com wrote:
Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This interfaces allows linux to "call back" into firmware to source the cause of an NMI. This feature isn't fully utilized as the actual source of the NMI isn't printed, the driver only indicates that the source couldn't be determined when the call fails.
With the advent of Gen9, iCRU replaces the CRU. The call back feature is no longer available in firmware. To be compatible and not attempt to call back into firmware on system not supporting CRU, the SMBIOS table is consulted to determine if it is safe to make the call back or not.
This results in about half of the driver code being devoted to either making CRU calls or determing if it is safe to make CRU calls. As noted, the driver isn't really using the results of the CRU calls.
Furthermore, as a consequence of the Spectre security issue, the BIOS/EFI calls are being wrapped into Spectre-disabling section. Removing the call back in hpwdt_pretimeout assists in this effort.
As the CRU sourcing of the NMI isn't required for handling the NMI and there are security concerns with making the call back, remove the legacy (pre Gen9) NMI sourcing and the DMI code to determine if the system had the CRU interface.
Signed-off-by: Jerry Hoemann jerry.hoemann@hpe.com
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch that added the objtool warning message candidates for backports to stable kernels?
Makes sense to me, but it is really a bit more than a bug fix, so I'll leave it up to Jerry/HPE to make the call in respect to hpwdt.
Generally speaking, HPE customers who run linux do so through a distro vendor and pick up patches from them. But I'm sure there are some customers who do things differently.
The distro vendor's have their own repos and we'll work with them to back port patches to their code base. So, I typically don't do a lot of kernel.org stable branch work.
Looks like objtool has been enhanced to find Spectre vulnerable code. Are the other kernel patches related to Spectre being back ported to stable release lines? If yes, it probably make sense to do the hpwdt change as well.
Spectre has been backported to v4.4 and later. I don't know about earlier kernels.
Is just the patch removing the firmware call back wanted/needed? Or the whole driver rewrite? (The older baseline don't have all the watchdog features that the patch set uses.)
We would only want to backport this patch. The rest is really out of scope.
Which stable baseline(s) would need to be patched? Priority?
Who does it? (i.e. do you want me to submit patches to the stable baseline?)
We would tag the patch for stable (and submit it into v4.16-rc). Greg would take care of the rest unless there are conflicts, in which case we get a note telling us that a backport is needed.
Guenter
On Mon, Feb 26, 2018 at 05:29:55PM -0800, Guenter Roeck wrote:
On 02/26/2018 05:02 PM, Jerry Hoemann wrote:
On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:
On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann jerry.hoemann@hpe.com wrote:
Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This interfaces allows linux to "call back" into firmware to source the cause of an NMI. This feature isn't fully utilized as the actual source of the NMI isn't printed, the driver only indicates that the source couldn't be determined when the call fails.
With the advent of Gen9, iCRU replaces the CRU. The call back feature is no longer available in firmware. To be compatible and not attempt to call back into firmware on system not supporting CRU, the SMBIOS table is consulted to determine if it is safe to make the call back or not.
This results in about half of the driver code being devoted to either making CRU calls or determing if it is safe to make CRU calls. As noted, the driver isn't really using the results of the CRU calls.
Furthermore, as a consequence of the Spectre security issue, the BIOS/EFI calls are being wrapped into Spectre-disabling section. Removing the call back in hpwdt_pretimeout assists in this effort.
As the CRU sourcing of the NMI isn't required for handling the NMI and there are security concerns with making the call back, remove the legacy (pre Gen9) NMI sourcing and the DMI code to determine if the system had the CRU interface.
Signed-off-by: Jerry Hoemann jerry.hoemann@hpe.com
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch that added the objtool warning message candidates for backports to stable kernels?
Makes sense to me, but it is really a bit more than a bug fix, so I'll leave it up to Jerry/HPE to make the call in respect to hpwdt.
Generally speaking, HPE customers who run linux do so through a distro vendor and pick up patches from them. But I'm sure there are some customers who do things differently.
The distro vendor's have their own repos and we'll work with them to back port patches to their code base. So, I typically don't do a lot of kernel.org stable branch work.
Looks like objtool has been enhanced to find Spectre vulnerable code. Are the other kernel patches related to Spectre being back ported to stable release lines? If yes, it probably make sense to do the hpwdt change as well.
Spectre has been backported to v4.4 and later. I don't know about earlier kernels.
Is just the patch removing the firmware call back wanted/needed? Or the whole driver rewrite? (The older baseline don't have all the watchdog features that the patch set uses.)
We would only want to backport this patch. The rest is really out of scope.
Which stable baseline(s) would need to be patched? Priority?
Who does it? (i.e. do you want me to submit patches to the stable baseline?)
We would tag the patch for stable (and submit it into v4.16-rc). Greg would take care of the rest unless there are conflicts, in which case we get a note telling us that a backport is needed.
Guenter,
Are you waiting for anything more from me on this patch, or are we good for now until the back ports to v.15 etc.,?
Thanks
Jerry
On 02/28/2018 11:45 AM, Jerry Hoemann wrote:
On Mon, Feb 26, 2018 at 05:29:55PM -0800, Guenter Roeck wrote:
On 02/26/2018 05:02 PM, Jerry Hoemann wrote:
On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:
On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann jerry.hoemann@hpe.com wrote:
Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This interfaces allows linux to "call back" into firmware to source the cause of an NMI. This feature isn't fully utilized as the actual source of the NMI isn't printed, the driver only indicates that the source couldn't be determined when the call fails.
With the advent of Gen9, iCRU replaces the CRU. The call back feature is no longer available in firmware. To be compatible and not attempt to call back into firmware on system not supporting CRU, the SMBIOS table is consulted to determine if it is safe to make the call back or not.
This results in about half of the driver code being devoted to either making CRU calls or determing if it is safe to make CRU calls. As noted, the driver isn't really using the results of the CRU calls.
Furthermore, as a consequence of the Spectre security issue, the BIOS/EFI calls are being wrapped into Spectre-disabling section. Removing the call back in hpwdt_pretimeout assists in this effort.
As the CRU sourcing of the NMI isn't required for handling the NMI and there are security concerns with making the call back, remove the legacy (pre Gen9) NMI sourcing and the DMI code to determine if the system had the CRU interface.
Signed-off-by: Jerry Hoemann jerry.hoemann@hpe.com
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch that added the objtool warning message candidates for backports to stable kernels?
Makes sense to me, but it is really a bit more than a bug fix, so I'll leave it up to Jerry/HPE to make the call in respect to hpwdt.
Generally speaking, HPE customers who run linux do so through a distro vendor and pick up patches from them. But I'm sure there are some customers who do things differently.
The distro vendor's have their own repos and we'll work with them to back port patches to their code base. So, I typically don't do a lot of kernel.org stable branch work.
Looks like objtool has been enhanced to find Spectre vulnerable code. Are the other kernel patches related to Spectre being back ported to stable release lines? If yes, it probably make sense to do the hpwdt change as well.
Spectre has been backported to v4.4 and later. I don't know about earlier kernels.
Is just the patch removing the firmware call back wanted/needed? Or the whole driver rewrite? (The older baseline don't have all the watchdog features that the patch set uses.)
We would only want to backport this patch. The rest is really out of scope.
Which stable baseline(s) would need to be patched? Priority?
Who does it? (i.e. do you want me to submit patches to the stable baseline?)
We would tag the patch for stable (and submit it into v4.16-rc). Greg would take care of the rest unless there are conflicts, in which case we get a note telling us that a backport is needed.
Guenter,
Are you waiting for anything more from me on this patch, or are we good for now until the back ports to v.15 etc.,?
We are good. I'll need to ask Wim to send a pull request to Linus.
Guenter
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Guenter Roeck -
Jerry Hoemann