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.lin...@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
