On 02/10/2018 14:02, Daniel Thompson wrote:
On 25/09/2018 10:07, Ilias Apalodimas wrote:
Hello,

Can we add a discussion in upcoming meetings about the participation
of SMMU in the booting procedure?

If I were you I'd roll up to one of the Thursday meetings. There's usually time for a bit of any other business.

I'll add it to the agenda.

In the past there's been a number of proposals on how to mitigate
attacks, were a rogue PCI card is inserted into the system.
Some of them include shutting down external DMA ports until the OS
explicitly powers them up or blocking DMA using BME bit et >
Keeping in mind this will enhance the security of devices would it
make sense to include it as a 'MUST' if the hardware is present or a
recommendation would be enough?

I'm not totally convinced this is in scope for EBBR (don't take this as a firm "no").

Basically EBBR primarily focuses on the handover from system firmware to OS[1].

Not entirely true. EBBR is a set of requirements on the system with regard to boot. We've definitely focused on the handover aspect, which is mostly interpretation of UEFI, plus covering areas UEFI doesn't touch like firmware stored on the block device. That has been the driver because it is necessary to get something supportable by distros.

However, it is appropriate to add additional requirements on system implementation/behaviour that goes beyond UEFI handover state.

It is hard to say on this particular topic on whether we want it in EBBR because these kinds of things can have wide ranging impact. It may be better in a separate spec that specifically addresses building secure platforms, but we can certainly discuss it in the EBBR meeting.

g.



For full defense this is essentially a requirement about the state of the system when we hand over from BL<something> to BL33 isn't it? It might therefore be regarded as an implementation quality issue.


Daniel.


[1] It is true we have contemplated (but haven't yet acted
     on) imposing also imposing requirements on boot ROMs but this is
     only really to try and squash (mis)features that impose a
     requirement to pre-partition the media the OS will install onto.
_______________________________________________
Arm.ebbr-discuss mailing list
arm.ebbr-disc...@arm.com

_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to