On 01/02/2017 09:48 PM, [email protected] wrote: > I think the only concern with this is it still adds more checks and > conditionals to the thread switching code. Whilst minimal, these can add > up with enough features like these, so would want some decent > motivation. That said, having the support be a build time option would > somewhat circumvent that whole problem. >
Fair. I wouldn't mind a build option. > Once more people are back from holidays I can bring up this discussion > internally, although it might be useful to have a more detailed use case > and threat model that you are trying to defend against. > My potential use case is depriving threads access to a high-quality source of timestamps with the hope of thwarting potential side channel attacks. I still haven't fully thought out how to close the shared memory timing hole (where another thread, in parallel, atomically increments some value as fast as it can, which the spy thread uses as its timestamp). Note that I consider cache coloring too expensive for Robigalia's usecases, so I've been looking for other ways to try and close those holes. > Adrian > > On Fri 23-Dec-2016 10:38 PM, Corey Richardson wrote: >> How do people feel about exposing the TSD (time-stamp disable) bit as a >> piece of state on the TCB? Ideally it'd be lazily switched. I vaguely >> want this in Robigalia for disabling access to real time in >> non-sufficiently-privileged processes. >> >> Best, >> >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> https://sel4.systems/lists/listinfo/devel > -- cmr http://octayn.net/ +16038524272
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
