Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1253219

Re: [PATCH v2] x86/mm: warn on W+x mappings

From Matt Fleming <matt@codeblueprint.co.uk>
Newsgroups linux.kernel
Subject Re: [PATCH v2] x86/mm: warn on W+x mappings
Date 2015-10-21 22:40 +0200
Message-ID <qm8kV-5Cw-3@gated-at.bofh.it> (permalink)
References (5 earlier) <qiM7h-1nR-31@gated-at.bofh.it> <qiMAh-1Y3-5@gated-at.bofh.it> <qjw0q-2n4-31@gated-at.bofh.it> <qjBta-20C-55@gated-at.bofh.it> <qlYbU-7xO-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, 21 Oct, at 11:42:42AM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > > > Right, we could do that, but then we wouldn't be able to support 
> > > > creation/updating variables at runtime, such as when you install a 
> > > > distribution for the first time, or want to boot a new kernel filename 
> > > > directly from the firmware without a boot loader (and need to modify the 
> > > > BootXXXX variables).
> > > 
> > > Do we know the precise position and address range of these variables?
> > > 
> > > We could map them writable (but not executable), and the rest executable (but 
> > > not writable).
> >  
> > The variables are stored in NVRAM, which we don't map into the kernel virtual 
> > address space. [...]
> 
> Just curious: is there firmware that memory maps those variables privately?
 
Good question, not sure. I suspect not because it becomes much harder
to protect those oh-so-precious variables from errant code wanting to
write to them.

Usually things get written on x86 from SMM code.

> > [...] We have to initiate the transaction of writing to the variables by 
> > executing EFI runtime services.
> > 
> > We obviously have buffers that we pass to the BIOS that contain variable data, 
> > but these should be NX anyway because they're regular kernel allocations.
> > 
> > > That raises the question whether the same physical page ever mixes variables 
> > > and actual code - but the hope would be that it's suffiently page granular for 
> > > this to work.
> > 
> > I don't think that would ever happen.
> 
> Ok, that's promising, so how about this then to solve the security weakness the 
> new warning unearthed: map the whole EFI range as 'r-x (NX)', but detect writes 
> from the page fault handler and transparently allow them to flip over the range to 
> 'rw-'.
> 
> Note that for security reasons we don't allow a subsequent flipping back to NX if 
> there's an NX fault on the same page, i.e. this new mechanism is a monotonic 
> one-way process that should dynamically 'map out' data pages versus executable 
> pages.
> 
> It should also be pretty robust, assuming we can take page faults while EFI code 
> is executing and is trying to modify EFI data: is that the case?

Yes, we can do that but I think I misunderstood what you were asking
when you said,

 > That raises the question whether the same physical page ever mixes variables and
 > actual code - but the hope would be that it's suffiently page granular for this to
 > work.
 
I was talking about EFI variables as defined in the UEFI spec, i.e.
backed by some peristent storage mechanism. I wasn't talking about
".data" objects.

It *is* possible for physical pages to contain both EFI code and data,
as Ard mentioned, and we have no way of distinguishing when EFI code
tried to write to a EfiRuntimeServicesCode page/region because there's
also legitimate data there and when an exploit attempt is taking
place.

In which case, I think we'd essentially map everything with execute
permission apart from the heap and other dynamically allocated objects
stored in EfiRuntimeServicesData.

But at that point, can't we just leave all these regions unmapped
unless we're in the EFI code paths? And that includes not leaving the
mappings around duing the suspend/resume code. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-21 11:50 +0200
  Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-21 14:50 +0200
    Re: [PATCH v2] x86/mm: warn on W+x mappings Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-10-21 15:00 +0200
      Re: [PATCH v2] x86/mm: warn on W+x mappings Borislav Petkov <bp@alien8.de> - 2015-10-21 15:30 +0200
        Re: [PATCH v2] x86/mm: warn on W+x mappings Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-10-21 15:30 +0200
          Re: [PATCH v2] x86/mm: warn on W+x mappings Borislav Petkov <bp@alien8.de> - 2015-10-21 16:40 +0200
            Re: [PATCH v2] x86/mm: warn on W+x mappings Andy Lutomirski <luto@amacapital.net> - 2015-10-21 20:50 +0200
              Re: [PATCH v2] x86/mm: warn on W+x mappings Andy Lutomirski <luto@amacapital.net> - 2015-10-21 22:50 +0200
              Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-21 22:50 +0200
  Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-21 22:40 +0200

csiph-web