Don't permit mappings of invalid physical addresses on x86 via /dev/mem.
While here, add a bounds check on the physical address used with
memrw on i386. (amd64 already has a check)
Differential D7408
Don't permit mappings of invalid physical addresses on x86 via /dev/mem. jhb on Aug 3 2016, 4:55 PM. Authored by Tags None Referenced Files
Subscribers
Details
Don't permit mappings of invalid physical addresses on x86 via /dev/mem. While here, add a bounds check on the physical address used with
Diff Detail
Event TimelineComment Actions I think that this may be not completely correct for i386. cpu_maxphyaddr contains raw value from CPUID. On non-PAE systems the result could be that offsets are allowed behind 4G. The result would be non-fatal, but incorrect. x86/nexus.c has same bug, it seems. Comment Actions We always set cpu_maxphyaddr. If the cpuid leaf isn't available we set it to either 32 or 36 depending on PAE: if (cpu_exthigh >= 0x80000008) { do_cpuid(0x80000008, regs); cpu_maxphyaddr = regs[0] & 0xff; cpu_procinfo2 = regs[2]; } else { cpu_maxphyaddr = (cpu_feature & CPUID_PAE) != 0 ? 36 : 32; } Comment Actions I mean that if CPUID leaf is available and typically wider than 32, on !PAE config the offsets > 4G are not representable. They will be wrapped mod 4G, which, as I said above, not fatal, but not correct either. Comment Actions Hmm, so perhaps the code to set cpu_maxphyaddr should force it to 32 in the i386 && !PAE case? Comment Actions I suspect this might be too limiting overall. If you want to avoid duplicated limiting code repeated several times for i386, perhaps inline function is due in x86_var.h ? static inline vm_paddr_t cpu_getmaxusedphyaddr(void) { #if defined(__i386__) && !defined(PAE) return (0xffffffffU); #else return (1ULL << cpu_maxphyaddr); #endif } I do not think that PAE_TABLES option should result in the full width return. Comment Actions
Comment Actions Oh, and I (finally) tested this on both PAE and !PAE on i386 (PAE testing was stuck on the EFER_NXE bug) |