There has been lots of discussion here, but nobody asked if ramstage is really the right place to do that: Disabling bus master for TBT is to prevent wild (potentially hostile) DMA accesses early on in the boot cycle, right? Ideally we'd do that in the bootblock, or in romstage before RAM is available or used for anything, at any rate.

If we're deferring this to ramstage, an attacker could just overwrite the ramstage before its executed: blast the entry point with "jmp -1" for 5 seconds, then write whatever code they really want to see executed somewhere and overwrite the jmp again. Since we're typically decompressing the ramstage, and decompression works from low to high addresses, while the entry point is at the beginning, it shouldn't even be hard to win that race.

Is bus mastering enabled early, though? It would be nice to document
the reset state and if FSP does anything about it.

Beside that, I doubt that this is TBT specific. We shouldn't enable
BM for anything that we don't use. 99% of the BM enable settings in
coreboot seem more like a bug than a feature. I do understand that
this might not be the right time to clean it up. But I'm with Patrick
here, we should prevent that BM gets enabled at all (or disable it as
early as possible if it's enabled due to some bug that can't be fixed),
not disable it at a random point later just to comply with a document.

View Change

To view, visit change 40968. To unsubscribe, or for help writing mail filters, visit settings.