| Message ID | 20190103004921.1928921-2-jeremy.linton@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | add system vulnerability sysfs entries | expand |
On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > There is a lot of variation in the Arm ecosystem. Because of this, > there exist possible cases where the kernel cannot authoritatively > determine if a machine is vulnerable. Really? Why not? What keeps you from "knowing" this? Can't the developer of the chip tell you? > Rather than guess the vulnerability status in cases where > the mitigation is disabled or the firmware isn't responding > correctly, we need to display an "Unknown" state. Shouldn't "Unknown" really be the same thing as "Vulnerable"? A user should treat it the same way, "Unknown" makes it feel like "maybe I can just ignore this and hope I really am safe", which is not a good idea at all. thanks, greg k-h
On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > There is a lot of variation in the Arm ecosystem. Because of this, > there exist possible cases where the kernel cannot authoritatively > determine if a machine is vulnerable. > > Rather than guess the vulnerability status in cases where > the mitigation is disabled or the firmware isn't responding > correctly, we need to display an "Unknown" state. > > Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Dave Hansen <dave.hansen@intel.com> > Cc: Borislav Petkov <bp@alien8.de> > Cc: David Woodhouse <dwmw@amazon.co.uk> > --- > Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu > index 9605dbd4b5b5..876103fddfa4 100644 > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > @@ -495,6 +495,7 @@ Description: Information about CPU vulnerabilities > "Not affected" CPU is not affected by the vulnerability > "Vulnerable" CPU is affected and no mitigation in effect > "Mitigation: $M" CPU is affected and mitigation $M is in effect > + "Unknown" The kernel is unable to make a determination Do some of the "Unknown" cases arise from the vulnerability detection code being compiled out of the kernel? I wonder whether at least the detection support should be mandatory. sysfs is not very useful as a standard vulnerability reporting interface unless we make best efforts to always populate it with real information. Also, does "Unknown" convey anything beyond what is indicated by the sysfs entry being omitted altogether? Cheers ---Dave
On 01/03/2019 03:38 AM, Greg Kroah-Hartman wrote: > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: >> There is a lot of variation in the Arm ecosystem. Because of this, >> there exist possible cases where the kernel cannot authoritatively >> determine if a machine is vulnerable. > > Really? Why not? What keeps you from "knowing" this? Can't the > developer of the chip tell you? There tends to be a few cases, possibly incomplete white/black lists, firmware that isn't responding correctly, or the user didn't build in the code to check the mitigation (possibly because its an embedded system and they know its not vulnerable?). I would hope that it is an exceptional case. > >> Rather than guess the vulnerability status in cases where >> the mitigation is disabled or the firmware isn't responding >> correctly, we need to display an "Unknown" state. > > Shouldn't "Unknown" really be the same thing as "Vulnerable"? A user > should treat it the same way, "Unknown" makes it feel like "maybe I can > just ignore this and hope I really am safe", which is not a good idea at > all. I tend to agree its not clear what to do with "unknown". OTOH, I think there is a hesitation to declare something vulnerable when it isn't. Meltdown for example, is fairly rare given that it currently only affects a few arm parts, so declaring someone vulnerable when they likely aren't is going to be just as difficult to explain.
Hi, On 01/03/2019 10:37 AM, Dave Martin wrote: > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: >> There is a lot of variation in the Arm ecosystem. Because of this, >> there exist possible cases where the kernel cannot authoritatively >> determine if a machine is vulnerable. >> >> Rather than guess the vulnerability status in cases where >> the mitigation is disabled or the firmware isn't responding >> correctly, we need to display an "Unknown" state. >> >> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> Cc: Peter Zijlstra <peterz@infradead.org> >> Cc: Dave Hansen <dave.hansen@intel.com> >> Cc: Borislav Petkov <bp@alien8.de> >> Cc: David Woodhouse <dwmw@amazon.co.uk> >> --- >> Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu >> index 9605dbd4b5b5..876103fddfa4 100644 >> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu >> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu >> @@ -495,6 +495,7 @@ Description: Information about CPU vulnerabilities >> "Not affected" CPU is not affected by the vulnerability >> "Vulnerable" CPU is affected and no mitigation in effect >> "Mitigation: $M" CPU is affected and mitigation $M is in effect >> + "Unknown" The kernel is unable to make a determination > > Do some of the "Unknown" cases arise from the vulnerability detection > code being compiled out of the kernel? > Yes, > I wonder whether at least the detection support should be mandatory. > sysfs is not very useful as a standard vulnerability reporting interface > unless we make best efforts to always populate it with real information. > > > Also, does "Unknown" convey anything beyond what is indicated by the > sysfs entry being omitted altogether? I'm not sure about this one. I tend to think the "unknown" case encourages users that really want an answer to dig deeper and call their hardware/os/whoever to get an answer. I would tend to think that if the entry is missing it would tend to encourage the behavior that Greg KH mentions where the user assumes "hey the system doesn't have a sysfs entry for $VUNLERABILITY, that probably means that its not possible on the architecture".
On Thu, Jan 03, 2019 at 10:38:16AM -0600, Jeremy Linton wrote: > On 01/03/2019 03:38 AM, Greg Kroah-Hartman wrote: > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > > > There is a lot of variation in the Arm ecosystem. Because of this, > > > there exist possible cases where the kernel cannot authoritatively > > > determine if a machine is vulnerable. > > > > Really? Why not? What keeps you from "knowing" this? Can't the > > developer of the chip tell you? > > There tends to be a few cases, possibly incomplete white/black lists, Then fix the lists :) > firmware that isn't responding correctly, or the user didn't build in the > code to check the mitigation (possibly because its an embedded system and > they know its not vulnerable?). If the firmware doesn't respond, that would imply it is vulnerable :) And if the code isn't built in, again, it's vulnerable. > I would hope that it is an exceptional case. Then have the default be vulnerable, don't give people false hope. > > > Rather than guess the vulnerability status in cases where > > > the mitigation is disabled or the firmware isn't responding > > > correctly, we need to display an "Unknown" state. > > > > Shouldn't "Unknown" really be the same thing as "Vulnerable"? A user > > should treat it the same way, "Unknown" makes it feel like "maybe I can > > just ignore this and hope I really am safe", which is not a good idea at > > all. > > I tend to agree its not clear what to do with "unknown". > > OTOH, I think there is a hesitation to declare something vulnerable when it > isn't. Meltdown for example, is fairly rare given that it currently only > affects a few arm parts, so declaring someone vulnerable when they likely > aren't is going to be just as difficult to explain. If you know it is rare, then you know how to properly detect it so "unknown" is not needed, correct? Again, "unknown" is not going to help anyone out here, please don't do it. thanks, greg k-h
Hi Jeremy, > Jeremy Linton <jeremy.linton@arm.com> hat am 3. Januar 2019 um 17:46 geschrieben: > > > Hi, > > On 01/03/2019 10:37 AM, Dave Martin wrote: > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > >> There is a lot of variation in the Arm ecosystem. Because of this, > >> there exist possible cases where the kernel cannot authoritatively > >> determine if a machine is vulnerable. > >> > >> Rather than guess the vulnerability status in cases where > >> the mitigation is disabled or the firmware isn't responding > >> correctly, we need to display an "Unknown" state. > >> i applied your patch series on linux-next-20190103. On my Raspberry Pi 3B+ (defconfig) i'm getting this from sysfs: l1tf:Not affected meltdown:Not affected spec_store_bypass:Unknown spectre_v1:Mitigation: __user pointer sanitization spectre_v2:Unknown AFAIK it has 4 Cortex-A53 cores (no PSCI firmware), so shouldn't be affected. How can this be fixed? Thanks Stefan
Hi, On 01/03/2019 01:30 PM, Stefan Wahren wrote: > Hi Jeremy, > >> Jeremy Linton <jeremy.linton@arm.com> hat am 3. Januar 2019 um 17:46 geschrieben: >> >> >> Hi, >> >> On 01/03/2019 10:37 AM, Dave Martin wrote: >>> On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: >>>> There is a lot of variation in the Arm ecosystem. Because of this, >>>> there exist possible cases where the kernel cannot authoritatively >>>> determine if a machine is vulnerable. >>>> >>>> Rather than guess the vulnerability status in cases where >>>> the mitigation is disabled or the firmware isn't responding >>>> correctly, we need to display an "Unknown" state. >>>> > > i applied your patch series on linux-next-20190103. On my Raspberry Pi 3B+ (defconfig) i'm getting this from sysfs: > > l1tf:Not affected > meltdown:Not affected > spec_store_bypass:Unknown > spectre_v1:Mitigation: __user pointer sanitization > spectre_v2:Unknown > > AFAIK it has 4 Cortex-A53 cores (no PSCI firmware), so shouldn't be affected. So, for spec_store_bypass, as you noted your getting hit by the lack of psci/smccc to report the ssb state, and this patch is just reflecting that. In the case of spectrev2 it may be correct to blame this patch set because its displaying "unknown" since your core isn't in the black list, and your core isn't new enough to have the csv2 bit indicating its not vulnerable. In this case if we do away with the unknown state, we should probably depend entirely on the black list and simply display "Not affected" if the core isn't listed. (meaning we may report cores not affected when they are missing from the blacklist). > How can this be fixed? For ssb, the correct answer is probably fix the firmware, but given the situation, its likely this kind of machine is going to force an additional MIDR list to report the state correctly. Maybe Will or someone can chime in here? For spectrev2, wait for another version of this patch.
On Thu, Jan 03, 2019 at 02:32:44PM -0600, Jeremy Linton wrote: > On 01/03/2019 01:30 PM, Stefan Wahren wrote: > > > Jeremy Linton <jeremy.linton@arm.com> hat am 3. Januar 2019 um 17:46 geschrieben: > > > On 01/03/2019 10:37 AM, Dave Martin wrote: > > > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > > > > > There is a lot of variation in the Arm ecosystem. Because of this, > > > > > there exist possible cases where the kernel cannot authoritatively > > > > > determine if a machine is vulnerable. > > > > > > > > > > Rather than guess the vulnerability status in cases where > > > > > the mitigation is disabled or the firmware isn't responding > > > > > correctly, we need to display an "Unknown" state. > > > > > > > > > i applied your patch series on linux-next-20190103. On my Raspberry Pi 3B+ (defconfig) i'm getting this from sysfs: > > > > l1tf:Not affected > > meltdown:Not affected > > spec_store_bypass:Unknown > > spectre_v1:Mitigation: __user pointer sanitization > > spectre_v2:Unknown > > > > AFAIK it has 4 Cortex-A53 cores (no PSCI firmware), so shouldn't be affected. > > So, for spec_store_bypass, as you noted your getting hit by the lack of > psci/smccc to report the ssb state, and this patch is just reflecting that. > > In the case of spectrev2 it may be correct to blame this patch set because > its displaying "unknown" since your core isn't in the black list, and your > core isn't new enough to have the csv2 bit indicating its not vulnerable. In > this case if we do away with the unknown state, we should probably depend > entirely on the black list and simply display "Not affected" if the core > isn't listed. (meaning we may report cores not affected when they are > missing from the blacklist). > > > > How can this be fixed? > > For ssb, the correct answer is probably fix the firmware, but given the > situation, its likely this kind of machine is going to force an additional > MIDR list to report the state correctly. Maybe Will or someone can chime in > here? Marc Z is already working on this iirc, since we need it to fix the message printed to dmesg about the mitigation status anyway. Will
On Thu, Jan 03, 2019 at 05:48:31PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 03, 2019 at 10:38:16AM -0600, Jeremy Linton wrote: > > On 01/03/2019 03:38 AM, Greg Kroah-Hartman wrote: > > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > > > > There is a lot of variation in the Arm ecosystem. Because of this, > > > > there exist possible cases where the kernel cannot authoritatively > > > > determine if a machine is vulnerable. > > > > > > Really? Why not? What keeps you from "knowing" this? Can't the > > > developer of the chip tell you? > > > > There tends to be a few cases, possibly incomplete white/black lists, > > Then fix the lists :) > > > firmware that isn't responding correctly, or the user didn't build in the > > code to check the mitigation (possibly because its an embedded system and > > they know its not vulnerable?). > > If the firmware doesn't respond, that would imply it is vulnerable :) > > And if the code isn't built in, again, it's vulnerable. > > > I would hope that it is an exceptional case. > > Then have the default be vulnerable, don't give people false hope. > > > > > Rather than guess the vulnerability status in cases where > > > > the mitigation is disabled or the firmware isn't responding > > > > correctly, we need to display an "Unknown" state. > > > > > > Shouldn't "Unknown" really be the same thing as "Vulnerable"? A user > > > should treat it the same way, "Unknown" makes it feel like "maybe I can > > > just ignore this and hope I really am safe", which is not a good idea at > > > all. > > > > I tend to agree its not clear what to do with "unknown". > > > > OTOH, I think there is a hesitation to declare something vulnerable when it > > isn't. Meltdown for example, is fairly rare given that it currently only > > affects a few arm parts, so declaring someone vulnerable when they likely > > aren't is going to be just as difficult to explain. > > If you know it is rare, then you know how to properly detect it so > "unknown" is not needed, correct? > > Again, "unknown" is not going to help anyone out here, please don't do > it. Thinking about it, "unknown" is actually the common case. Kernels that predate the sysfs vulnerabilities interface effectively report this for all vulnerabilities by omitting the sysfs entries entirely. Current kernels also don't know anything about future vulnerabilities that may be added in sysfs later on (but which may nevertheless be discovered subsequently to affect current hardware). So, can we simply omit the sysfs entries for which we can't provide a good answer? IMHO the kernel should make best efforts to provide answers for every vulnerability that it knows about, so the checks should not be Kconfig- dependent without a good reason. There will be cases where whitelists/blacklists are the only source of answers, and we are ultimately reliant on vendors to provide that information. Upstream Linux is likely to lag, there's not much we can do about that. Cheers ---Dave
On Fri, Jan 04, 2019 at 02:08:32PM +0000, Dave Martin wrote: > On Thu, Jan 03, 2019 at 05:48:31PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Jan 03, 2019 at 10:38:16AM -0600, Jeremy Linton wrote: > > > On 01/03/2019 03:38 AM, Greg Kroah-Hartman wrote: > > > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > > > > > There is a lot of variation in the Arm ecosystem. Because of this, > > > > > there exist possible cases where the kernel cannot authoritatively > > > > > determine if a machine is vulnerable. > > > > > > > > Really? Why not? What keeps you from "knowing" this? Can't the > > > > developer of the chip tell you? > > > > > > There tends to be a few cases, possibly incomplete white/black lists, > > > > Then fix the lists :) > > > > > firmware that isn't responding correctly, or the user didn't build in the > > > code to check the mitigation (possibly because its an embedded system and > > > they know its not vulnerable?). > > > > If the firmware doesn't respond, that would imply it is vulnerable :) > > > > And if the code isn't built in, again, it's vulnerable. > > > > > I would hope that it is an exceptional case. > > > > Then have the default be vulnerable, don't give people false hope. > > > > > > > Rather than guess the vulnerability status in cases where > > > > > the mitigation is disabled or the firmware isn't responding > > > > > correctly, we need to display an "Unknown" state. > > > > > > > > Shouldn't "Unknown" really be the same thing as "Vulnerable"? A user > > > > should treat it the same way, "Unknown" makes it feel like "maybe I can > > > > just ignore this and hope I really am safe", which is not a good idea at > > > > all. > > > > > > I tend to agree its not clear what to do with "unknown". > > > > > > OTOH, I think there is a hesitation to declare something vulnerable when it > > > isn't. Meltdown for example, is fairly rare given that it currently only > > > affects a few arm parts, so declaring someone vulnerable when they likely > > > aren't is going to be just as difficult to explain. > > > > If you know it is rare, then you know how to properly detect it so > > "unknown" is not needed, correct? > > > > Again, "unknown" is not going to help anyone out here, please don't do > > it. > > Thinking about it, "unknown" is actually the common case. > > Kernels that predate the sysfs vulnerabilities interface effectively > report this for all vulnerabilities by omitting the sysfs entries > entirely. > > Current kernels also don't know anything about future vulnerabilities > that may be added in sysfs later on (but which may nevertheless be > discovered subsequently to affect current hardware). > > So, can we simply omit the sysfs entries for which we can't provide a > good answer? As you say, we already do this for older systems. But don't add new logic to explicitly not create the files just because we "can not figure it out". For those systems, I would default to "vulnerable" as I think that's what we do today, right? thanks, g reg k-h
On Fri, Jan 04, 2019 at 03:18:05PM +0100, Greg Kroah-Hartman wrote: > On Fri, Jan 04, 2019 at 02:08:32PM +0000, Dave Martin wrote: > > On Thu, Jan 03, 2019 at 05:48:31PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Jan 03, 2019 at 10:38:16AM -0600, Jeremy Linton wrote: > > > > On 01/03/2019 03:38 AM, Greg Kroah-Hartman wrote: > > > > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: > > > > > > There is a lot of variation in the Arm ecosystem. Because of this, > > > > > > there exist possible cases where the kernel cannot authoritatively > > > > > > determine if a machine is vulnerable. > > > > > > > > > > Really? Why not? What keeps you from "knowing" this? Can't the > > > > > developer of the chip tell you? > > > > > > > > There tends to be a few cases, possibly incomplete white/black lists, > > > > > > Then fix the lists :) > > > > > > > firmware that isn't responding correctly, or the user didn't build in the > > > > code to check the mitigation (possibly because its an embedded system and > > > > they know its not vulnerable?). > > > > > > If the firmware doesn't respond, that would imply it is vulnerable :) > > > > > > And if the code isn't built in, again, it's vulnerable. > > > > > > > I would hope that it is an exceptional case. > > > > > > Then have the default be vulnerable, don't give people false hope. > > > > > > > > > Rather than guess the vulnerability status in cases where > > > > > > the mitigation is disabled or the firmware isn't responding > > > > > > correctly, we need to display an "Unknown" state. > > > > > > > > > > Shouldn't "Unknown" really be the same thing as "Vulnerable"? A user > > > > > should treat it the same way, "Unknown" makes it feel like "maybe I can > > > > > just ignore this and hope I really am safe", which is not a good idea at > > > > > all. > > > > > > > > I tend to agree its not clear what to do with "unknown". > > > > > > > > OTOH, I think there is a hesitation to declare something vulnerable when it > > > > isn't. Meltdown for example, is fairly rare given that it currently only > > > > affects a few arm parts, so declaring someone vulnerable when they likely > > > > aren't is going to be just as difficult to explain. > > > > > > If you know it is rare, then you know how to properly detect it so > > > "unknown" is not needed, correct? > > > > > > Again, "unknown" is not going to help anyone out here, please don't do > > > it. > > > > Thinking about it, "unknown" is actually the common case. > > > > Kernels that predate the sysfs vulnerabilities interface effectively > > report this for all vulnerabilities by omitting the sysfs entries > > entirely. > > > > Current kernels also don't know anything about future vulnerabilities > > that may be added in sysfs later on (but which may nevertheless be > > discovered subsequently to affect current hardware). > > > > So, can we simply omit the sysfs entries for which we can't provide a > > good answer? > > As you say, we already do this for older systems. > > But don't add new logic to explicitly not create the files just because > we "can not figure it out". For those systems, I would default to > "vulnerable" as I think that's what we do today, right? Nope: currently the vulnerabilities directory doesn't even exist for arm64 because we don't select GENERIC_CPU_VULNERABILITIES. There are also a few other things to consider here: 1. The action to take as an end-user is slightly different in the case that you know for sure that your system is vulnerable, as opposed to the case that you don't know whether your system is vulnerable or not. The former needs a firmware update; the second needs a statement about the CPU, which could result in a simple whitelist update in Linux. 2. There's an unfortunate political angle to this. Whilst the Arm website [1] provides information for all of the Arm-designed CPUs (i.e. Cortex-A*), it doesn't comment on partner implementations. I'm not at all keen to be seen as branding them all as vulnerable in the Linux kernel, as this is likely to cause more problems than it solves. If we had complete whitelist information available in public, that would be ideal, but it's not the case. 3. The architecture has added some ID registers to determine if a CPU is affected by Spectre and Meltdown, so a whitelist only needs to cover existing CPUs. So I agree with Dave that continuing to omit the files when we don't know whether or not the system is affected is the right thing to do. Will [1] https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 9605dbd4b5b5..876103fddfa4 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -495,6 +495,7 @@ Description: Information about CPU vulnerabilities "Not affected" CPU is not affected by the vulnerability "Vulnerable" CPU is affected and no mitigation in effect "Mitigation: $M" CPU is affected and mitigation $M is in effect + "Unknown" The kernel is unable to make a determination Details about the l1tf file can be found in Documentation/admin-guide/l1tf.rst
There is a lot of variation in the Arm ecosystem. Because of this, there exist possible cases where the kernel cannot authoritatively determine if a machine is vulnerable. Rather than guess the vulnerability status in cases where the mitigation is disabled or the firmware isn't responding correctly, we need to display an "Unknown" state. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: David Woodhouse <dwmw@amazon.co.uk> --- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + 1 file changed, 1 insertion(+) -- 2.17.2