Re: [coreboot] cmos.layout upgradability
On 26.01.2014 05:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing >> >> (which mentions another solution to the problem) >> > Flashrom solution is interesting but it doesn't handle external > flashing. It would be a nice addition to checksums for internal flashing > though. > Patrick's solution would have only one advantage compared to my > prototype: possibility of coreboot migrating the options rather than > resetting. Patrick's solution relies on mathematical impossibility. You can't have such function with only 16-bit salt. Let's take any partition of 248 (see http://mathworld.wolfram.com/PartitionFunctionP.html), then create options A,B,C,... with sizes according to this partition. The hashing function as per Patrick's proposal would have to map them to non-interlapping regions. By evaluating this function at A,B,C,... you can extract the partition if number of chunks is known. Since number of chunks is an integer from 1 to 248 so the function has to store at least: Log2[PartitionsP[248]]-Log2[248]> 39 bits of information. So salt has to be at least 40 bits. Probably even more if you put into mix that we also need sub-byte options and you have to handle option names. This means: 1) You can't bruteforce such a parameter space during compile, so some structure is needed. 2) You'll need more than 40 bits of storage in CMOS. At this point I feel like Patrick's proposal is not practical. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
> http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing > > (which mentions another solution to the problem) > Flashrom solution is interesting but it doesn't handle external flashing. It would be a nice addition to checksums for internal flashing though. Patrick's solution would have only one advantage compared to my prototype: possibility of coreboot migrating the options rather than resetting. But there is a problem with attempting this: when you request for option the hashing would always give a number, even if that option doesn't exist. And then we're back to reading garbage for new options. >> 2a) instead of having separate field we could make XOR layout checksum >> into CMOS checksum. This would save 2 bytes but will break any existing >> users if they check checksum. > > (IIRC we already have problems with the Linux nvram driver which does > checksumming somehow differently. Or maybe that was fixed already.) > Ok. Let's hold 2a in reserve if 2 bytes is considered too expensive > ...but the above reminded me that it is ultimately a responsibility > of our source code and our design to never let booting fail simply > due to some garbage in NVRAM. > > Code and design really must ensure a working state. > There are number of problems with this: 1) Overclocking options. If you overclock too much, you don't boot successfully. 2) FILO uses options to control its behaviour. If by garbage tells to boot from bad filename, it will probably stop unable to find the file. 3) vbnv field may be a problem. Even if this goal is achieved we still need an upgrade way as new option with garbage may make the system bootable but uncomfortable to most of users, which is to avoid. E.g. disabling touchpad: I personally disable touchpad (but through OS facilities, not coreboot) but many users would get confused by disabled touchpad. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
Vladimir 'φ-coder/phcoder' Serbinenko wrote: > I feel like we should have a way to update options safely. Thanks for starting the thread. I hope we'll hear comments on this from all parts of the community. It's a fairly important topic, since it impacts every single board. Even if individual boards using coreboot in production typically do not have new NVRAM settings added, there may be tree-wide options added, and it's important that everything in the field continues to work if a newer version of coreboot is deployed. There is also previous work on the topic: http://www.coreboot.org/Infrastructure_Projects#CMOS_handling in particular: http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing (which mentions another solution to the problem) > 2) Have some version field to check and if it mismatches reset CMOS > to default. To avoid having to maintain version manually I propose to > checksum option table and write 16-bit result to CMOS. This does seem like a reasonable approach, but... > 2a) instead of having separate field we could make XOR layout checksum > into CMOS checksum. This would save 2 bytes but will break any existing > users if they check checksum. (IIRC we already have problems with the Linux nvram driver which does checksumming somehow differently. Or maybe that was fixed already.) Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > And why would you need to reset CMOS if trackpad is disabled? > > > > # nvramtool -a > > # nvramtool -w trackpad_enable=Enable > > You could do it in this particular case but user isn't required to know > this. And settings may be something more drammatic. It may happen that > the system doesn't boot with garbage settings at all. The fact that you > have to handle garbage in saved option indicates that something is wrong. ...but the above reminded me that it is ultimately a responsibility of our source code and our design to never let booting fail simply due to some garbage in NVRAM. Code and design really must ensure a working state. Until there exists an update path it's obviously not future proof to add new options to any mainboard. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
On 25.01.2014 01:28, mrnuke wrote: > On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' > Serbinenko wrote: >> Hello, all. Due to my failue to foresee this problem if one upgrades X60 >> coreboot, you need to manually reset CMOS config or your trackpad may >> not work as option "trackpad_enable" will get a garbage value. While I >> admit my part of fault, I feel like we should have a way to update >> options safely. I see following possibilities: >> 1) Hide ourselves and tell that on upgrade you always have to clear >> CMOS. I don't think it's really an option as users will continue just >> running flashrom and in case of external flashing, CMOS reset may >> require full power removal with cell battery sometimes in difficult to >> access places inside laptop. >> 2) Have some version field to check and if it mismatches reset CMOS to >> default. To avoid having to maintain version manually I propose to >> checksum option table and write 16-bit result to CMOS. 16-bit should >> give enough confidence without excessively using CMOS. I've made a >> prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree >> that it's a right approach, I'll make this prototype into complete patch >> (mostly missing is laborous adding of version field) >> 2a) instead of having separate field we could make XOR layout checksum >> into CMOS checksum. This would save 2 bytes but will break any existing >> users if they check checksum. > > You mean it won't write the cmos.default after upgrade? > Not it won't. Checksum covers the same range and is at same position. So checksum is still valid. > And why would you need to reset CMOS if trackpad is disabled? > > # nvramtool -a > # nvramtool -w trackpad_enable=Enable > You could do it in this particular case but user isn't required to know this. And settings may be something more drammatic. It may happen that the system doesn't boot with garbage settings at all. The fact that you have to handle garbage in saved option indicates that something is wrong. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Hello, all. Due to my failue to foresee this problem if one upgrades X60 > coreboot, you need to manually reset CMOS config or your trackpad may > not work as option "trackpad_enable" will get a garbage value. While I > admit my part of fault, I feel like we should have a way to update > options safely. I see following possibilities: > 1) Hide ourselves and tell that on upgrade you always have to clear > CMOS. I don't think it's really an option as users will continue just > running flashrom and in case of external flashing, CMOS reset may > require full power removal with cell battery sometimes in difficult to > access places inside laptop. > 2) Have some version field to check and if it mismatches reset CMOS to > default. To avoid having to maintain version manually I propose to > checksum option table and write 16-bit result to CMOS. 16-bit should > give enough confidence without excessively using CMOS. I've made a > prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree > that it's a right approach, I'll make this prototype into complete patch > (mostly missing is laborous adding of version field) > 2a) instead of having separate field we could make XOR layout checksum > into CMOS checksum. This would save 2 bytes but will break any existing > users if they check checksum. You mean it won't write the cmos.default after upgrade? And why would you need to reset CMOS if trackpad is disabled? # nvramtool -a # nvramtool -w trackpad_enable=Enable -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] cmos.layout upgradability
Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option "trackpad_enable" will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
