On Tue, Jul 17, 2018 at 07:10:25PM +0530, Hari Vyas wrote: > Okay. Don't think it is a question of trust. If access happens from > kernel mode, I understand but If user mode initiated > access(from devmem(which is just an example) or any other application) > into outside or invalid region of system > address brings complete kernel down, at least I will be surprised. > If all other also think kernel panic okay in this case, then no > further action is required from my side. There are many, many ways that someone with privileged access can take the system down. It's _well_ known that accesses through /dev/mem (which gives _direct_ access to the hardware in the system) has the capability to take the system down. Your example may be through an exception, but another way could be to find the clock controller and disable system clocks, or find the RAM controller in physical memory and disable that. Or the L2 cache in older ARMs and tell it to invalidate all its contents, leading to system data corruption and probably a kernel panic. Other ways (on x86) that have been known for years include configuring an 8250 serial port at an address or interrupt (this doesn't involve /dev/mem, but merely the setserial program.) Another, non-hardware way is the killall program used from a privileged context. On some flavours of Unix, it terminates programs that match the argument. On others, it terminates _all_ programs without warning, effectively taking the system down. There are 32-bit ARM SoCs that hard-lock if you try to access a device and the clocks for that device are disabled - irrespective of whether that is a kernel or user mode access. Whoever has privileged system access (iow, the ability to directly talk to hardware or configure drivers) has a responsibility to know what to do and, more importantly, what not to do. Poking around in /dev/mem definitely comes under the heading of "don't do that unless you know *exactly* what you are doing". In normal circumstances, _nothing_ in userspace should have /dev/mem open - indeed, the kernel build system provides an option to disable this special device file via the CONFIG_DEVMEM. It has to be said that /dev/mem should _never_ be exposed to non- privileged users on the system - it's way too dangerous to do so, since as soon as you do that, you have *no* system security what so ever. Your average user is then at liberty to manually read *and* *write* the hardware *including* the kernel code _and_ page tables, which means they can bypass *all* software protections and some hardware ones as well. TBH, I'd say that for people who don't know what they're doing, poking about in /dev/mem is like pointing a gun at your foot while squeezing the trigger. It won't end well. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up
