Re: [flashrom] Porting flashrom to OpenBSD

2010-07-02 Thread Carl-Daniel Hailfinger
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 
>>>   
>>>   
>> If the flashrom OpenBSD patch works for you / looks good, could you
>> respond with a line saying "Acked-by: Your Name "
>>
>> 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 
>   

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

2010-07-02 Thread Stuart Henderson
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 
> >   
> 
> If the flashrom OpenBSD patch works for you / looks good, could you
> respond with a line saying "Acked-by: Your Name "
> 
> 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 



Re: [flashrom] Porting flashrom to OpenBSD

2010-07-02 Thread Carl-Daniel Hailfinger
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 
>   

If the flashrom OpenBSD patch works for you / looks good, could you
respond with a line saying "Acked-by: Your Name "

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

2010-06-29 Thread Carl-Daniel Hailfinger
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 

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 
 #include 
+#if defined(__NetBSD__)
 #if defined(__i386__)
   #de

Re: [flashrom] Porting flashrom to OpenBSD

2010-06-29 Thread Uwe Hermann
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

2010-06-28 Thread Brynet
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

2010-06-28 Thread Stuart Henderson
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

2010-06-28 Thread Ian McWilliam

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

2010-06-28 Thread Matthieu Herrb
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

2010-06-27 Thread Carl-Daniel Hailfinger
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

2010-06-27 Thread Carl-Daniel Hailfinger
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

2010-06-26 Thread Stuart Henderson
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

2010-06-25 Thread Carl-Daniel Hailfinger
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



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Matthieu Herrb
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. 


-- 
Matthieu Herrb



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Carl-Daniel Hailfinger
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



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Carl-Daniel Hailfinger
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

2010-06-25 Thread Brynet
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

2010-06-25 Thread Theo de Raadt
> 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

2010-06-25 Thread Carl-Daniel Hailfinger
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



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Matthieu Herrb
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.
-- 
Matthieu Herrb



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Theo de Raadt
> 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.



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Stuart Henderson
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.



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Theo de Raadt
> > 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.



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Stuart Henderson
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)?



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Carl-Daniel Hailfinger
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

-- 
http://www.hailfinger.org/



Re: [flashrom] Porting flashrom to OpenBSD

2010-06-25 Thread Carl-Daniel Hailfinger
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 
>> 
>
> 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-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

-- 
http://www.hailfinger.org/