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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3639flaet.fsf@intrepid.localdomain>
Date:	Thu, 12 Nov 2009 22:07:22 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	"Henrique de Moraes Holschuh" <hmh@....eng.br>
Cc:	"Andi Kleen" <andi@...stfloor.org>,
	"Robert Hancock" <hancockrwd@...il.com>,
	"Anton D. Kachalov" <mouse@...c.ru>, linux-kernel@...r.kernel.org
Subject: Re: Reading /dev/mem by dd

"Henrique de Moraes Holschuh" <hmh@....eng.br> writes:

> In this case, the problem seems to be access over /dev/mem to stuff the
> kernel is already taking care of.

Not sure if local APIC counts as "PCI space and the BIOS code and data
regions" but:

$ grep STRICT_DEVMEM -A 15 arch/x86/Kconfig.debug
config STRICT_DEVMEM
        bool "Filter access to /dev/mem"
        ---help---
          If this option is disabled, you allow userspace (root) access to all
          of memory, including kernel and userspace memory. Accidental
          access to this is obviously disastrous, but specific access can
          be used by people debugging the kernel. Note that with PAT support
          enabled, even in this case there are restrictions on /dev/mem
          use due to the cache aliasing requirements.

          If this option is switched on, the /dev/mem file only allows
          userspace access to PCI space and the BIOS code and data regions.
          This is sufficient for dosemu and X and all common users of
          /dev/mem.

          If in doubt, say Y.

> Certainly "as safe as possible" does
> not have to mean making /dev/mem useless for whatever good uses it has.

For debugging you need absolutely full access to whole address space(s).
One mistake (or intentional action) and the system is dead, this is by
design. It's BTW not very dangerous, compared to accessing flash
ROM/EEPROM/"fuses"/FPGA/CPLD/etc.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ