Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 01 Jul 2016 13:12:55 -0500 | Subject | Re: [PATCH 6/6] x86: Fix stray A/D bit setting into non-present PTEs |
| |
Dave Hansen <dave@sr71.net> writes:
> On 07/01/2016 07:25 AM, Eric W. Biederman wrote: >> Linus Torvalds <torvalds@linux-foundation.org> writes: >>> > On Thu, Jun 30, 2016 at 9:39 PM, Dave Hansen <dave@sr71.net> wrote: >>>> >> >>>> >> I think what you suggest will work if we don't consider A/D in >>>> >> pte_none(). I think there are a bunch of code path where assume that >>>> >> !pte_present() && !pte_none() means swap. >>> > >>> > Yeah, we would need to change pte_none() to mask off D/A, but I think >>> > that might be the only real change needed (other than making sure that >>> > we don't use the bits in the swap entries, I didn't look at that part >>> > at all) >> It looks like __pte_to_swp_entry also needs to be changed to mask out >> those bits when the swap code reads pte entries. For all of the same >> reasons as pte_none. > > I guess that would be nice, but isn't it redundant? > > static inline swp_entry_t pte_to_swp_entry(pte_t pte) > { > ... > arch_entry = __pte_to_swp_entry(pte); > return swp_entry(__swp_type(arch_entry), __swp_offset(arch_entry)); > } > > As long as __swp_type() and __swp_offset() don't let A/D through, then > we should be OK. This site is the only call to __pte_to_swp_entry() > that I can find in the entire codebase. > > Or am I missing something?
Given that __pte_to_swp_entry on x86_64 is just __pte_val or pte.pte it does no filtering. Similarly __swp_type(arch_entry) is a >> and swp_entry(type, ...) is a << of what appears to be same amount for the swap type.
So any corruption in the upper bits of the pte will be preserved as a swap type.
In fact I strongly suspect that the compiler can optimize out all of the work done by "swp_entry(__swp_type(arch_entry), _swp_offset(arch_entry))".
Eric
| |