On 9/5/25 02:51, Orzel, Michal wrote:
> 
> 
> On 05/09/2025 05:47, Demi Marie Obenour wrote:
>> Right now, both EXPERT and UNSUPPORTED options are
>> not security supported.  However, this seems to be
>> causing problems for safety-certified use-cases.
>>
>> Specifically, disabling AMD or Intel support is certainly
>> something that should fall under EXPERT IMO, as it is a
>> great way to produce a Xen binary that will not boot on
>> a large fraction of hardware.  However, I see no fundamental
>> reason it should not be security supported.  Not security
>> supporting it means that those producing safety-certified
>> builds of Xen (which, presumably, are some of the most
>> security-critical there are!) are having to use
>> security-unsupported configurations.
>>
>> This definitely does not seem right to me.  Safety
>> certification and security support should go hand in hand,
>> not conflict with each other!  Is there a plan to address this?
> What makes you say that? Functional safety and security, although often
> intertwined differ in focus areas and objectives. Functional safety aims
> at reducing the risk of unintended hazards caused by malfunction of system
> components, whereas security is about reducing the risk of intentional 
> threats.
> There are different standards for safety and security. Current AMD safety work
> focuses on ISO26262 and IEC61508 but there are security standards like ISO/SAE
> 21434.
There have been cases of vehicles being compromised remotely.
Intentionally reducing the security of a system in the name of
safety does not seem like a good tradeoff compared to achieving
both, especially when (as here) the problem is purely a procedural
one and not technical.

A car that can be hijacked by a remote attacker is not safe, and
cars have been recalled in the past because of this.  My
understanding is that AMD's threat model includes the
non-certified OSs being compromised, so safety requires security
(though not the other way around).
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to