mbox series

[0/2] Fix W+X debug feature on x86

Message ID 20200521152308.33096-1-steven.price@arm.com (mailing list archive)
Headers show
Series Fix W+X debug feature on x86 | expand

Message

Steven Price May 21, 2020, 3:23 p.m. UTC
Jan alert me[1] that the W+X detection debug feature was broken in x86
by my change[2] to switch x86 to use the generic ptdump infrastructure.

Fundamentally the approach of trying to move the calculation of
effective permissions into note_page() was broken because note_page() is
only called for 'leaf' entries and the effective permissions are passed
down via the internal nodes of the page tree. The solution I've taken
here is to create a new (optional) callback which is called for all
nodes of the page tree and therefore can calculate the effective
permissions.

Secondly on some configurations (32 bit with PAE) "unsigned long" is not
large enough to store the table entries. The fix here is simple - let's
just use a u64.

I'd welcome testing (and other comments), especially if you have a
configuration which previously triggered W+X warnings as I don't have
such a setup.

[1] https://lore.kernel.org/lkml/d573dc7e-e742-84de-473d-f971142fa319@suse.com/
[2] 2ae27137b2db ("x86: mm: convert dump_pagetables to use walk_page_range")

Steven Price (2):
  x86: mm: ptdump: Calculate effective permissions correctly
  mm: ptdump: Expand type of 'val' in note_page()

 arch/arm64/mm/dump.c          |  2 +-
 arch/x86/mm/dump_pagetables.c | 33 ++++++++++++++++++++-------------
 include/linux/ptdump.h        |  3 ++-
 mm/ptdump.c                   | 17 ++++++++++++++++-
 4 files changed, 39 insertions(+), 16 deletions(-)

Comments

Andrew Morton May 21, 2020, 7:08 p.m. UTC | #1
On Thu, 21 May 2020 16:23:06 +0100 Steven Price <steven.price@arm.com> wrote:

> Jan alert me[1] that the W+X detection debug feature was broken in x86
> by my change[2] to switch x86 to use the generic ptdump infrastructure.
> 
> Fundamentally the approach of trying to move the calculation of
> effective permissions into note_page() was broken because note_page() is
> only called for 'leaf' entries and the effective permissions are passed
> down via the internal nodes of the page tree. The solution I've taken
> here is to create a new (optional) callback which is called for all
> nodes of the page tree and therefore can calculate the effective
> permissions.
> 
> Secondly on some configurations (32 bit with PAE) "unsigned long" is not
> large enough to store the table entries. The fix here is simple - let's
> just use a u64.

I assumed that a cc:stable was appropriate on both of these(?).

> I'd welcome testing (and other comments), especially if you have a
> configuration which previously triggered W+X warnings as I don't have
> such a setup.

I'll wait a while for such testing.  If nothing happens then I guess we
merge it up and see what then happens.
Steven Price May 22, 2020, 12:50 p.m. UTC | #2
On 21/05/2020 20:08, Andrew Morton wrote:
> On Thu, 21 May 2020 16:23:06 +0100 Steven Price <steven.price@arm.com> wrote:
> 
>> Jan alert me[1] that the W+X detection debug feature was broken in x86
>> by my change[2] to switch x86 to use the generic ptdump infrastructure.
>>
>> Fundamentally the approach of trying to move the calculation of
>> effective permissions into note_page() was broken because note_page() is
>> only called for 'leaf' entries and the effective permissions are passed
>> down via the internal nodes of the page tree. The solution I've taken
>> here is to create a new (optional) callback which is called for all
>> nodes of the page tree and therefore can calculate the effective
>> permissions.
>>
>> Secondly on some configurations (32 bit with PAE) "unsigned long" is not
>> large enough to store the table entries. The fix here is simple - let's
>> just use a u64.
> 
> I assumed that a cc:stable was appropriate on both of these(?).

Yes thanks.

>> I'd welcome testing (and other comments), especially if you have a
>> configuration which previously triggered W+X warnings as I don't have
>> such a setup.
> 
> I'll wait a while for such testing.  If nothing happens then I guess we
> merge it up and see what then happens.
> 

Thanks,

Steve