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 > > [email protected] > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
