- #Tenfourfox no encryption overlap full
- #Tenfourfox no encryption overlap software
- #Tenfourfox no encryption overlap code
It purges the L1 upon exiting the kernel or hypervisor, since it apparently does catch permissions violations if a load misses the L1. Perhaps a variation on what is being done to counteract Meltdown in Power? Maybe expand the role of the line fill buffers to delay booting things out of the L1, although that's a complex set of areas to change. Not knowing the details of the hardware, perhaps there's enough information nearby for the pipeline to trap out if it detects a subset of instructions that can generate side-effects not rolled back by standard misprediction handling.Īdding a new cache partition seems expensive, and not speculating at all seems impractical.
#Tenfourfox no encryption overlap software
Spectre is the more pervasive one, and if Intel means no software workarounds like serializing before branch checks, retpolines, and the indirect branch control instructions and barriers, I'm curious what would be changed in what is publicly a short time across multiple hardware units and scenarios. That wouldn't necessarily require new behaviors in the rest of the chip. If that part isn't changed, perhaps the load pipeline can be made to disable forwarding or zero out the value in the faulting scenario.
#Tenfourfox no encryption overlap code
If the hardware is positioned to know that it's in the scenario where user code is hitting a kernel address, it might suppress the operation like AMD does with its specific check. Meltdown might be amenable to something of a quicker fix. How long Intel had to make changes or how hacky they may be is uncertain. Tapeout to launch of a chip this year could take 2-3 quarters. Google became aware of the exploits last June. Given the lag time for significant design changes, I'm curious what could be done. I've stated that I hope the stakeholders do get together to forge a comprehensive framework for defining and measuring such concerns, rather than fixing the immediate exploit at hand and winding up caught out by a new one years down the road and having a similar learning curve under pressure. That doesn't resolve the question about why IBRS might be open-ended, and whether it's iffy because it's a rough but functional hack that will be forgotten in the future or if it's more portentous.
#Tenfourfox no encryption overlap full
There may still be specific (perhaps near-zero probability ones in AMD's parlance) corner cases that Skylake may have if it doesn't have the full measure, so the next step would be to have further debate and explicit decision-making on what's good enough.
The predictor gets wiped if it happens, which is significantly lower-overhead than some of the hundreds or thousands of cycles associated with some of the microcoded functions. Using the stack trace functionality already in place, the kernel can determine if the call stack has gotten 16 deep, the threshold that might make Skylake escape retpoline coverage. IBRS functions as a form of barrier and so some of its behaviors are more complicated than a dedicated instruction or simple mode switch.įurther, IBRS is less of a penalty for Skylake, and might actually allow Skylake to fall back to a simplified retpoline (perhaps akin to what AMD gets).Įven further down the chain, it seems like someone brainstormed up a potentially more elegant fix, at least for Linux. The ugly IBRS persists despite retpoline particularly for Skylake (or one of its variants) because Skylake's architecture falls back to its more standard prediction pipeline in a manner that leaves retpoline as an incomplete solution. Retpoline has generally replaced the need for the heaviest IBRS involvement, although it was kept on for areas where coverage was uncertain and for further discussion about trade-offs. The bit related to Meltdown is a flag that effectively states "not fixed" and "fixed" going forward.įollowing the chain, the major motivators for some of the most complicated IBRS changes were related to mitigation measures underway prior to the retpoline trick being introduced. The former seems to leave an open-ended commitment to Spectre persisting with seemingly arbitrary compromises to security possible forever more. One part that Torvalds objected to in particular was the implication that the IBRS status bits involved in Spectre mitigation are not implemented in the same manner as the Meltdown status bit. *Note: the peanut gallery mentioned would likely include us. Outsiders fixating on the fireworks is an unfortunate side effect of open discussion, although in this case it did seem to prompt a later explanation of some of the details: While this is a public email chain, this is still a back and forth discussion that's generally treated by its participants in a more informal style-as Torvalds does.Ī single email is not a final judgement or the end of the matter. I think the discussion that follows is interesting. From my limited sampling of such discussions and articles that quote or mention him, I'm not sure that's all that special.
0 kommentar(er)
