lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 09 Aug 2018 16:03:18 -0700 From: Stephen Boyd <swboyd@...omium.org> To: Julius Werner <jwerner@...omium.org> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, LKML <linux-kernel@...r.kernel.org>, Wei-Ning Huang <wnhuang@...omium.org>, Julius Werner <jwerner@...omium.org>, Brian Norris <briannorris@...omium.org>, samuel@...lland.org Subject: Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access Quoting Julius Werner (2018-08-09 14:07:31) > On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd <swboyd@...omium.org> wrote: > > > > Call request_mem_region() on the entire coreboot table to make sure > > other devices don't attempt to map the coreboot table in their drivers. > > If drivers need that support, it would be better to provide bus APIs > > they can use to do that through the mapping created in this file. > > > > Does this prevent userspace from mapping this region via /dev/mem? If > so, let's please not do it to not break compatibility with existing > tools. No it doesn't break. I can still read the memory here with /dev/mem (and cbmem). But that seems to be because of a couple reasons. First, I have CONFIG_STRICT_DEVMEM=y but CONFIG_IO_STRICT_DEVMEM=n. This allows me to map memory that isn't system ram. If CONFIG_IO_STRICT_DEVMEM=y then mapping this I/O region through /dev/mem here would be denied . Furthermore, I see that my system RAM excludes this coreboot table so it doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find. > (I guess an alternative would be to rewrite 'cbmem' to use > /sys/bus/coreboot/devices if available to get its coreboot table > information. But we'd still need to maintain the old path for > backwards compatibility anyway, so that would really just make it more > complicated.) This sounds like a good idea. Userspace reaching into /dev/mem is not good from a kernel hardening perspective. That's why those strict devmem configs exist. Can cbmem be updated to query information from device drivers instead, so that we can enable CONFIG_IO_STRICT_DEVMEM as well?
Powered by blists - more mailing lists