Hello,
Can we add a discussion in upcoming meetings about the participation of SMMU in the booting procedure?
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 etc
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? If we enable if a number of questions will rise as well such as, What happens if the SMMU is already configured? Should the OS reconfigure it ?
/Ilias
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.
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].
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.
On Tue, Oct 02, 2018 at 02:02:11PM +0100, 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.
Ok will do that
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").
Me neither
Basically EBBR primarily focuses on the handover from system firmware to OS[1].
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.
Well i'd replace BL<something> with 'once the bus is configured'. In other words if a peripheral that's connected to the SMMU is required to do transactions SMMU should be up and running. If no device is going to do transactions the SMMU can be ignored. Again i am not entirely sure this is an EBBR decision to make
Thanks /Ilias
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-discuss@arm.com
On Wed, Oct 03, 2018 at 03:55:45PM +0100, Grant Likely wrote:
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.
Agree. There can be good reasons for this (it's why I used weasel phrasing like primarily). However I'm not of the view that standards are the best place to tackle implementation quality issues, at least not before a conformance testing approach is clear.
Daniel.
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-discuss@arm.com
boot-architecture@lists.linaro.org
-
Daniel Thompson -
Grant Likely -
Ilias Apalodimas