Commit 81fa32bd7e ("drivers/linux: enforce address requirement for
IOCTL_ALLOC_PHYSMEM") tried to enforce the physical address constraints
provided by the user. However, it's broken for the memory range 16M-4G
as there's no DMA32 kmalloc cache, making the request allocate from the
normal zone which is free to return an address above 4GB for systems
with enough RAM.
Commit d010b82b0d ("Fix malloc issue in Linux driver") worked around
that issue by simple dropping the DMA32 allocation and only using DMA
allocations for which kmalloc slabs do exist.
As the DMA zone is a scarce resource and might be exhausted already, use
a different allocation scheme for chipsec that directly allocates memory
from the page allocator which honours both, DMA and DMA32 requests.
Also fix the allocation list handling while at it. The stored physical
address might be truncated on 32-bit PAE systems because of the use of
'physaddr_t' instead of 'phys_addr_t'.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Try harder to fulfill the physical address constraint for the
IOCTL_ALLOC_PHYSMEM ioctl by trying to allocate memory from the zones
that fit the maximum address best, but fall-back to the normal zone in
case the allocation fails.
If we fail to allocate memory that fulfills the maximum physical address
constraint, make the ioctl() fail as well instead of emitting a warning.
This is safer then making, e.g., the tools.smm.smm_ptr module corrupt
unrelated memory just because the allocation happens to be above 4GB but
the pointer passed to SMM is truncated to 32 bit.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
With the addition of a bounce buffer both functions are nearly
identical. They only differ in the direction of copy.
Merge them into a common helper function that gets the copy direction
passed as an argument.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
If we try to write to an address that's not allowed by USERCOPY, the
copy will fail.
Use a bounce buffer to work around that, just like read_mem() does.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
If we get passed an invalid virtual address, make IOCTL_VA2PA fail
instead of returning a bogus address.
Also simplify the code. No need to use 'PHYSICAL_ADDRESS' here,
'phys_addr_t' is just fine.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
chipsec_km.c is mostly self-contained and thereby has no need to export
symbols.
Make almost all of them 'static' and leave only the (config dependent)
unused ones non-static.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
If we fail to allocate memory for chaining the user requested allocation
to our accounting list, we leak 'va.'
Fix that. Also fix the return code to be -ENOMEM instead of -EFAULT for
failing memory allocations.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
In case my_xlate_dev_mem_ptr() fails for a given physical address, we
should return an error instead of trying to read/write to NULL.
Also fix whitespace issues around this code section.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Commit 397b1b8d8b ("drivers/linux: simplify and fix symbol resolving
for kernels >= 5.10") introduced a method for finding the address of
kallsyms_lookup_name() by scanning kernel code around 'sprint_symbol.'
However, it only looked "backwards" which would be fine, as
kallsyms_lookup_name() gets defined before sprint_symbol() in
kallsyms.c. However, gcc's '-freorder-functions' (which is enabled by
default at -O2 / -Os) may put kallsyms_lookup_name() *after*
sprint_symbol() in the object file, making our search fail to find it.
Account for that and search around sprint_symbol() in both directions.
32kB is more than enough to cover all of kallsyms.o.
Fixes: 397b1b8d8b ("drivers/linux: simplify and fix symbol resolving for kernels >= 5.10")
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
grsecurity kernels stub out the kallsyms family of functions when the
feature CONFIG_GRKERNSEC_HIDESYM is enabled. This destroys out attempt
to find the address of 'kallsyms_lookup_name' via sprint_symbol().
Prevent that by making use of the '__INCLUDED_BY_HIDESYM' define
grsecurity provides for this exact purpose.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
The current implementation of __swsmi__ for x86-64 is rather complicated
as it uses more registers than needed. Simplyfy it.
We can use the passed SMI_CTX buffer as scratch space without the need
to use intermediate registers (beside for RDI, for which we use R10 -- a
callee clobbered register).
Bring the implementation more in line with its OS X counterpart and
adapt the comments and code to reflect reality, namely:
- change the C type members to mirror the used (and intended) registers,
- mark the registers as in/out parameters in the comments,
- drop the bogus comment about clobbering DX, as we don't do that and
- fix and tweak the comment about split i/o because of picky firmwares.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
ChipSec