[cip-dev] Meltdown and Spectre in CIP

[cip-dev] Meltdown and Spectre in CIP

[Ben Hutchings]

I expect that everyone's heard about the above security issues and I
understand there have been questions about how and when these will be
addressed in CIP.

My thinking is that for these are *not* serious issues for embedded
systems, though they do weaken the "defence in depth" that is normally
provided by memory protection and user privilege separation.??We do
need to get fixes out, but not urgently.

(When we discussed kernel configurations and maintainability, there was
consensus that no-one using KVM was relying on it being secure against
malicious guests - the guests were trusted.)

This is the current status of mitigations for these issues, as I
understand it:

Meltdown:
- arm 32-bit: Not affected?  (ARM reports that only the Cortex-A75 is
  affected, but I haven't seen information from other architecture
  licensees.)
- x86 32-bit: Not fixed, no plans to fix.  There are two affected
  configurations that I'm aware of: Siemens' i386-rt and iot2000.
  I doubt that the Quark processor in iot2000 is affected.
- x86 64-bit: Fully mitigated in mainline and 4.4-stable.

Spectre: will be mitigated in mainline, but still under discussion. 
Based on what I've seen, I expect that it will be possible to backport
most of these to 4.4.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[cip-dev] Meltdown and Spectre in CIP

[Chris Paterson]

Hello Ben,

Thank you for the summary.

> From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-
> bounces at lists.cip-project.org] On Behalf Of Ben Hutchings
> Sent: 10 January 2018 14:17
> 
> I expect that everyone's heard about the above security issues and I
> understand there have been questions about how and when these will be
> addressed in CIP.
> 
> My thinking is that for these are *not* serious issues for embedded systems,
> though they do weaken the "defence in depth" that is normally provided by
> memory protection and user privilege separation.??We do need to get fixes
> out, but not urgently.
> 
> (When we discussed kernel configurations and maintainability, there was
> consensus that no-one using KVM was relying on it being secure against
> malicious guests - the guests were trusted.)
> 
> This is the current status of mitigations for these issues, as I understand it:
> 
> Meltdown:
> - arm 32-bit: Not affected?  (ARM reports that only the Cortex-A75 is
>   affected, but I haven't seen information from other architecture
>   licensees.)

ARM also lists that meltdown subvariant '3a' affects some arm 32-bit processors [1], but say that "In general, it is not believed that software mitigations for this issue are necessary".

The whitepaper ARM link to [2] implies that ARM don't think this is an issue worth worrying about as the information that can be obtained from the system registers is "not material".

Have you heard/seen anything to contradict this statement?


> - x86 32-bit: Not fixed, no plans to fix.  There are two affected
>   configurations that I'm aware of: Siemens' i386-rt and iot2000.
>   I doubt that the Quark processor in iot2000 is affected.
> - x86 64-bit: Fully mitigated in mainline and 4.4-stable.
> 
> Spectre: will be mitigated in mainline, but still under discussion.
> Based on what I've seen, I expect that it will be possible to backport most of
> these to 4.4.

Will you be keeping an eye on Spectre patches on behalf of CIP as part of your maintainer role? I guess you may be in the loop a bit more than the rest of us?


[1] https://developer.arm.com/support/security-update
[2] https://developer.arm.com/support/security-update/download-the-whitepaper

Kind regards, Chris

[cip-dev] Meltdown and Spectre in CIP

[Ben Hutchings]

On Tue, 2018-01-16 at 08:01 +0000, Chris Paterson wrote:
[...]
> > Meltdown:
> > - arm 32-bit: Not affected???(ARM reports that only the Cortex-A75 is
> > ? affected, but I haven't seen information from other architecture
> > ? licensees.)
> 
> ARM also lists that meltdown subvariant '3a' affects some arm 32-bit
> processors [1], but say that "In general, it is not believed that
> software mitigations for this issue are necessary".
> 
> The whitepaper ARM link to [2] implies that ARM don't think this is
> an issue worth worrying about as the information that can be obtained
> from the system registers is "not material".
> 
> Have you heard/seen anything to contradict this statement?

No I haven't.

[...]
> Will you be keeping an eye on Spectre patches on behalf of CIP as
> part of your maintainer role? I guess you may be in the loop a bit
> more than the rest of us?

I will look at the mitigations as they land upstream, but I still think
these are low priority security issues for CIP.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[cip-dev] Meltdown and Spectre in CIP

[Jan Kiszka]

On 2018-02-15 12:44, Ben Hutchings wrote:
> [...]
>> Will you be keeping an eye on Spectre patches on behalf of CIP as
>> part of your maintainer role? I guess you may be in the loop a bit
>> more than the rest of us?
> 
> I will look at the mitigations as they land upstream, but I still think
> these are low priority security issues for CIP.

The priority starts to rise here because new system are coming out that
need to start system testing and other processes on a CIP kernel with
Spectre mitigations (x86 so far). Can you estimate the time needed for a
cip19 release?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] Meltdown and Spectre in CIP

[Ben Hutchings]

Here's the status of these issues, as of today's kernel release
(4.4.120-cip20).

On Wed, 2018-01-10 at 14:16 +0000, Ben Hutchings wrote:
> Meltdown:
> - arm 32-bit: Not affected???(ARM reports that only the Cortex-A75 is
> ? affected, but I haven't seen information from other architecture
> ? licensees.)

As Chris pointed out, some 32-bit ARM cores are affected by a variant
of Meltdown, though ARM claims that this variant is unlikely to leak
sensitive information.  In any case, there is no sign of any mitigation
in mainline, which would be a prerequisite for addressing it in the CIP
kernel.

> - x86 32-bit: Not fixed, no plans to fix.??There are two affected
> ? configurations that I'm aware of: Siemens' i386-rt and iot2000.
> ? I doubt that the Quark processor in iot2000 is affected.
> - x86 64-bit: Fully mitigated in mainline and 4.4-stable.

This is not quite accurate.  The 4.14-stable branch and later versions
use per-CPU entry stacks, allowing normal kernel stacks to be excluded
from the user-mode page tables.  KAISER, used in older branches
including 4.4, does not do this, so kernel stacks are still vulnerable
to information leaks.

> Spectre: will be mitigated in mainline, but still under discussion.?
> Based on what I've seen, I expect that it will be possible to backport
> most of these to 4.4.

Spectre variant 1 is being mitigated by adding a masking operation
after each sensitive range check, mostly using the generic
array_index_nospec() function.  This has been done for some generic and
x86-specific code, and backported to the 4.4 CIP kernel.

Spectre variant 2 is being mitigated for x86 using "retpoline" (for
indirect calls) and filling the return stack buffer (for returns). 
This has been backported to the 4.4 CIP kernel.  The retpoline feature
requires a new compiler - gcc 7.3, or a version with retpoline support
backported.  The default versions of gcc in Debian 8 (jessie) and 9
(stretch) include this.

Mainline Linux has additional mitigations for Spectre variant 2 on x86,
using new microcoded CPU features (IBPB and IBRS).  These have *not*
been backported to 4.4 and are not included in the CIP kernel.  There
have also been some changes to the kernel entry code that clear several
registers.  These have also not been backported.

I don't see any sign of Spectre being addressed for 32-bit ARM yet.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.