Hi Stuart, hi Ian,
thanks for the enthusiastic response. I added a few fixups to the flashrom tree in the meantime to get the OpenBSD patch size down a bit. After all, if it gets easier for you to test, we all win.
Stuart, if this works for you, I'll commit the patches into flashrom subversion ASAP. My stated goal is to support every OS without the need for any local patches.
A good first step to check if flashrom could run on your system is to run lspci. You may have to set machdep.allowaperture=2 and possibly other settings to get it working. flashrom uses raw memory access (/dev/mem), raw x86 port access (via inb/outb functions) and PCI access (via libpci).
On 19.06.2010 03:38, Ian McWilliam wrote:
On 19/06/2010 10:42 AM, Stuart Henderson wrote:
On 2010/06/19 02:33, Carl-Daniel Hailfinger wrote:
I'm one of the lead developers of flashrom, a GPLv2 application to read/write/erase flash chips on mainboards, network/storage/graphics cards and external programmers.[...]
I have two patches which get flashrom to compile on OpenBSD on i386, and they should work on amd64 as well. Those patches will be merged into the official flashrom source tree once I know that they work. The big obstacle for me is that I don't own any OpenBSD machine, and all I have is shell access to a public OpenBSD i386 shell server. flashrom is pretty small, you can compile it in ~5 seconds on a reasonably fast machine, so compile testing shouldn't need too much time.
If you send me the patches I'll write a port Makefile for it. Then it's easier for people to test. Compile testing is no problem but I don't have any machines that I can spare to test actual bios updates on though.
It would be great to have flashrom working on OpenBSD.
I have 2 ASUS M2N-SLI deluxe motherboards that have a later bios update that I can test under AMD64 && i386. Create the port and throw my way for some testing.
First patch (libpci fixups) is available at http://patchwork.coreboot.org/patch/1506/ (click the "patch" link there to download it). It is needed for gcc 3.x. The second patch (which has the actual OpenBSD support code) is below and will be available for download near the top of http://patchwork.coreboot.org/project/flashrom/list/ in case the patch gets mangled in transit.
To compile flashrom, please check out svn://svn.coreboot.org/flashrom/trunk then apply the libpci fixup patch, then apply the patch below:
Add OpenBSD support (i386 and amd64) to flashrom. Compile tested on i386. To compile flashrom, you need libpci from pciutils. flashrom expects /usr/local/include/pci/pci.h (see OpenBSD-specific CPPFLAGS in the Makefile patch) and /usr/local/lib/libpci.so or libpci.a or something which can be found by the linker. flashrom needs gmake. Depending on the cleanliness of your headers, you may have to set WARNERROR=no. Run gmake or gmake WARNERROR=no
If /usr/local is not the place where ports end up, please tell me so I can fix the patch.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: flashrom-openbsd/hwaccess.h =================================================================== --- flashrom-openbsd/hwaccess.h (revision 1057) +++ flashrom-openbsd/hwaccess.h (working copy) @@ -221,17 +221,25 @@ #endif #endif
-#if defined(__NetBSD__) +#if defined(__NetBSD__) || defined (__OpenBSD__) #define off64_t off_t #define lseek64 lseek #if defined(__i386__) || defined(__x86_64__) #include <sys/types.h> #include <machine/sysarch.h> +#if defined(__NetBSD__) #if defined(__i386__) #define iopl i386_iopl #elif defined(__x86_64__) #define iopl x86_64_iopl #endif +#elif defined (__OpenBSD__) + #if defined(__i386__) + #define iopl i386_iopl + #elif defined(__amd64__) + #define iopl amd64_iopl + #endif +#endif #include <stdint.h>
static inline void outb(uint8_t value, uint16_t port) Index: flashrom-openbsd/Makefile =================================================================== --- flashrom-openbsd/Makefile (revision 1057) +++ flashrom-openbsd/Makefile (working copy) @@ -48,6 +48,10 @@ CPPFLAGS += -I/usr/local/include LDFLAGS += -L/usr/local/lib endif +ifeq ($(OS_ARCH), OpenBSD) +CPPFLAGS += -I/usr/local/include +LDFLAGS += -L/usr/local/lib +endif ifeq ($(OS_ARCH), DOS) EXEC_SUFFIX := .exe CPPFLAGS += -I../libgetopt -I../libpci/include @@ -259,9 +263,13 @@ LIBS += ../libpci/lib/libpci.a else LIBS += -lpci +ifeq ($(OS_ARCH), OpenBSD) +# For (i386|amd64)_iopl(2). +LIBS += -l$(shell uname -m) endif endif endif +endif
ifeq ($(CONFIG_PRINT_WIKI), yes) FEATURE_CFLAGS += -D'CONFIG_PRINT_WIKI=1' Index: flashrom-openbsd/README =================================================================== --- flashrom-openbsd/README (revision 1057) +++ flashrom-openbsd/README (working copy) @@ -55,6 +55,11 @@ * devel/gmake * devel/libpci
+On OpenBSD, you need the following ports: + + * devel/gmake + * sysutils/pciutils + To compile on Linux, use:
make @@ -76,6 +81,10 @@ ln -s /usr/pkg/include/pciutils pci gmake CPPFLAGS=-I. LDFLAGS="-L/usr/pkg/lib -Wl,-rpath-link,/usr/pkg/lib"
+To compile on OpenBSD, use: + + gmake + To compile and run on Darwin/Mac OS X:
Install DirectIO from coresystems GmbH.
On 2010/06/22 04:02, Carl-Daniel Hailfinger wrote:
Hi Stuart, hi Ian,
thanks for the enthusiastic response. I added a few fixups to the flashrom tree in the meantime to get the OpenBSD patch size down a bit. After all, if it gets easier for you to test, we all win.
Stuart, if this works for you, I'll commit the patches into flashrom subversion ASAP. My stated goal is to support every OS without the need for any local patches.
A good first step to check if flashrom could run on your system is to run lspci. You may have to set machdep.allowaperture=2 and possibly other settings to get it working. flashrom uses raw memory access (/dev/mem), raw x86 port access (via inb/outb functions) and PCI access (via libpci).
Port attached and at http://spacehopper.org/flashrom.tgz; this is basically your patches with a typo fixed (missing ; in the Makefile).
You can see exampkle output from an unsuccessful run on amd64 attempting to dump rom contents at http://spacehopper.org/flashroom.txt
On 2010/06/25 00:21, Stuart Henderson wrote:
On 2010/06/22 04:02, Carl-Daniel Hailfinger wrote:
Hi Stuart, hi Ian,
thanks for the enthusiastic response. I added a few fixups to the flashrom tree in the meantime to get the OpenBSD patch size down a bit. After all, if it gets easier for you to test, we all win.
Stuart, if this works for you, I'll commit the patches into flashrom subversion ASAP. My stated goal is to support every OS without the need for any local patches.
A good first step to check if flashrom could run on your system is to run lspci. You may have to set machdep.allowaperture=2 and possibly other settings to get it working. flashrom uses raw memory access (/dev/mem), raw x86 port access (via inb/outb functions) and PCI access (via libpci).
Port attached and at http://spacehopper.org/flashrom.tgz; this is basically your patches with a typo fixed (missing ; in the Makefile).
You can see exampkle output from an unsuccessful run on amd64 attempting to dump rom contents at http://spacehopper.org/flashroom.txt
Sorry, typo: http://spacehopper.org/flashrom.txt
Port at http://spacehopper.org/flashrom.tgz is updated (add dmidedode as a RUN_DEPENDS and tidy the Makefile).
Hi Jonathan,
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
On 25.06.2010 01:30, Stuart Henderson wrote:
On 2010/06/25 00:21, Stuart Henderson wrote:
On 2010/06/22 04:02, Carl-Daniel Hailfinger wrote:
I added a few fixups to the flashrom tree in the meantime to get the OpenBSD patch size down a bit. After all, if it gets easier for you to test, we all win.
Stuart, if this works for you, I'll commit the patches into flashrom subversion ASAP. My stated goal is to support every OS without the need for any local patches.
A good first step to check if flashrom could run on your system is to run lspci. You may have to set machdep.allowaperture=2 and possibly other settings to get it working. flashrom uses raw memory access (/dev/mem), raw x86 port access (via inb/outb functions) and PCI access (via libpci).
Port attached and at http://spacehopper.org/flashrom.tgz; this is basically your patches with a typo fixed (missing ; in the Makefile).
Right, my bad. Thanks.
You can see exampkle output from an unsuccessful run on amd64 attempting to dump rom contents at
Excerpt from that log:
pcilib: obsd_write: ioctl(PCIOCWRITE) failed
Ouch. I remember a pciutils patch on the ports mailing list which may be related to this: http://marc.info/?l=openbsd-ports&m=126918139214769 flashrom uses libpci from pciutils, and it absolutely _must_ have write access to PCI.
Port at http://spacehopper.org/flashrom.tgz is updated (add dmidedode as a RUN_DEPENDS and tidy the Makefile).
Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
Stuart, does the pcilib abort happen on i386 and amd64?
Regards, Carl-Daniel
On 25.06.2010 11:57, Carl-Daniel Hailfinger wrote:
Port at http://spacehopper.org/flashrom.tgz is updated (add dmidedode as a RUN_DEPENDS and tidy the Makefile).
Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
One additional question about the port. I saw you have this in the port Makefile:
CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib
Does this mean that the OpenBSD-specific CFLAGS/LDFLAGS in the flashrom Makefile are wrong/useless? I have this snippet in the flashrom Makefile patch: +ifeq ($(OS_ARCH), OpenBSD) +CPPFLAGS += -I/usr/local/include +LDFLAGS += -L/usr/local/lib +endif
That snippet is designed to pick up libpci from the ports tree (well, I don't really know if ports work like that). The idea is that if someone has pciutils installed in the standard location, running "gmake" in the flashrom tree shouldn't need any additional parameters, and just work.
Regards, Carl-Daniel
On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote:
Hi Jonathan,
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE: io = (struct pci_io *)data; switch (io->pi_width) { case 4: /* Make sure the register is properly aligned */ if (io->pi_reg & 0x3) return EINVAL; pci_conf_write(pc, tag, io->pi_reg, io->pi_data); error = 0; break; default: error = ENODEV; break; } break;
Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
As an aside, anyone know why securelevel gets set to 1 after booting (despite the setting in rc.securelevel)?
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE: io = (struct pci_io *)data; switch (io->pi_width) { case 4: /* Make sure the register is properly aligned */ if (io->pi_reg & 0x3) return EINVAL; pci_conf_write(pc, tag, io->pi_reg, io->pi_data); error = 0; break; default: error = ENODEV; break; } break;Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
Re-using the aperture like this is a mistake. In time, if the X server support for kernel mode setting, the aperture will largely go away, or at least have the hole shrunk.
Again -- reusing the aperture for this is a mistake. Sorry. What X does on PC's is totally wrong, and more things don't need to make the same mistake.
As an aside, anyone know why securelevel gets set to 1 after booting (despite the setting in rc.securelevel)?
To protect the machine.
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE: io = (struct pci_io *)data; switch (io->pi_width) { case 4: /* Make sure the register is properly aligned */ if (io->pi_reg & 0x3) return EINVAL; pci_conf_write(pc, tag, io->pi_reg, io->pi_data); error = 0; break; default: error = ENODEV; break; } break;Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
I should have mentioned, this was single-user.
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE: io = (struct pci_io *)data; switch (io->pi_width) { case 4: /* Make sure the register is properly aligned */ if (io->pi_reg & 0x3) return EINVAL; pci_conf_write(pc, tag, io->pi_reg, io->pi_data); error = 0; break; default: error = ENODEV; break; } break;Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
I should have mentioned, this was single-user.
The aperture is for X.
On 25.06.2010 16:44, Theo de Raadt wrote:
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE: io = (struct pci_io *)data; switch (io->pi_width) { case 4: /* Make sure the register is properly aligned */ if (io->pi_reg & 0x3) return EINVAL; pci_conf_write(pc, tag, io->pi_reg, io->pi_data); error = 0; break; default: error = ENODEV; break; } break;Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
I should have mentioned, this was single-user.
The aperture is for X.
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs.
PCI config space writes (usually only to the PCI<->LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years.
flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip).
Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD.
Regards, Carl-Daniel
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs.
PCI config space writes (usually only to the PCI<->LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years.
flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip).
I understand very well what you are trying to do.
But it is the kernel's job to protect the hardware from all manner of direct access. Even essentially in single user mode.
Now it is an accident of history that X is so terribly designed. It is currently accepted that this is so, and that's too bad, so there is a "hole" for X. There's a 10+ year effort to improve X so that this hole can go away. When it does, stuff like your code will stop working.
Unix is designed to hide the hardware, to protect the hardware, and it does this by providing and using highly abstracted interfaces. What you are trying to do is get around Unix.
Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD.
I don't buy any of that stuff. By the time this has happened, you're already hosed.
On 25.06.2010 17:20, Theo de Raadt wrote:
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs.
PCI config space writes (usually only to the PCI<->LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years.
flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip).
I understand very well what you are trying to do.
But it is the kernel's job to protect the hardware from all manner of direct access. Even essentially in single user mode.
Now it is an accident of history that X is so terribly designed. It is currently accepted that this is so, and that's too bad, so there is a "hole" for X. There's a 10+ year effort to improve X so that this hole can go away. When it does, stuff like your code will stop working.
What's the correct way forward for flashrom on OpenBSD?
Unix is designed to hide the hardware, to protect the hardware, and it does this by providing and using highly abstracted interfaces. What you are trying to do is get around Unix.
The Unix interfaces for hardware access usually have a reasonable level of abstraction as well, and flashrom makes use of that to run on pretty much any OS.
flashrom is essentially a self-contained driver+frontend in userspace and thus very similar to X. It would be possible to move all hardware access into a kernel driver, but such a kernel driver would (if you really care about userspace not being able to screw up) have in excess of 25000 lines of code, constantly growing. That's the point where kernel maintainers usually run away screaming.
The minimalistic and still somewhat safe approach is to have flashrom generate a list of PCI config space locations it needs to read/write, and whitelist only those in a kernel driver. Such a whitelist would reduce the amount of damage another userspace app with the same privileges could cause, and it's way better than a blacklist which will never be exhaustive. That kernel driver would also allow opening /dev/flashrom_memory which is essentially /dev/mem restricted to the regions which are absolutely necessary.
Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD.
I don't buy any of that stuff. By the time this has happened, you're already hosed.
Not necessarily. You can easily boot with a known-clean flash chip, then (once the machine is booted) hot-swap the flash chip and read out the new flash chip. No code from the new flash chip will be executed. In fact, you can remove the flash chip after booting and run the machine without a flash chip forever (until you need to boot again). As long as the flash chip technology is compatible, you can exchange them regardless of mainboard chipset or CPU. This only applies to i386/amd64, I have no idea about other architectures.
Regards, Carl-Daniel
On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote:
On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote:
Hi Jonathan,
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries.
The rest of the discussion about not abusing the aperture driver for this also stays.
If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland.
On 25.06.2010 17:07, Matthieu Herrb wrote:
On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote:
On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote:
Hi Jonathan,
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries.
If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland.
Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in /dev/pci work for that? I could modify flashrom to use read/modify/write cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but that may have undesirable side effects on some chipsets.
The rest of the discussion about not abusing the aperture driver for this also stays.
I never fully understood how /dev/mem and the aperture driver are related. flashrom uses /dev/mem for memory access. The allowaperture stuff is something I guessed from reading various OpenBSD docs and mailing list posts.
Regards, Carl-Daniel
On Fri, Jun 25, 2010 at 06:24:56PM +0200, Carl-Daniel Hailfinger wrote:
On 25.06.2010 17:07, Matthieu Herrb wrote:
On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote:
On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote:
Hi Jonathan,
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries.
If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland.
Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in /dev/pci work for that? I could modify flashrom to use read/modify/write cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but that may have undesirable side effects on some chipsets.
As far as I know this is an urban legend. Ask kettenis@ for details. So far we resisted to do that. libpciaccess handles it for OpenBSD (/usr/xenocara/lib/libpciaccess/src/openbsd_pci.c).
The rest of the discussion about not abusing the aperture driver for this also stays.
I never fully understood how /dev/mem and the aperture driver are related. flashrom uses /dev/mem for memory access. The allowaperture stuff is something I guessed from reading various OpenBSD docs and mailing list posts.
The aperture driver was initially created to allow the X server to access the physical memory addresses of the graphics cards, even when running at securelevel > 0, where /dev/mem access is forbidden. /dev/xf86 is used for that purpose and is attached to a character device which has the same major device number as /dev/mem.
The sysctl is there to enable or disable the aperture, in order to avoid rebuilding a kernel to disable it.
Then, when PCI/AGP video cards appeared, many PCI BIOS started so buggy that something had to fix their configuration space in order to be able to use them. Since XFree86 was a multi-platform system, instead of asking and waiting until every possible supported system implements the required kernel bits, they decided to write to the PCI config space directly from userland to fix those problems.
On OpenBSD we decided that those /dev/pci write access are similar to /dev/mem access, and thus decided to control it using the same sysctl, in order not to create more knobs.
On 25.06.2010 18:58, Matthieu Herrb wrote:
On Fri, Jun 25, 2010 at 06:24:56PM +0200, Carl-Daniel Hailfinger wrote:
On 25.06.2010 17:07, Matthieu Herrb wrote:
On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote:
On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote:
Hi Jonathan,
you're in CC of this mail because you sent the "unbreak pciutils" mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-ports&m=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2...
Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries.
If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland.
Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in /dev/pci work for that? I could modify flashrom to use read/modify/write cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but that may have undesirable side effects on some chipsets.
As far as I know this is an urban legend. Ask kettenis@ for details. So far we resisted to do that. libpciaccess handles it for OpenBSD (/usr/xenocara/lib/libpciaccess/src/openbsd_pci.c).
Thanks. Do you know if anyone plans to implement the same trickery in libpci? If it works fine for libpciaccess, it should be doable for libpci.
The rest of the discussion about not abusing the aperture driver for this also stays.
I never fully understood how /dev/mem and the aperture driver are related. flashrom uses /dev/mem for memory access. The allowaperture stuff is something I guessed from reading various OpenBSD docs and mailing list posts.
The aperture driver was initially created to allow the X server to access the physical memory addresses of the graphics cards, even when running at securelevel > 0, where /dev/mem access is forbidden. /dev/xf86 is used for that purpose and is attached to a character device which has the same major device number as /dev/mem.
The sysctl is there to enable or disable the aperture, in order to avoid rebuilding a kernel to disable it.
Then, when PCI/AGP video cards appeared, many PCI BIOS started so buggy that something had to fix their configuration space in order to be able to use them. Since XFree86 was a multi-platform system, instead of asking and waiting until every possible supported system implements the required kernel bits, they decided to write to the PCI config space directly from userland to fix those problems.
On OpenBSD we decided that those /dev/pci write access are similar to /dev/mem access, and thus decided to control it using the same sysctl, in order not to create more knobs.
So if I understand you correctly, full /dev/pci and /dev/mem access should be possible with securelevel=0, and we shouldn't screw with allowaperture at all? No problem, I am happy to change the flashrom docs.
flashrom is something you won't run on every boot, so I think requiring securelevel=0 for the few times you need to access flash is perfectly fine.
Regards, Carl-Daniel
On 2010/06/25 19:31, Carl-Daniel Hailfinger wrote:
On OpenBSD we decided that those /dev/pci write access are similar to /dev/mem access, and thus decided to control it using the same sysctl, in order not to create more knobs.
So if I understand you correctly, full /dev/pci and /dev/mem access should be possible with securelevel=0, and we shouldn't screw with allowaperture at all? No problem, I am happy to change the flashrom docs.
Ah, I've tracked down why securelevel gets changed from 0 to 1 (which is what I was asking about re securelevels). It's init(8). To avoid this and have /dev/{pci,mem} access on a running system, temporarily set securelevel=-1 in /etc/rc.securelevel.
flashrom is something you won't run on every boot, so I think requiring securelevel=0 for the few times you need to access flash is perfectly fine.
Agreed.
On 26.06.2010 15:16, Stuart Henderson wrote:
On 2010/06/25 19:31, Carl-Daniel Hailfinger wrote:
On OpenBSD we decided that those /dev/pci write access are similar to /dev/mem access, and thus decided to control it using the same sysctl, in order not to create more knobs.
So if I understand you correctly, full /dev/pci and /dev/mem access should be possible with securelevel=0, and we shouldn't screw with allowaperture at all? No problem, I am happy to change the flashrom docs.
Ah, I've tracked down why securelevel gets changed from 0 to 1 (which is what I was asking about re securelevels). It's init(8). To avoid this and have /dev/{pci,mem} access on a running system, temporarily set securelevel=-1 in /etc/rc.securelevel.
Ah right. So you change /etc/securelevel, reboot, run flashrom, change securelevel again, reboot, and the system is back to the old secure settings.
flashrom is something you won't run on every boot, so I think requiring securelevel=0 for the few times you need to access flash is perfectly fine.
Agreed.
It is at least going to take a reboot and either running in single- user mode or adjusting rc.securelevel.
Could I ask you to write one or two short sentences which will be printed if flashrom detects insufficient permisions on OpenBSD? Maybe something like this (feel free to change it completely): "Error: Insufficient permissions to access hardware. Please set securelevel=-1 in /etc/rc.securelevel and reboot, or reboot into single user mode."
Regards, Carl-Daniel
On Sun, Jun 27, 2010 at 10:38:30PM +0200, Carl-Daniel Hailfinger wrote:
Could I ask you to write one or two short sentences which will be printed if flashrom detects insufficient permisions on OpenBSD? Maybe something like this (feel free to change it completely):
"Error: Insufficient permissions to access hardware. Please set securelevel=-1 in /etc/rc.securelevel and reboot, or reboot into single user mode."
This message looks good to me. You could add "See the securelevel(7) and init(8) manual pages for details".
Thanks for your work on this port.
On 28/06/2010, at 6:41 PM, Matthieu Herrb wrote:
On Sun, Jun 27, 2010 at 10:38:30PM +0200, Carl-Daniel Hailfinger wrote:
Could I ask you to write one or two short sentences which will be printed if flashrom detects insufficient permisions on OpenBSD? Maybe something like this (feel free to change it completely):
"Error: Insufficient permissions to access hardware. Please set securelevel=-1 in /etc/rc.securelevel and reboot, or reboot into single user mode."
This message looks good to me. You could add "See the securelevel(7) and init(8) manual pages for details".
Thanks for your work on this port.
Matthieu Herrb
I think in the port we could probably add a README.OpenBSD file where we could explain the situation in more detail like we do for many other ports stored in the share/doc/flashrom directory as well.
Ian McWilliam
-
Brynet -
Carl-Daniel Hailfinger -
Ian McWilliam -
Matthieu Herrb -
Stuart Henderson -
Theo de Raadt