Hi,
Google Summer of Code 2010 is approaching quickly. I hope coreboot/flashrom are going to participate again, and to do that, we have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
Do we want to participate? Who is willing to mentor? Any developers who want to apply as students? Who will serve as organization administrator? Are there any good ideas for GSoC (coreboot or flashrom)?
Regards, Carl-Daniel
On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
Google Summer of Code 2010 is approaching quickly. I hope coreboot/flashrom are going to participate again, and to do that, we have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
Do we want to participate? Who is willing to mentor? Any developers who want to apply as students? Who will serve as organization administrator? Are there any good ideas for GSoC (coreboot or flashrom)?
I would like for coreboot to do GSoC again. I think it is great exposure for the project and I would be happy to be a mentor again. I'll put some thought into what prospective students might work on.
Marc
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-)
Regards,
Darmawan
On 3/5/10, Marc Jones marcj303@gmail.com wrote:
On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
Google Summer of Code 2010 is approaching quickly. I hope coreboot/flashrom are going to participate again, and to do that, we have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
Do we want to participate? Who is willing to mentor? Any developers who want to apply as students? Who will serve as organization administrator? Are there any good ideas for GSoC (coreboot or flashrom)?
I would like for coreboot to do GSoC again. I think it is great exposure for the project and I would be happy to be a mentor again. I'll put some thought into what prospective students might work on.
Marc
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
does coreboot and flashrom will join gsoc 2010 as an union or else? i am thinking who about making flashrom can be used under windows?
On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun <darmawan.salihun@gmail.com
wrote:
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-)
Regards,
Darmawan
On 3/5/10, Marc Jones marcj303@gmail.com wrote:
On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
Google Summer of Code 2010 is approaching quickly. I hope coreboot/flashrom are going to participate again, and to do that, we have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
Do we want to participate? Who is willing to mentor? Any developers who want to apply as students? Who will serve as organization administrator? Are there any good ideas for GSoC (coreboot or flashrom)?
I would like for coreboot to do GSoC again. I think it is great exposure for the project and I would be happy to be a mentor again. I'll put some thought into what prospective students might work on.
Marc
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
--
-= Human knowledge belongs to the world =-
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 06.03.2010 10:03, Jason Wang wrote:
On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-)
i am thinking who about making flashrom can be used under windows?
I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet.
does coreboot and flashrom will join gsoc 2010 as an union or else?
Yes, coreboot and flashrom will have one joint project for GSoC 2010.
Regards, Carl-Daniel
On 06.03.2010 14:45, Carl-Daniel Hailfinger wrote:
On 06.03.2010 10:03, Jason Wang wrote:
On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-)
i am thinking who about making flashrom can be used under windows?
I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet.
To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I have no idea if our coding style allows usage of old compilers for DOS.
Use a DOS extender and it should be fine.
//Peter
On 06.03.2010 16:05, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
I have no idea if our coding style allows usage of old compilers for DOS.
Use a DOS extender and it should be fine.
Not what I meant. AFAIK DJGPP is based on gcc 2.72, and that may not support the C99 features flashrom is using.
Regards, Carl-Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Not what I meant. AFAIK DJGPP is based on gcc 2.72, and that may not support the C99 features flashrom is using.
Well then compile with libpayload and write simple DOS wrapper to load it ;)
Rudolf
On 06.03.2010 23:47, Rudolf Marek wrote:
Not what I meant. AFAIK DJGPP is based on gcc 2.72, and that may not support the C99 features flashrom is using.
Well then compile with libpayload and write simple DOS wrapper to load it ;)
Brilliant idea. Not exactly what I had in mind, but certainly an option.
Regards, Carl-Daniel
Carl-Daniel Hailfinger napsal(a):
On 06.03.2010 23:47, Rudolf Marek wrote:
Not what I meant. AFAIK DJGPP is based on gcc 2.72, and that may not support the C99 features flashrom is using.
Well then compile with libpayload and write simple DOS wrapper to load it ;)
Brilliant idea. Not exactly what I had in mind, but certainly an option.
Well not so on the other look ;) One would need to do bit of I/O to/from file right? Maybe one could place the file to HIGMEM and after flashrom is finished write it back using normal dos ;)
Second possibility is to compile against the libpayload and use DPMI services to handle the I/O and even setup the protected mode. If one forces the compiler to output in COFF format one can even embedd the application in CSWDPMI ;)
Rudolf
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS.
On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reinauer@coresystems.de wrote:
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS.
YES! Flashrom as a coreboot payload would be truly awesome!
On 06.03.2010 16:19, Joseph Smith wrote:
On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reinauer@coresystems.de wrote:
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS.
YES! Flashrom as a coreboot payload would be truly awesome!
Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.)
Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer: 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements).
Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-)
Regards, Carl-Daniel
On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 16:19, Joseph Smith wrote:
On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reinauer@coresystems.de wrote:
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS.
YES! Flashrom as a coreboot payload would be truly awesome!
Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.)
Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer:
- Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements).
Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-)
What about Variant 1 but with Kconfig options to choose only certain flash chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible :-)
On Sat, 06 Mar 2010 11:22:06 -0500, Joseph Smith joe@settoplinux.org wrote:
On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 16:19, Joseph Smith wrote:
On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reinauer@coresystems.de wrote:
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS.
YES! Flashrom as a coreboot payload would be truly awesome!
Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.)
Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer:
- Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements).
Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-)
What about Variant 1 but with Kconfig options to choose only certain
flash
chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible
:-)
Or like Stefan said, just make it part of FILO, that way it already has disk access to find the bios image to flash.
On 06.03.2010 17:22, Joseph Smith wrote:
On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 16:19, Joseph Smith wrote:
YES! Flashrom as a coreboot payload would be truly awesome!
- Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed).
Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast.
What about Variant 1 but with Kconfig options to choose only certain flash chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible :-)
While it would be cool, this needs a completely working coreboot including VGA init (how would you interact with the system otherwise), and if that works, you can usually run Linux anyway or at least load some code from disk or from the network (the place where the new image would live).
So yes, would be a neat gimmick, but IMHO of limited value.
Regards, Carl-Daniel
On 3/6/10 5:13 PM, Carl-Daniel Hailfinger wrote:
Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer:
- Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements).
Just having it as a FILO add-on would be the best solution. Then it can use all the FILO infrastructure (reading lots of filesystems, using a recovery with a nice menu on a USB stick, integrate with the flash protection that FILO offers (lock flash writes before FILO executes external code for example)
Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
I agree all those variants have some drawbacks...
Stefan
On 06.03.2010 18:50, Stefan Reinauer wrote:
On 3/6/10 5:13 PM, Carl-Daniel Hailfinger wrote:
- Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements).
Just having it as a FILO add-on would be the best solution. Then it can use all the FILO infrastructure (reading lots of filesystems, using a recovery with a nice menu on a USB stick,
OTOH, it could simply be an ELF loaded by FILO. That allows upgrades of flashrom as needed, and if FILO can load flash images from any media, it should be able to do the same with executable code.
integrate with the flash protection that FILO offers (lock flash writes before FILO executes external code for example)
Now that is indeed a compelling reason to have FILO support flashing. Then again, if flashrom-in-FILO doesn't check a cryptographic signature of the new flash image, the flash protection effect is rather limited.
Anyway, I can do it if you let me do it.
Regards, Carl-Daniel
It would be nice, if a flashrom is in there, to also have some sort of security too I think.
Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity.
Is it even possible?
The only thing I really trust is a jumper, but nobody seems to put those in any more. A pity.
thanks
ron
On 06.03.2010 19:52, ron minnich wrote:
It would be nice, if a flashrom is in there, to also have some sort of security too I think.
Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity.
Is it even possible?
Well, I implemented signature checking for coreboot (so that only signed payloads would be executed).
The big question is: Do you want to protect against 1. someone with full hardware access (developer), 2. someone sitting in front of the machine but without hardware access (computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware. Second category should be easily achieved by requiring a signed boot image for a non-lockdown boot. A default boot would be with locked down flash, and only a special kernel/payload/bootable-file-on-disk would be able to reflash. Needs chipset cooperation and/or one-shot GPIOs. Third category would allow the user to select an unlocked boot. Locked boot would be default, and the setting would not be stored anywhere to avoid circumvention.
The only thing I really trust is a jumper, but nobody seems to put those in any more. A pity.
At least one modern flash chip ignores the write protect pin for some erase commands. A jumper won't help here. Chipset lockdown can be circumvented as well. If you really want a rootkit-resistant protection, you need two flash chips and some additional circuitry.
(I once worked as an infosec penetration tester, and it shows. I don't believe in magic, nor do I believe in correct operation of any chip under non-standard conditions.)
Regards, Carl-Daniel
On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 19:52, ron minnich wrote:
It would be nice, if a flashrom is in there, to also have some sort of security too I think.
Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity.
Is it even possible?
Well, I implemented signature checking for coreboot (so that only signed payloads would be executed).
The big question is: Do you want to protect against
- someone with full hardware access (developer),
- someone sitting in front of the machine but without hardware access
(computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware.
I agree completely.
Second category should be easily achieved by requiring a signed boot image for a non-lockdown boot. A default boot would be with locked down flash, and only a special kernel/payload/bootable-file-on-disk would be able to reflash. Needs chipset cooperation and/or one-shot GPIOs. Third category would allow the user to select an unlocked boot. Locked boot would be default, and the setting would not be stored anywhere to avoid circumvention.
3 is the biggest concern. For me, anyway. (2) is close however.
At least one modern flash chip ignores the write protect pin for some erase commands. A jumper won't help here.
WHO designs this stuff? it would be nice to have a blacklist for such poor designs.
Chipset lockdown can be circumvented as well. If you really want a rootkit-resistant protection, you need two flash chips and some additional circuitry.
(I once worked as an infosec penetration tester, and it shows. I don't believe in magic, nor do I believe in correct operation of any chip under non-standard conditions.)
I'm glad you're on OUR side :-)
ron
On 3/6/10 9:17 PM, ron minnich wrote:
On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 19:52, ron minnich wrote:
It would be nice, if a flashrom is in there, to also have some sort of security too I think.
Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity.
Is it even possible?
Well, I implemented signature checking for coreboot (so that only signed payloads would be executed).
The big question is: Do you want to protect against
- someone with full hardware access (developer),
- someone sitting in front of the machine but without hardware access
(computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware.
I agree completely.
Also, the question is what kind of privilege escalation can be caused by a security breach. While you can always solder a new flash chip on an x86 system these days you can still encrypt your data in order to protect (read) access.
3 is the biggest concern. For me, anyway. (2) is close however.
Someone sitting in front of the machine usually does have hardware access, so the differentiation is kind of artificial unless you count the people forgetting to bring soldering irons and screw drivers.
Stefan
On 07.03.2010 00:02, Stefan Reinauer wrote:
On 3/6/10 9:17 PM, ron minnich wrote:
On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger wrote:
Well, I implemented signature checking for coreboot (so that only signed payloads would be executed).
The big question is: Do you want to protect against
- someone with full hardware access (developer),
- someone sitting in front of the machine but without hardware access
(computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware.
I agree completely.
Also, the question is what kind of privilege escalation can be caused by a security breach. While you can always solder a new flash chip on an x86 system these days you can still encrypt your data in order to protect (read) access.
It depends on the security model. If you store the encryption key in the ROM, people can read it out if they have hardware access. If there are protections in place against such readout, there is still the chance to rig something with the help of SerialICE.
3 is the biggest concern. For me, anyway. (2) is close however.
Someone sitting in front of the machine usually does have hardware access, so the differentiation is kind of artificial unless you count the people forgetting to bring soldering irons and screw drivers.
I hope someone questions/stops you if you decide to bring screwdrivers and a soldering iron to a shared student computer room and start taking apart one of the machines. Then again, doing this is basic social engineering, and if you are bold enough and ask loudly in that computer room for someone to assist you, most people will think the operation is entirely legit.
In the end, what we need is a detailed security model which includes a good understanding of the threat we want to protect against. Doing many "security things" is not a fix for anything, but a hand-tailored solution has the chance of addressing one given problem.
Regards, Carl-Daniel
On 3/6/10 8:28 PM, Carl-Daniel Hailfinger wrote:
On 06.03.2010 19:52, ron minnich wrote:
It would be nice, if a flashrom is in there, to also have some sort of security too I think.
Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity.
Is it even possible?
Well, I implemented signature checking for coreboot (so that only signed payloads would be executed).
When coresystems developed our first version of hard crypto signature checking for firmware in 2007/2008 we explicitly decided to not check the payload but only let the payload check further stages. The reason was that if you're able to compromise the flash chip, you're able to reprogram coreboot just as well as the payload. Also, we didn't want feel comfortable to duplicate the amount of crypto code in the flash, and there is no serious mechanism around that protects only the bootblock, at least not on commonly used systems.
So I'm interested to hear your reasons to do this in coreboot itself... Is your code publically available somewhere?
Regards, Stefan
On 06.03.2010 23:57, Stefan Reinauer wrote:
On 3/6/10 8:28 PM, Carl-Daniel Hailfinger wrote:
On 06.03.2010 19:52, ron minnich wrote:
It would be nice, if a flashrom is in there, to also have some sort of security too I think.
Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity.
Is it even possible?
Well, I implemented signature checking for coreboot (so that only signed payloads would be executed).
When coresystems developed our first version of hard crypto signature checking for firmware in 2007/2008 we explicitly decided to not check the payload but only let the payload check further stages. The reason was that if you're able to compromise the flash chip, you're able to reprogram coreboot just as well as the payload. Also, we didn't want feel comfortable to duplicate the amount of crypto code in the flash, and there is no serious mechanism around that protects only the bootblock, at least not on commonly used systems.
Indeed.
So I'm interested to hear your reasons to do this in coreboot itself... Is your code publically available somewhere?
Code: http://www.mail-archive.com/coreboot@coreboot.org/msg17372.html Thesis by Rene Reuter: http://sit.sit.fraunhofer.de/smv/publications/downloads/KonzeptTrustedBoot_R... Reasons: Basically, I did it for fun, and because Rene was stuck trying to include OpenSSL in coreboot. I simply coded up a working alternative. And yes, I agree that checking the payload is pointless if flash protection is either full-on (not needed) or full-off (attacker can modify coreboot itself). The only halfway reasonable use case would be if coreboot is in a write protected part of the flash chip and the payload is in an unprotected part of the flash chip.
Regards, Carl-Daniel
On Sat, Mar 6, 2010 at 8:13 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
- Tiny flashrom stub for remote flashing over serial/network/whatever
(~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). ... Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
I implemented a little hack a while ago that let you download a payload via xmodem over serial:
http://www.coreboot.org/pipermail/coreboot/2006-October/016120.html
It looks like most of the code has since vanished, but the xmodemReceive() function is still there, and might be useful for some kind of last-ditch failover mechanism.
--Ed
On Mon, 8 Mar 2010 16:04:31 -0800, Ed Swierk eswierk@aristanetworks.com wrote:
On Sat, Mar 6, 2010 at 8:13 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
- Tiny flashrom stub for remote flashing over serial/network/whatever
(~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). ... Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
I implemented a little hack a while ago that let you download a payload via xmodem over serial:
http://www.coreboot.org/pipermail/coreboot/2006-October/016120.html
It looks like most of the code has since vanished, but the xmodemReceive() function is still there, and might be useful for some kind of last-ditch failover mechanism.
We also have a small program on Set-Top-Linux to send flash commands to the original bios over Serial Console:
http://www.settoplinux.org/index.php?title=RCA_RM4100:Howto_coreboot_and_Lin...
You just copy bios image to drive, boot, and flash over serial console. It may be nothing, but it could be a start to something that could be used for recovery???
On 09.03.2010 01:16, Joseph Smith wrote:
On Mon, 8 Mar 2010 16:04:31 -0800, Ed Swierk eswierk@aristanetworks.com wrote:
On Sat, Mar 6, 2010 at 8:13 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
- Tiny flashrom stub for remote flashing over serial/network/whatever
(~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). ... Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
I implemented a little hack a while ago that let you download a payload via xmodem over serial:
http://www.coreboot.org/pipermail/coreboot/2006-October/016120.html
Right, I had remembered such a think existed, but didn't know where to look.
It looks like most of the code has since vanished, but the xmodemReceive() function is still there, and might be useful for some kind of last-ditch failover mechanism.
Absolutely. It is definitely good for payload/whateveryoucallit download once CAR or RAM is working.
We also have a small program on Set-Top-Linux to send flash commands to the original bios over Serial Console:
http://www.settoplinux.org/index.php?title=RCA_RM4100:Howto_coreboot_and_Lin...
You just copy bios image to drive, boot, and flash over serial console. It may be nothing, but it could be a start to something that could be used for recovery???
AFAICS the trick you mentioned works by uploading a small flasher program to the RM4100 memory in a place where it overwrites existing code, causing execution to continue at the inserted code. Very neat. It needs a way to upload a program over serial to RAM to work at all, though.
Anyway, we'll see what the optimal solution is, and how it works out. IMHO one key to success is to have multiple options, and enable some sort of recovery for all of them.
Regards, Carl-Daniel
As a project, I'd still like to see someone try the "serialice as bootblock" and see how it goes.
Let me explain. At the meeting in 2006, we decided it would be nice to have an "all is lost" mode wherein we'd flash a new image from the serial port. I still like this idea. I think serialice would be the foundation of this capability.
If a given mainboard could be extended to include the basic commands for flashing, then we could experiment with this model. Coreboot would need to be modified, mainly to allow it to be loaded into lower-than-top-64k, but we do this already: it's called the "normal" build.
I think all the bits are there, they just need assembly. This model would be *ideal* for me on the Dell cluster, even better than the old normal/fallback model.
Not well defined, I realize, but I'd be happy to mentor someone who wanted to give this a try.
ron
On 06.03.2010 18:12, ron minnich wrote:
As a project, I'd still like to see someone try the "serialice as bootblock" and see how it goes.
Let me explain. At the meeting in 2006, we decided it would be nice to have an "all is lost" mode wherein we'd flash a new image from the serial port. I still like this idea. I think serialice would be the foundation of this capability.
If a given mainboard could be extended to include the basic commands for flashing, then we could experiment with this model. Coreboot would need to be modified, mainly to allow it to be loaded into lower-than-top-64k, but we do this already: it's called the "normal" build.
I think all the bits are there, they just need assembly. This model would be *ideal* for me on the Dell cluster, even better than the old normal/fallback model.
Not well defined, I realize, but I'd be happy to mentor someone who wanted to give this a try.
Oh, I would definitely be interested (well, it is variant 2 of my proposal), but due to the hard requirements of flashing, the code either has to run from CAR or from RAM. Not only the stack, but also the code has to be outside flash. Why? Simple. During write or erase of any Parallel/LPC/FWH chip, all reads are guaranteed to return garbage (bit 6 and 7 are reserved for JEDEC completion detection on some chips, other chips simply return the status register instead of valid data). That means instruction fetch from ROM has to be avoided at all costs. SPI isn't much better, many datasheets mention that the results of reads during erase/write are undefined. Please note that this is not the fault of flashrom (no other flashing software would be able to cope either).
There are three points in time where the "all is lost" code can be run in theory: 1. Without CAR or RAM. No reflashing possible (see above). 2. With CAR and without RAM. Works as long as the CPU can execute code from CAR and at the same time have either a stack in CAR (neat) or store a few bytes elsewhere (but it needs ROMCC for that). 3. With RAM. No limitations here.
Regards, Carl-Daniel
Hi,
I updated http://www.coreboot.org/GSoC with my project ideas and some basic information. Please update the wiki with your own ideas and fix the stuff I forgot.
Thank you.
Regards, Carl-Daniel
On 3/6/10, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 10:03, Jason Wang wrote:
On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-)
i am thinking who about making flashrom can be used under windows?
I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet.
OK. Looking into it now ;-). I'm not well versed with Windows 7 driver model yet. I'm gonna need to working on it nonetheless, for my book. I'll let you guys know.
does coreboot and flashrom will join gsoc 2010 as an union or else?
Yes, coreboot and flashrom will have one joint project for GSoC 2010.
Regards, Carl-Daniel
-- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth
Regards,
Darmawan
[followup to flashrom@flashrom.org please]
On 06.03.2010 22:07, Darmawan Salihun wrote:
On 3/6/10, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 10:03, Jason Wang wrote:
On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-)
i am thinking who about making flashrom can be used under windows?
I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet.
OK. Looking into it now ;-). I'm not well versed with Windows 7 driver model yet. I'm gonna need to working on it nonetheless, for my book. I'll let you guys know.
Cool, thanks.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Darmawan Salihun -
Ed Swierk -
Jason Wang -
Joseph Smith -
Marc Jones -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer -
Stefan Reinauer