Hi Russell and all, On Tue, Jul 17, 2018 at 8:15 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> wrote: > 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. > Thanks for clarifying concern. My idea was to keep kernel running no matter what user does and due to that I proposed simple fix to avoid panic with some notification(which worked in our environment) and was as per little bit old kernel 4.14 version. All suggested example modifies system/device memory i.e.clock,dram,uart so user knows very well what is being done and so may expect weird behavior but here I was just (read)accessing i.e. not modifying. I understand (read) access could also result in security violation and it will be difficult to distinguish case and if all are thinking that it is expected behavior and best to panic kernel, I am also Okay. > -- > 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
