Hi! > > It falls there so that the cpu only issues reads with known good 'index' values. > > > >> I suspect it would be better to have those barriers in the tun/tap > >> interfaces where userspace can inject packets and thus time them. Then > >> the code could still speculate and go fast for remote packets. > >> > >> Or does the speculation stomping have to be immediately at the place > >> where we use data from userspace to perform a table lookup? > > > > The speculation stomping barrier has to be between where we validate > > the input and when we may speculate on invalid input. > > So a serializing instruction at the kernel/user boundary (like say > loading cr3) is not enough? That would seem to break any chance of a > controlled timing. Timing attack is not as straightforward as this. You can assume cache snooping from second CPU _while_ kernel is executing. Yes, that will mean timing, but.... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
