Re: [flashrom] Porting flashrom to OpenBSD
Hi Stuart, hi Matthieu, On 29.06.2010 18:53, Carl-Daniel Hailfinger wrote: Add OpenBSD support. Add a requirements section to the man page which lists the needed access permissions for each programmer. This patch needs the libpci 8/16-bit write patch I sent earlier. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net If the flashrom OpenBSD patch works for you / looks good, could you respond with a line saying Acked-by: Your Name y...@email That will allow me to commit it, and the port should need no patches anymore. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [flashrom] Porting flashrom to OpenBSD
On 2010/07/02 13:26, Carl-Daniel Hailfinger wrote: Hi Stuart, hi Matthieu, On 29.06.2010 18:53, Carl-Daniel Hailfinger wrote: Add OpenBSD support. Add a requirements section to the man page which lists the needed access permissions for each programmer. This patch needs the libpci 8/16-bit write patch I sent earlier. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net If the flashrom OpenBSD patch works for you / looks good, could you respond with a line saying Acked-by: Your Name y...@email That will allow me to commit it, and the port should need no patches anymore. It does. Matthieu, any opinion on the pciutils/libpci diff? Thanks. acked-by: Stuart Henderson st...@openbsd.org
Re: [flashrom] Porting flashrom to OpenBSD
On 02.07.2010 13:38, Stuart Henderson wrote: On 2010/07/02 13:26, Carl-Daniel Hailfinger wrote: Hi Stuart, hi Matthieu, On 29.06.2010 18:53, Carl-Daniel Hailfinger wrote: Add OpenBSD support. Add a requirements section to the man page which lists the needed access permissions for each programmer. This patch needs the libpci 8/16-bit write patch I sent earlier. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net If the flashrom OpenBSD patch works for you / looks good, could you respond with a line saying Acked-by: Your Name y...@email That will allow me to commit it, and the port should need no patches anymore. It does. Matthieu, any opinion on the pciutils/libpci diff? Thanks. Acked-by: Stuart Henderson st...@openbsd.org Thanks, committed in r1067 to flashrom svn. Is there anything I need to do to have flashrom end up in the ports tree? flashrom supports i386 and amd64. Support for more architectures (PowerPC, MIPS) is pending, but testers are hard to come by. If anyone has a wishlist for to-be-supported architectures, mail flash...@flashrom.org and we'll take care of it. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [flashrom] Porting flashrom to OpenBSD
On Mon, Jun 28, 2010 at 07:10:21PM -0400, Brynet wrote: There is no sense having a port until the libpci/pci(4) issue is fixed, Not necessarily, as flashrom also supports libusb/libfti-based, parallel port based and serial port based programmers. The PCI based programmers can be disabled easily in the Makefile until the PCI issues are fixed. (However, I guess someone needs to check if the serial/parallel port code needs porting on OpenBSD; I expect libusb/libftdi support to work out of the box if those libs are available in OpenBSD) HTH, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org
Re: [flashrom] Porting flashrom to OpenBSD
On 28.06.2010 22:01, Stuart Henderson wrote: On 2010/06/29 00:06, Ian McWilliam wrote: 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 agree with both points :) Thanks. 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. We could, but I think it's even better to have proper instructions for OpenBSD in the main distribution. I added the message to strategic places in the code and the man page. Add OpenBSD support. Add a requirements section to the man page which lists the needed access permissions for each programmer. This patch needs the libpci 8/16-bit write patch I sent earlier. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Index: flashrom-openbsd/flashrom.8 === --- flashrom-openbsd/flashrom.8 (revision 1063) +++ flashrom-openbsd/flashrom.8 (working copy) @@ -306,7 +306,7 @@ Example: .B flashrom \-p dummy:lpc,fwh .TP -.BR nic3com , nicrealtek , nicsmc1211 , gfxnvidia , satasii\ +.BR nic3com , nicrealtek , nicsmc1211 , gfxnvidia , satasii \ and atahpt programmers These programmers have an option to specify the PCI address of the card your want to use, which must be specified if more than one card supported @@ -391,6 +391,51 @@ .SH EXIT STATUS flashrom exits with 0 on success, 1 on most failures but with 2 if /dev/mem (/dev/xsvc on Solaris) can not be opened and with 3 if a call to mmap() fails. +.SH REQUIREMENTS +flashrom needs different access permissions for different programmers. +.sp +.B internal +needs raw memory access, PCI configuration space access, raw I/O port +access (x86) and MSR access (x86). +.sp +.B it87spi +needs raw I/O port access (x86). +.sp +.BR nic3com , nicrealtek , nicsmc1211 and nicnatsemi +need PCI configuration space read access and raw I/O port access. +.sp +.B atahpt +needs PCI configuration space access and raw I/O port access. +.sp +.BR gfxnvidia and drkaiser +need PCI configuration space access and raw memory access. +.sp +.B satasii +needs PCI configuration space read access and raw memory access. +.sp +.B serprog +needs TCP access to the network or userspace access to a serial port. +.sp +.B buspirate_spi +needs userspace access to a serial port. +.sp +.BR dediprog and ft2232_spi +need access to the USB device via libusb. +.sp +.B dummy +needs no access permissions at all. +.sp +.BR internal , it87spi , nic3com , nicrealtek , nicsmc1211 , +.BR nicnatsemi , gfxnvidia , drkaiser , satasii and atahpt +have to be run as superuser/root, and need additional raw access permission. +.sp +.BR serprog , buspirate_spi , dediprog and ft2232_spi +can be run as normal user on most operating systems if appropriate device +permissions are set. +.sp +On OpenBSD, you can obtain raw access permission by setting +securelevel=-1 in /etc/rc.securelevel and rebooting, or rebooting into single +user mode. .SH BUGS Please report any bugs at .sp Index: flashrom-openbsd/hwaccess.c === --- flashrom-openbsd/hwaccess.c (revision 1063) +++ flashrom-openbsd/hwaccess.c (working copy) @@ -57,6 +57,11 @@ #endif msg_perr(ERROR: Could not get I/O privileges (%s).\n You need to be root.\n, strerror(errno)); +#if defined (__OpenBSD__) + msg_perr(Please set securelevel=-1 in /etc/rc.securelevel + and reboot, or reboot into \n); + msg_perr(single user mode.\n); +#endif exit(1); } #endif Index: flashrom-openbsd/hwaccess.h === --- flashrom-openbsd/hwaccess.h (revision 1063) +++ flashrom-openbsd/hwaccess.h (working copy) @@ -228,17 +228,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
Re: [flashrom] Porting flashrom to OpenBSD
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
Re: [flashrom] Porting flashrom to OpenBSD
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
Re: [flashrom] Porting flashrom to OpenBSD
On 2010/06/29 00:06, Ian McWilliam wrote: 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 agree with both points :) 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. We could, but I think it's even better to have proper instructions for OpenBSD in the main distribution.
Re: [flashrom] Porting flashrom to OpenBSD
There is no sense having a port until the libpci/pci(4) issue is fixed, flashrom still doesn't work yet.. it compiles and runs, but AFAIK it always errors out. -Bryan.
Re: [flashrom] Porting flashrom to OpenBSD
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
--
http://www.hailfinger.org/
Re: [flashrom] Porting flashrom to OpenBSD
On 26.06.2010 15:30, Stuart Henderson wrote: We already have a bios flasher in the ports tree (sysutils/dellflash). It requires special steps to be taken to use. Userland just does not and should not have this level of access to the system unless configuration changes are deliberately made. (In the case of dellflash, a kernel module handles access to the flash device which of course must be loaded before securelevel is raised). AFAIK dellflash (well, at least the Linux equivalent) is special because it doesn't perform any flashing, it simply loads a BIOS image into contiguous physical memory and waits for the BIOS to do the flashing on reboot. Due to that, you need a kernel module, and the flashing happens outside any OS. flashrom doesn't trust/use the BIOS to flash, and it doesn't need a kernel module because it does the flashing itself, from userspace. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [flashrom] Porting flashrom to OpenBSD
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.
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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 http://spacehopper.org/flashrom.txt 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-portsm=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 -- http://www.hailfinger.org/
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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)?
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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.
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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.
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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.
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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. -- Matthieu Herrb
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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
Re: [flashrom] Porting flashrom to OpenBSD
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.
Re: [flashrom] Porting flashrom to OpenBSD
Theo de Raadt wrote: I should have mentioned, this was single-user. The aperture is for X. But it's not opening /dev/xf86 or /dev/drm, it's playing around with /dev/pci via libpci.. and writes always fail, even in single-user. -Bryan.
Re: [flashrom] Porting flashrom to OpenBSD
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
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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. -- Matthieu Herrb
Re: [flashrom] Porting flashrom to OpenBSD
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-portsm=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
