[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <539ad252-599f-1be5-3bde-196829929af2@intel.com>
Date: Thu, 18 Jun 2020 07:09:15 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: John Andersen <john.s.andersen@...el.com>, corbet@....net,
pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
x86@...nel.org, hpa@...or.com, shuah@...nel.org,
sean.j.christopherson@...el.com, liran.alon@...cle.com, drjones@...hat.com,
rick.p.edgecombe@...el.com, kristen@...ux.intel.com
Cc: vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
joro@...tes.org, mchehab+huawei@...nel.org, gregkh@...uxfoundation.org,
paulmck@...nel.org, pawan.kumar.gupta@...ux.intel.com, jgross@...e.com,
mike.kravetz@...cle.com, oneukum@...e.com, luto@...nel.org,
peterz@...radead.org, fenghua.yu@...el.com, reinette.chatre@...el.com,
vineela.tummalapalli@...el.com, dave.hansen@...ux.intel.com,
arjan@...ux.intel.com, caoj.fnst@...fujitsu.com, bhe@...hat.com,
nivedita@...m.mit.edu, keescook@...omium.org, dan.j.williams@...el.com,
eric.auger@...hat.com, aaronlewis@...gle.com, peterx@...hat.com,
makarandsonare@...gle.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-kselftest@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 1/4] X86: Update mmu_cr4_features during feature
identification
Overall this looks pretty good. For all the maintainers on cc, we try
to do internal reviews of these before they're submitted. This one got
missed, sorry about that.
On 6/17/20 12:07 PM, John Andersen wrote:
> In identify_cpu when setting up SMEP/SMAP/UMIP call
> cr4_set_bits_and_update_boot instead of cr4_set_bits. This ensures that
> mmu_cr4_features contains those bits, and does not disable those
> protections when in hibernation asm.
When I'm writing comments, I try to use parenthesis for functions(),
which leaves variable_names plain.
I also try not to dive directly into the function names. This
description assumes that the reader knows the subtle difference between
cr4_set_bits_and_update_boot() and of cr4_set_bits(). A sentence or two
of background here can save a reviewer a dive into the source code.
> setup_arch updates mmu_cr4_features to save what identified features are
> supported for later use in hibernation asm when cr4 needs to be modified
> to toggle PGE. cr4 writes happen in restore_image and restore_registers.
> setup_arch occurs before identify_cpu, this leads to mmu_cr4_features
> not containing some of the cr4 features which were enabled via
> identify_cpu when hibernation asm is executed.
This fails to address the bigger picture. I assume you end up wanting
this because without it hibernation is not compatible with CR pinning.
Shouldn't that be mentioned?
I also wonder why we even need two classes of cr4_set_bits(). Are there
features we *want* to disable before entering the hibernation assembly?
For instance, why not leave MCE enabled in there? What about PCIDs or
OSPKE? Does it hurt?
> On CPU bringup when cr4_set_bits_and_update_boot is called
> mmu_cr4_features will now be written to. For the boot CPU, the
> __ro_after_init on mmu_cr4_features does not cause a fault. However,
> __ro_after_init was removed due to it triggering faults on non-boot
> CPUs
Before this patch, cr4_set_bits_and_update_boot() was only ever called
during init. But, after this patch, it gets called later in boot and
causes problems. We're surely not making _real_ updates to it, right?
In that case the writes are superfluous and we would be better off just
not writing to it (and retaining __ro_after_init) rather than allowing
superfluous writes.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
