(resent with Matt's email address fixed.) * Ingo Molnar <mi...@kernel.org> wrote:
> > * Linus Torvalds <torva...@linux-foundation.org> wrote: > > > On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones <da...@codemonkey.org.uk> wrote: > > > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote: > > > > > > > > I don't have that later debug output at all. Presumably some config > > > difference. > > > > > > CONFIG_X86_PTDUMP_CORE iirc. > > > > No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead. > > > > Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should > > not default to 'y' unless it is made more useful if it actually > > triggers. Ingo? > > Yeah, agreed absolutely. > > So this is a bit sad because RWX pages are a real problem in practice, > especially > since the EFI addresses are well predictable, but generating a warning > without > being able to fix it quickly is counterproductive as well, as it only annoys > people and makes them turn off the option. (Which we could do as well to > begin > with, without the annoyance factor...) > > So the plan would be: > > 1) Make it default-n. > > 2) We should try to further improve the messages to make it easier to > determine > what's wrong. We _do_ try to output symbolic information in the warning, > to > make it easier to find buggy mappings, but these are not standard kernel > mappings. So I think we need an e820 mappings based semi-symbolic > printout of > bad addresses - maybe even correlate it with the MMIO resource tree. > > 3) We should fix the EFI permission problem without relying on the firmware: > it > appears we could just mark everything R-X optimistically, and if a write > fault > happens (it's pretty rare in fact, only triggers when we write to an EFI > variable and so), we can mark the faulting page RW- on the fly, because > it > appears that writable EFI sections, while not enumerated very well in > 'old' > firmware, are still supposed to be page granular. (Even 'new' firmware I > wouldn't automatically trust to get the enumeration right...) > > If that 'supposed to be' turns out to be 'not true' (not unheard of in > firmware land), then plan B would be to mark pages that generate write > faults > RWX as well, to not break functionality. (This 'mark it RWX' is not > something > that exploits would have easy access to, and we could also generate a > warning > [after the EFI call has finished] if it ever triggers.) > > Admittedly this approach might not be without its own complications, but > it > looks reasonably simple (I don't think we need per EFI call page tables, > etc.), and does not assume much about the firmware being able to > enumerate its > permissions properly. Were we to merge EFI support today I'd have > insisted on > trying such an approach from day 1 on. > > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
