Messages in this thread | | | Date | Mon, 14 Aug 2023 13:01:28 -0700 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v2 00/11] Fix up SRSO stuff |
| |
On Mon, Aug 14, 2023 at 12:51:55PM -0700, Josh Poimboeuf wrote: > On Mon, Aug 14, 2023 at 06:44:47PM +0200, Borislav Petkov wrote: > > On Mon, Aug 14, 2023 at 01:44:26PM +0200, Peter Zijlstra wrote: > > > The one open techinical issue I have with the mitigation is the alignment of > > > the RET inside srso_safe_ret(). The details given for retbleed stated that RET > > > should be on a 64byte boundary, which is not the case here. > > > > I have written this in the hope to make this more clear: > > > > /* > > * Some generic notes on the untraining sequences: > > * > > * They are interchangeable when it comes to flushing potentially wrong > > * RET predictions from the BTB. > > * > > * The SRSO Zen1/2 (MOVABS) untraining sequence is longer than the > > * Retbleed sequence because the return sequence done there > > * (srso_safe_ret()) is longer and the return sequence must fully nest > > * (end before) the untraining sequence. Therefore, the untraining > > * sequence must overlap the return sequence. > > * > > * Regarding alignment - the instructions which need to be untrained, > > * must all start at a cacheline boundary for Zen1/2 generations. That > > * is, both the ret in zen_untrain_ret() and srso_safe_ret() in the > > * srso_untrain_ret() must both be placed at the beginning of > > * a cacheline. > > */ > > It's a good comment, but RET in srso_safe_ret() is still misaligned. > Don't we need something like so?
Scratch that, I guess I misread the confusingly worded comment:
"both the ret in zen_untrain_ret() and srso_safe_ret()..."
to mean the RET in each function.
How about:
"both the RET in zen_untrain_ret() and the LEA in srso_untrain_ret()"
?
-- Josh
| |