On 10/04/2012 01:07 PM, Randy Wright wrote:
>
> I wanted to mention in this context a patch RFC I posted yesterday as a
> distinct thread which is visible as https://lkml.org/lkml/2012/10/3/589
> with the subject: [PATCH RFC] function probe_roms accessing improper
> addresses on UEFI systems.
>
On 10/02/2012 11:20 PM, Matthew Garrett wrote:
> Oh, right, got you. In that case I think we potentially need a
> finer-grained check on EFI platforms - the EFI memory map is kind enough
> to tell us the difference between unusable regions and io regions, and
> we could avoid access to the unus
On 10/02/2012 10:28 PM, Matthew Garrett wrote:
> On Tue, Oct 02, 2012 at 11:13:17PM -0600, Thavatchai Makphaibulchoke wrote:
>
>> Sounds like a better solution is to allow accesses to only I/O regions
>> presented in the EFI memory map for physical addresses below 1 MB.
>
> That won't work - unf
On Tue, Oct 02, 2012 at 11:13:17PM -0600, Thavatchai Makphaibulchoke wrote:
> Sounds like a better solution is to allow accesses to only I/O regions
> presented in the EFI memory map for physical addresses below 1 MB.
That won't work - unfortunately we do still need the low region to be
availab
On 10/02/2012 10:15 PM, Matthew Garrett wrote:
> On Tue, Oct 02, 2012 at 09:44:16PM -0700, H. Peter Anvin wrote:
>
>> We *always* expose the I/O regions to /dev/mem. That is what /dev/mem
>> *does*. The above is an exception (which is really obsolete, too: we
>> should simply disallow access to
Thank you both for the comments.
Sounds like a better solution is to allow accesses to only I/O regions
presented in the EFI memory map for physical addresses below 1 MB.
Do we need to worry about the X checksum in the first MB on an EFI system?
Thanks,
Mak.
On 10/02/2012 11:15 PM, Matthew Ga
On Tue, Oct 02, 2012 at 09:44:16PM -0700, H. Peter Anvin wrote:
> We *always* expose the I/O regions to /dev/mem. That is what /dev/mem
> *does*. The above is an exception (which is really obsolete, too: we
> should simply disallow access to anything which is treated as system
> RAM, which doesn
On 10/02/2012 09:31 PM, Matthew Garrett wrote:
> On Tue, Oct 02, 2012 at 02:50:09PM -0700, H. Peter Anvin wrote:
>
>> That sounds like exactly the opposite of normal /dev/mem behavior... we
>> allow access to non-memory resources (which really could do anything if
>> misused), but not memory.
>
>
On Tue, Oct 02, 2012 at 02:50:09PM -0700, H. Peter Anvin wrote:
> That sounds like exactly the opposite of normal /dev/mem behavior... we
> allow access to non-memory resources (which really could do anything if
> misused), but not memory.
>From arch/x86/mm/init.c:
* On x86, access has to be gi
On 10/02/2012 02:32 PM, T Makphaibulchoke wrote:
> Changing devmem_is_allowed so that on an EFI machine, access to physical
> address below 1 MB is allowed only to physical pages that are valid in
> the EFI memory map. This prevents the possibility of an MCE due to
> accessing an invalid physical
Changing devmem_is_allowed so that on an EFI machine, access to physical
address below 1 MB is allowed only to physical pages that are valid in
the EFI memory map. This prevents the possibility of an MCE due to
accessing an invalid physical address.
Signed-off-by: T Makphaibulchoke
---
arch/x86
11 matches
Mail list logo
