public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: Ingo Molnar <mingo@elte.hu>, Rafa? Mi?ecki <zajec5@gmail.com>,
	Alan Jenkins <alan-jenkins@tuffmail.co.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption
Date: Mon, 08 Sep 2008 12:45:02 -0700	[thread overview]
Message-ID: <48C580BE.8060207@goop.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0809081956390.23187@blonde.site>

Hugh Dickins wrote:
> On Mon, 8 Sep 2008, Jeremy Fitzhardinge wrote:
>   
>> Well, if we never want the direct map to be non-executable (which I
>>     
>
> One too many negatives?
>   

Yes.  I over-corrected in my pre-send proofread.

>> think would be OK, since all the code is either core kernel or modules
>> which are mapped elsewhere),
>>     
>
> I had thought so until just before replying.
>
>   
>> then we can set NX on the level4 for the
>> linear mapping which will make everything below non-executable.
>>     
>
> That would be much the neatest answer: I hadn't realized
> that inheritance (perhaps I'm still living in early-i386 days,
> when IIRC there was a bug in inheriting WP from higher levels).
>   

In PAE mode the top-level doesn't let you set inheritable permissions
flags.  On i386 it only works on levels 2 and 1, but 64-bit fixes it to
work on all levels.

> But then I stumbled across static_protections() in pageattr.c
> (takes both addr and pfn, latter seems weird),

Well, it wants to set the mappings for some physical memory in the case
of BIOS and RO data, but only affect the kernel mappings in a particular
virtual range (so the linear mapping of the kernel is still NX).   (No
need for it to be inline though.)

But it does seem it wants the BIOS to be executable when you're using it
for PCI space.  A possible fix in that case is to create a separate
executable mapping of BIOS space.

That said, PCI_GOBIOS is only used on 32-bit anyway, so it's moot (its
only use is to define CONFIG_PCI_BIOS, and it depends on X86_32).

> A simple answer might be to go the way you suggest, but remove
> the special casing from pageattr.c and ioremap.c; but I fear
> that will slow something down, or introduce further bugs.
>   

It looks to me like it won't matter either way.

    J

  reply	other threads:[~2008-09-08 19:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-28 19:52 [PATCH RFC] x86: check for and defend against BIOS memory corruption Jeremy Fitzhardinge
2008-08-29  1:49 ` Yinghai Lu
2008-08-29  3:28   ` Jeremy Fitzhardinge
2008-08-29  9:25     ` Alan Cox
2008-08-29 10:13       ` Rafał Miłecki
2008-08-29 10:06         ` Alan Cox
2008-08-29 10:24         ` Hugh Dickins
2008-08-29 11:54           ` Rafał Miłecki
2008-08-29 12:09             ` Alan Jenkins
2008-08-29 13:21               ` Hugh Dickins
2008-08-29 16:30                 ` Rafał Miłecki
2008-08-29 17:39                 ` Rafał Miłecki
2008-09-04 19:42                   ` Rafał Miłecki
2008-09-04 20:23                     ` Hugh Dickins
2008-09-04 23:04                       ` Jeremy Fitzhardinge
2008-09-06 18:09                         ` Ingo Molnar
2008-08-29 14:08           ` Jeremy Fitzhardinge
2008-08-29 14:18       ` Jeremy Fitzhardinge
2008-08-29 20:31     ` Kasper Sandberg
2008-08-30  1:15       ` Jeremy Fitzhardinge
2008-08-29  6:20 ` Rafał Miłecki
2008-08-29  6:45   ` Ingo Molnar
2008-08-29  7:21     ` Jeremy Fitzhardinge
2008-08-29  7:30       ` Ingo Molnar
2008-08-29  8:02         ` Jeremy Fitzhardinge
2008-08-29  7:22   ` Jeremy Fitzhardinge
2008-08-29  8:14 ` Hugh Dickins
2008-08-29 14:48   ` Jeremy Fitzhardinge
2008-08-29 17:20     ` H. Peter Anvin
2008-09-08 11:35     ` Hugh Dickins
2008-09-08 17:16       ` Jeremy Fitzhardinge
2008-09-08 19:14         ` Hugh Dickins
2008-09-08 19:45           ` Jeremy Fitzhardinge [this message]
2008-08-29 17:02   ` H. Peter Anvin
2008-08-29 17:03   ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48C580BE.8060207@goop.org \
    --to=jeremy@goop.org \
    --cc=alan-jenkins@tuffmail.co.uk \
    --cc=hpa@zytor.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox