Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31788 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2023-04-19 19:06 -0700 |
| Last post | 2023-04-27 18:27 +0200 |
| Articles | 20 on this page of 85 — 14 participants |
Back to article view | Back to comp.arch.embedded
Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-19 19:06 -0700
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-20 12:14 +0300
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 06:18 -0700
Re: Embedding a Checksum in an Image File "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2023-04-20 11:30 +0000
Re: Embedding a Checksum in an Image File dalai lamah <antonio12358@hotmail.com> - 2023-04-20 13:47 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 06:04 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-20 16:46 +0200
Re: Embedding a Checksum in an Image File George Neuner <gneuner2@comcast.net> - 2023-04-20 11:33 -0400
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 09:45 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-20 22:26 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:36 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:12 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:35 +0200
Re: Embedding a Checksum in an Image File George Neuner <gneuner2@comcast.net> - 2023-04-20 16:44 -0400
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-20 22:37 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-21 12:43 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-21 04:39 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-21 16:50 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-21 17:29 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 16:57 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-04-24 00:32 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-24 16:37 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-05-03 00:15 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-05-03 14:48 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-05-09 20:42 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-05-10 10:06 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-05-10 12:03 +0200
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-08-05 01:48 -0700
Re: Embedding a Checksum in an Image File Don Y <blockedofcourse@foo.invalid> - 2023-08-05 01:42 -0700
Re: Embedding a Checksum in an Image File Stefan Reuther <stefan.news@arcor.de> - 2023-04-21 19:40 +0200
Re: Embedding a Checksum in an Image File Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2023-04-20 20:17 +0300
Re: Embedding a Checksum in an Image File George Neuner <gneuner2@comcast.net> - 2023-04-20 16:49 -0400
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-20 22:09 -0400
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-20 19:41 -0700
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-21 19:30 -0400
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-21 01:53 -0700
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-21 05:12 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-21 17:02 +0200
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-21 16:56 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 17:01 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-21 20:14 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 17:13 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-22 09:56 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-22 19:54 +0200
Re: Embedding a Checksum in an Image File Grant Edwards <invalid@invalid.invalid> - 2023-04-22 20:05 +0000
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-23 17:37 +0200
Re: Embedding a Checksum in an Image File Grant Edwards <invalid@invalid.invalid> - 2023-04-23 17:37 +0000
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-23 23:45 +0200
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-23 18:16 -0400
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-24 09:13 +0200
Re: Embedding a Checksum in an Image File boB <boB@K7IQ.com> - 2023-04-22 13:41 -0700
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-23 10:34 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-23 23:58 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-23 15:24 -0700
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-24 09:17 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-24 01:07 -0700
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:42 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:20 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:44 +0200
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-21 16:52 -0700
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-21 20:23 -0700
Re: Embedding a Checksum in an Image File Brian Cockburn <brian.cockburn.1959@gmail.com> - 2023-04-22 07:07 -0700
Re: Embedding a Checksum in an Image File Richard Damon <Richard@Damon-Family.org> - 2023-04-22 10:31 -0400
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-22 09:54 -0700
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:26 +0200
Re: Embedding a Checksum in an Image File Rick C <gnuarm.deletethisbit@gmail.com> - 2023-04-27 10:09 -0700
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-27 21:29 +0300
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-27 21:39 +0300
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 22:44 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:38 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:50 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 15:04 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-29 23:03 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-30 16:19 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-05-09 20:34 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-05-10 10:18 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:33 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 22:36 +0200
Re: Embedding a Checksum in an Image File Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-04-28 01:10 +0300
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:54 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 09:24 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-28 10:56 +0200
Re: Embedding a Checksum in an Image File David Brown <david.brown@hesbynett.no> - 2023-04-28 15:09 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-29 23:02 +0200
Re: Embedding a Checksum in an Image File Ulf Samuelsson <ulf.r.samuelsson@gmail.com> - 2023-04-27 18:27 +0200
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-04-21 20:23 -0700 |
| Message-ID | <52b5ae94-a5b4-4dc0-8e79-d27a9a4f2805n@googlegroups.com> |
| In reply to | #31812 |
On Friday, April 21, 2023 at 7:52:27 PM UTC-4, Brian Cockburn wrote: > On Friday, April 21, 2023 at 10:12:49 PM UTC+10, Rick C wrote: > > On Friday, April 21, 2023 at 4:53:18 AM UTC-4, Brian Cockburn wrote: > > > On Thursday, April 20, 2023 at 12:06:36 PM UTC+10, Rick C wrote: > > > > This is a bit of the chicken and egg thing. If you want a embed a checksum in a code module to report the checksum, is there a way of doing this? It's a bit like being your own grandfather, I think. > > > > > > > > I'm not thinking anything too fancy, like a CRC, but rather a simple modulo N addition, maybe N being 2^16. > > > > > > > > I keep thinking of using a placeholder, but that doesn't seem to work out in any useful way. Even if you try to anticipate the impact of adding the checksum, that only gives you a different checksum, that you then need to anticipate further... ad infinitum. > > > > > > > > I'm not thinking of any special checksum generator that excludes the checksum data. That would be too messy. > > > > > > > > I keep thinking there is a different way of looking at this to achieve the result I want... > > > > > > > > Maybe I can prove it is impossible. Assume the file checksums to X when the checksum data is zero. The goal would then be to include the checksum data value Y in the file, that would change X to Y. Given the properties of the module N checksum, this would appear to be impossible for the general case, unless... Add another data value, called, checksum normalizer. This data value checksums with the original checksum to give the result zero. Then, when the checksum is also added, the resulting checksum is, in fact, the checksum. Another way of looking at this is to add a value that combines with the added checksum, to be zero, leaving the original checksum intact. > > > > > > > > This might be inordinately hard for a CRC, but a simple checksum would not be an issue, I think. At least, this could work in software, where data can be included in an image file as itself. In a device like an FPGA, it might not be included in the bit stream file so directly... but that might depend on where in the device it is inserted. Memory might have data that is stored as itself. I'll need to look into that. > > > > > > > > -- > > > > > > > > Rick C. > > > > > > > > - Get 1,000 miles of free Supercharging > > > > - Tesla referral code - https://ts.la/richard11209 > > > Rick, What is the purpose of this? Is it (1) to be able to externally identify a binary, as one might a ROM image by computing a checksum? Is it (2) for a run-able binary to be able to check itself? This would of course only be able to detect corruption, not tampering. Is it (3) for the loader (whatever that might be) to be able to say 'this binary has the correct checksum' and only jump to it if it does? Again this would only be able to detect corruption, not tampering. Are you hoping for more than corruption detection? > > This is simply to be able to say this version is unique, regardless of what the version number says. Version numbers are set manually and not always done correctly. I'm looking for something as a backup so that if the checksums are different, I can be sure the versions are not the same. > > > > The less work involved, the better. > > > > -- > > > > Rick C. > > > > ++ Get 1,000 miles of free Supercharging > > ++ Tesla referral code - https://ts.la/richard11209 > Rick, so you want the executable to, as part of its execution, print on the console the 'checksum' of itself? Or do you want to be able to inspect the executable with some other tool to calculate its 'checksum'? For the latter there are lots of tools to do that (your OS or PROM programmer for instance), for the former you need to embed the calculation code into the executable (along with the length over which to calculate) and run this when asked. Neither of these involve embedding the 'checksum' value. > And just to be sure I understand what you wrote in a somewhat convoluted way. When you have two binary executables that report the same version number you want to be able to distinguish them with a 'checksum', right? Yes, I want the checksum to be readable while operating. Calculation code??? Not going to happen. That's why I want to embed the checksum. Yes, two compiled files which ended up with the same version number by error. We are using an 8 bit version number, so two hex digits. Negative numbers are lab versions, positive numbers are releases, so 64 of each. We don't do a lot of actual work on the hardware. This code usually is 99.9% working by the time it is tested on hardware. So no need for lots of rev numbers. But sometimes, in the lab, the rev number is not bumped when it should be. The checksum will tell us if we are working with different revisions in that case. So far, it looks like a simple checksum is the way to go. Include the checksum and the 2's complement of the checksum (in locations that were zeros), and the checksum will not change. -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Brian Cockburn <brian.cockburn.1959@gmail.com> |
|---|---|
| Date | 2023-04-22 07:07 -0700 |
| Message-ID | <58ed7e73-759a-4741-aee6-de44f330be1cn@googlegroups.com> |
| In reply to | #31816 |
Rick, >> Rick, so you want the executable to, as part of its execution, print on the console the 'checksum' of itself? Or do you want to be able to inspect the executable with some other tool to calculate its 'checksum'? For the latter there are lots of tools to do that (your OS or PROM programmer for instance), for the former you need to embed the calculation code into the executable (along with the length over which to calculate) and run this when asked. Neither of these involve embedding the 'checksum' value. >> And just to be sure I understand what you wrote in a somewhat convoluted way. When you have two binary executables that report the same version number you want to be able to distinguish them with a 'checksum', right? > > Yes, I want the checksum to be readable while operating. Calculation code??? Not going to happen. That's why I want to embed the checksum. Can you expand on what you mean or expect by 'readable while operating' please? Are you planning to use some sort of tool to inspect the executing binary to 'read' this thing, or provoke output to the console in some way like: $ run my-binary-thing --checksum 10FD $ This would be as distinct from: $ run my-binary-thing --version -52 $ > Yes, two compiled files which ended up with the same version number by error. We are using an 8 bit version number, so two hex digits. Negative numbers are lab versions, positive numbers are releases, so 64 of each. Signed 8-bit numbers range from -128 to +127 (0x80 to 0x7F) so probably a few more than 64. > ... sometimes, in the lab, the rev number is not bumped when it should be. This may be an indicator that better procedures are needed for code review-for-release. And that in independent pair of eyes should be doing the review against an agreed check list. > So far, it looks like a simple checksum is the way to go. Include the checksum and the 2's complement of the checksum (in locations that were zeros), and the checksum will not change. How will the checksum 'not change'? It will be different for every build won't it? Cheers, Brian.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-04-22 10:31 -0400 |
| Message-ID | <odS0M.292423$wfQc.236913@fx43.iad> |
| In reply to | #31818 |
On 4/22/23 10:07 AM, Brian Cockburn wrote: > Rick, > >> So far, it looks like a simple checksum is the way to go. Include the checksum and the 2's complement of the checksum (in locations that were zeros), and the checksum will not change. > > How will the checksum 'not change'? It will be different for every build won't it? > > Cheers, Brian. He means the checksum of the file for a given build after the modification will be the same as the checksum of the file before the modification.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-04-22 09:54 -0700 |
| Message-ID | <08922ed4-b36b-4698-bce1-b8615d2ccfd9n@googlegroups.com> |
| In reply to | #31818 |
On Saturday, April 22, 2023 at 10:07:37 AM UTC-4, Brian Cockburn wrote: > Rick, > >> Rick, so you want the executable to, as part of its execution, print on the console the 'checksum' of itself? Or do you want to be able to inspect the executable with some other tool to calculate its 'checksum'? For the latter there are lots of tools to do that (your OS or PROM programmer for instance), for the former you need to embed the calculation code into the executable (along with the length over which to calculate) and run this when asked. Neither of these involve embedding the 'checksum' value. > >> And just to be sure I understand what you wrote in a somewhat convoluted way. When you have two binary executables that report the same version number you want to be able to distinguish them with a 'checksum', right? > > > > Yes, I want the checksum to be readable while operating. Calculation code??? Not going to happen. That's why I want to embed the checksum. > Can you expand on what you mean or expect by 'readable while operating' please? Are you planning to use some sort of tool to inspect the executing binary to 'read' this thing, or provoke output to the console in some way like: > > $ run my-binary-thing --checksum > 10FD > $ > > This would be as distinct from: > > $ run my-binary-thing --version > -52 > $ More like $ run my-binary thing Hello, master. Would you like to achieve world domination today? > No, thank you, can you display the contents of registers 26 and 27 in hex please? That would be X0FE38 > Thank you. > > Yes, two compiled files which ended up with the same version number by error. We are using an 8 bit version number, so two hex digits. Negative numbers are lab versions, positive numbers are releases, so 64 of each. > Signed 8-bit numbers range from -128 to +127 (0x80 to 0x7F) so probably a few more than 64. See? This is why I need the checksum. I make mistakes. > > ... sometimes, in the lab, the rev number is not bumped when it should be. > > This may be an indicator that better procedures are needed for code review-for-release. And that in independent pair of eyes should be doing the review against an agreed check list. Or that I need a checksum. This is a lab compile, not a release. Let's try to stay on task. > > So far, it looks like a simple checksum is the way to go. Include the checksum and the 2's complement of the checksum (in locations that were zeros), and the checksum will not change. > How will the checksum 'not change'? It will be different for every build won't it? It won't be changed by including the checksum and the complement because they add up to zero. -- Rick C. -+- Get 1,000 miles of free Supercharging -+- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-04-27 18:26 +0200 |
| Message-ID | <105b1cab-9e5f-91b3-1de6-99586246ecbd@gmail.com> |
| In reply to | #31788 |
Den 2023-04-20 kl. 04:06, skrev Rick C:
> This is a bit of the chicken and egg thing. If you want a embed a checksum in a code module to report the checksum, is there a way of doing this? It's a bit like being your own grandfather, I think.
>
The proper way to do this is to have a directive in the linker.
This reserves space for the CRC and defines the area where the CRC is
calculated.
I am not aware of any linker which support this.
Two months ago, I added the DIGEST directive to binutils aka the GNU
linker. It was committed, but then people realized that I had not signed
an agreement with Free Software Foundation.
Since part of the code I pushed was from a third party which released
their code under MIT, the licensing has not been resolved yet
but the patch is in binutils git, but reverted.
You would write (IIRC):
DIGEST "CRC64-ECMA", (from, to)
and the linker would reserve 8 bytes which is filled with the CRC in the
final link stage.
/Ulf
> I'm not thinking anything too fancy, like a CRC, but rather a simple modulo N addition, maybe N being 2^16.
>
> I keep thinking of using a placeholder, but that doesn't seem to work out in any useful way. Even if you try to anticipate the impact of adding the checksum, that only gives you a different checksum, that you then need to anticipate further... ad infinitum.
>
> I'm not thinking of any special checksum generator that excludes the checksum data. That would be too messy.
>
> I keep thinking there is a different way of looking at this to achieve the result I want...
>
> Maybe I can prove it is impossible. Assume the file checksums to X when the checksum data is zero. The goal would then be to include the checksum data value Y in the file, that would change X to Y. Given the properties of the module N checksum, this would appear to be impossible for the general case, unless... Add another data value, called, checksum normalizer. This data value checksums with the original checksum to give the result zero. Then, when the checksum is also added, the resulting checksum is, in fact, the checksum. Another way of looking at this is to add a value that combines with the added checksum, to be zero, leaving the original checksum intact.
>
> This might be inordinately hard for a CRC, but a simple checksum would not be an issue, I think. At least, this could work in software, where data can be included in an image file as itself. In a device like an FPGA, it might not be included in the bit stream file so directly... but that might depend on where in the device it is inserted. Memory might have data that is stored as itself. I'll need to look into that.
>
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-04-27 10:09 -0700 |
| Message-ID | <b62a77f7-3a13-4d76-b7cb-c42902595751n@googlegroups.com> |
| In reply to | #31855 |
On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote: > Den 2023-04-20 kl. 04:06, skrev Rick C: > > This is a bit of the chicken and egg thing. If you want a embed a checksum in a code module to report the checksum, is there a way of doing this? It's a bit like being your own grandfather, I think. > > > The proper way to do this is to have a directive in the linker. > This reserves space for the CRC and defines the area where the CRC is > calculated. That assumes there is a linker. How does the application access this information? > I am not aware of any linker which support this. > > Two months ago, I added the DIGEST directive to binutils aka the GNU > linker. It was committed, but then people realized that I had not signed > an agreement with Free Software Foundation. > Since part of the code I pushed was from a third party which released > their code under MIT, the licensing has not been resolved yet > but the patch is in binutils git, but reverted. > > You would write (IIRC): > DIGEST "CRC64-ECMA", (from, to) > and the linker would reserve 8 bytes which is filled with the CRC in the > final link stage. You are making a lot of assumptions about the tools. I'm pretty sure they don't apply to my case. I'm not at all clear how this is workable, anyway. Adding the checksum to the file, changes the checksum, which is where this conversation started... unless I'm missing something significant. -- Rick C. +++ Get 1,000 miles of free Supercharging +++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2023-04-27 21:29 +0300 |
| Message-ID | <kavt7iFlvc5U1@mid.individual.net> |
| In reply to | #31859 |
On 2023-04-27 20:09, Rick C wrote:
> On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote:
>> Den 2023-04-20 kl. 04:06, skrev Rick C:
>>> This is a bit of the chicken and egg thing. If you want a embed a checksum in a code module to report the checksum, is there a way of doing this? It's a bit like being your own grandfather, I think.
>>>
>> The proper way to do this is to have a directive in the linker.
>> This reserves space for the CRC and defines the area where the CRC is
>> calculated.
>
> That assumes there is a linker.
Almost all toolchains have a linker.
> How does the application access this information?
In Ulf's suggestion, it seems the DIGEST directive emits 8 bytes of
checksum at the current point (usually the linker "." symbol). I assume
one can give that point in the image a linkage symbol, perhaps like
_checksum DIGEST "CRC64-ECMA", (from, to)
or like
_checksum EQU. .
DIGEST "CRC64-ECMA", (from, to)
(This is schematic linker code, not necessarily proper syntax.)
One can then from the application code access the "checksum" location as
an externally defined object, say:
extern uint8[8] checksum;
The linker will connect that C identifier to the actual address of the
DIGEST checksum. Here I assumed that the C compiler mangles C
identifiers into linkage symbols by prefixing an underscore; YMMV.
> You are making a lot of assumptions about the tools. I'm pretty sure
> they don't apply to my case. I'm not at all clear how this is
> workable, anyway. Adding the checksum to the file, changes the
> checksum, which is where this conversation started... unless I'm
> missing something significant.
But you have insisted that your "checksum" is for the purpose of
identifying the version of the program, not for checking the integrity
of the memory image. If so, that checksum does not have to be the
checksum of the whole memory image, as long as it is the checksum of the
part of the image that contains the actual code and constant data, and
so will change according to changes in those parts of the image.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2023-04-27 21:39 +0300 |
| Message-ID | <kavtrnFlvc5U2@mid.individual.net> |
| In reply to | #31861 |
Um, just noting some typos in my last, with apologies:
On 2023-04-27 21:29, Niklas Holsti wrote:
> _checksum EQU. .
should be
_checksum EQU .
(Thunderbird inserted an extra period out of "friendliness"...)
> extern uint8[8] checksum;
should be (my C is rusty):
extern uint8 checksum[8];
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-04-27 22:44 +0200 |
| Message-ID | <u2emsa$22pgk$2@dont-email.me> |
| In reply to | #31861 |
Den 2023-04-27 kl. 20:29, skrev Niklas Holsti: > On 2023-04-27 20:09, Rick C wrote: >> On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote: >>> Den 2023-04-20 kl. 04:06, skrev Rick C: >>>> This is a bit of the chicken and egg thing. If you want a embed a >>>> checksum in a code module to report the checksum, is there a way of >>>> doing this? It's a bit like being your own grandfather, I think. >>>> >>> The proper way to do this is to have a directive in the linker. >>> This reserves space for the CRC and defines the area where the CRC is >>> calculated. >> >> That assumes there is a linker. > > > Almost all toolchains have a linker. > > >> How does the application access this information? > > > In Ulf's suggestion, it seems the DIGEST directive emits 8 bytes of > checksum at the current point (usually the linker "." symbol). I assume > one can give that point in the image a linkage symbol, perhaps like > > _checksum DIGEST "CRC64-ECMA", (from, to) > > or like > > _checksum EQU. . > DIGEST "CRC64-ECMA", (from, to) > > > (This is schematic linker code, not necessarily proper syntax.) > > One can then from the application code access the "checksum" location as > an externally defined object, say: > > extern uint8[8] checksum; > > The linker will connect that C identifier to the actual address of the > DIGEST checksum. Here I assumed that the C compiler mangles C > identifiers into linkage symbols by prefixing an underscore; YMMV. > Yes, that is more or less it. > >> You are making a lot of assumptions about the tools. I'm pretty sure >> they don't apply to my case. I'm not at all clear how this is >> workable, anyway. Adding the checksum to the file, changes the >> checksum, which is where this conversation started... unless I'm >> missing something significant. No, you reserve room for the checksum, but that needs to be outside the checked area. The address of the checksum needs to be known to the application. Also the limits of the checked area. That is why the application has a header in front in my projects. The application is started by the bootloader, which checks a number of things before the application is started. The application can read the header as well to allow checking the code area at runtime. > > > But you have insisted that your "checksum" is for the purpose of > identifying the version of the program, not for checking the integrity > of the memory image. If so, that checksum does not have to be the > checksum of the whole memory image, as long as it is the checksum of the > part of the image that contains the actual code and constant data, and > so will change according to changes in those parts of the image. > /Ulf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-28 09:38 +0200 |
| Message-ID | <u2ft59$2bnd0$4@dont-email.me> |
| In reply to | #31864 |
On 27/04/2023 22:44, Ulf Samuelsson wrote: > Den 2023-04-27 kl. 20:29, skrev Niklas Holsti: >> On 2023-04-27 20:09, Rick C wrote: > >> >>> You are making a lot of assumptions about the tools. I'm pretty sure >>> they don't apply to my case. I'm not at all clear how this is >>> workable, anyway. Adding the checksum to the file, changes the >>> checksum, which is where this conversation started... unless I'm >>> missing something significant. > No, you reserve room for the checksum, but that needs to be outside > the checked area. > The address of the checksum needs to be known to the application. The address here could have a symbol, and then declared "extern" in the C code - it would not have to be a known numerical address. But if the image is checked or started from another program (such as a boot program), you need an absolute address somewhere to chain this all together. > Also the limits of the checked area. > That is why the application has a header in front in my projects. > The application is started by the bootloader, which checks > a number of things before the application is started. > The application can read the header as well to allow checking > the code area at runtime. > Or for my preferences, the CRC "DIGEST" would be put at the end of the image, rather than near the start. Then the "from, to" range would cover the entire image except for the final CRC. But I'd have a similar directive for the length of the image at a specific area near the start.
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-04-28 10:50 +0200 |
| Message-ID | <u2g1bu$2cdfn$3@dont-email.me> |
| In reply to | #31876 |
Den 2023-04-28 kl. 09:38, skrev David Brown: > On 27/04/2023 22:44, Ulf Samuelsson wrote: >> Den 2023-04-27 kl. 20:29, skrev Niklas Holsti: >>> On 2023-04-27 20:09, Rick C wrote: > >> >>> >>>> You are making a lot of assumptions about the tools. I'm pretty sure >>>> they don't apply to my case. I'm not at all clear how this is >>>> workable, anyway. Adding the checksum to the file, changes the >>>> checksum, which is where this conversation started... unless I'm >>>> missing something significant. >> No, you reserve room for the checksum, but that needs to be outside >> the checked area. >> The address of the checksum needs to be known to the application. > > The address here could have a symbol, and then declared "extern" in the > C code - it would not have to be a known numerical address. But if the > image is checked or started from another program (such as a boot > program), you need an absolute address somewhere to chain this all > together. The header is declared as a struct. > >> Also the limits of the checked area. >> That is why the application has a header in front in my projects. >> The application is started by the bootloader, which checks >> a number of things before the application is started. >> The application can read the header as well to allow checking >> the code area at runtime. >> > > Or for my preferences, the CRC "DIGEST" would be put at the end of the > image, rather than near the start. Then the "from, to" range would > cover the entire image except for the final CRC. But I'd have a similar > directive for the length of the image at a specific area near the start. > I really do not see a benefit of splitting the meta information about the image to two separate locations. The bootloader uses the struct for all checks. It is a much simpler implementation once the tools support it. You might find it easier to write a tool which adds the CRC at the end, but that is a different issue. Occam's Razor! /Ulf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-28 15:04 +0200 |
| Message-ID | <u2gg9d$2ejus$3@dont-email.me> |
| In reply to | #31881 |
On 28/04/2023 10:50, Ulf Samuelsson wrote: > Den 2023-04-28 kl. 09:38, skrev David Brown: >> On 27/04/2023 22:44, Ulf Samuelsson wrote: >>> Den 2023-04-27 kl. 20:29, skrev Niklas Holsti: >>>> On 2023-04-27 20:09, Rick C wrote: >> >>> >>>> >>>>> You are making a lot of assumptions about the tools. I'm pretty sure >>>>> they don't apply to my case. I'm not at all clear how this is >>>>> workable, anyway. Adding the checksum to the file, changes the >>>>> checksum, which is where this conversation started... unless I'm >>>>> missing something significant. >>> No, you reserve room for the checksum, but that needs to be outside >>> the checked area. >>> The address of the checksum needs to be known to the application. >> >> The address here could have a symbol, and then declared "extern" in >> the C code - it would not have to be a known numerical address. But >> if the image is checked or started from another program (such as a >> boot program), you need an absolute address somewhere to chain this >> all together. > > The header is declared as a struct. > >> >>> Also the limits of the checked area. >>> That is why the application has a header in front in my projects. >>> The application is started by the bootloader, which checks >>> a number of things before the application is started. >>> The application can read the header as well to allow checking >>> the code area at runtime. >>> >> >> Or for my preferences, the CRC "DIGEST" would be put at the end of the >> image, rather than near the start. Then the "from, to" range would >> cover the entire image except for the final CRC. But I'd have a >> similar directive for the length of the image at a specific area near >> the start. >> > > I really do not see a benefit of splitting the meta information about > the image to two separate locations. > > The bootloader uses the struct for all checks. > It is a much simpler implementation once the tools support it. > > You might find it easier to write a tool which adds the CRC at the end, > but that is a different issue. > > Occam's Razor! > There are different needs for different projects - and more than one way to handle them. I find adding a CRC at the end of the image works best for me, but I have no problem appreciating that other people have different solutions.
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-04-29 23:03 +0200 |
| Message-ID | <u2k0mp$33teb$2@dont-email.me> |
| In reply to | #31890 |
Den 2023-04-28 kl. 15:04, skrev David Brown: > On 28/04/2023 10:50, Ulf Samuelsson wrote: >> Den 2023-04-28 kl. 09:38, skrev David Brown: >>> On 27/04/2023 22:44, Ulf Samuelsson wrote: >>>> Den 2023-04-27 kl. 20:29, skrev Niklas Holsti: >>>>> On 2023-04-27 20:09, Rick C wrote: >>> >>>> >>>>> >>>>>> You are making a lot of assumptions about the tools. I'm pretty sure >>>>>> they don't apply to my case. I'm not at all clear how this is >>>>>> workable, anyway. Adding the checksum to the file, changes the >>>>>> checksum, which is where this conversation started... unless I'm >>>>>> missing something significant. >>>> No, you reserve room for the checksum, but that needs to be outside >>>> the checked area. >>>> The address of the checksum needs to be known to the application. >>> >>> The address here could have a symbol, and then declared "extern" in >>> the C code - it would not have to be a known numerical address. But >>> if the image is checked or started from another program (such as a >>> boot program), you need an absolute address somewhere to chain this >>> all together. >> >> The header is declared as a struct. >> >>> >>>> Also the limits of the checked area. >>>> That is why the application has a header in front in my projects. >>>> The application is started by the bootloader, which checks >>>> a number of things before the application is started. >>>> The application can read the header as well to allow checking >>>> the code area at runtime. >>>> >>> >>> Or for my preferences, the CRC "DIGEST" would be put at the end of >>> the image, rather than near the start. Then the "from, to" range >>> would cover the entire image except for the final CRC. But I'd have >>> a similar directive for the length of the image at a specific area >>> near the start. >>> >> >> I really do not see a benefit of splitting the meta information about >> the image to two separate locations. >> >> The bootloader uses the struct for all checks. >> It is a much simpler implementation once the tools support it. >> >> You might find it easier to write a tool which adds the CRC at the >> end, but that is a different issue. >> >> Occam's Razor! >> > > There are different needs for different projects - and more than one way > to handle them. I find adding a CRC at the end of the image works best > for me, but I have no problem appreciating that other people have > different solutions. > > > > I'd be curious to know WHY it works best for you. /Ulf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-30 16:19 +0200 |
| Message-ID | <u2ltdt$3i28u$1@dont-email.me> |
| In reply to | #31898 |
On 29/04/2023 23:03, Ulf Samuelsson wrote:
> Den 2023-04-28 kl. 15:04, skrev David Brown:
>> On 28/04/2023 10:50, Ulf Samuelsson wrote:
>>> Den 2023-04-28 kl. 09:38, skrev David Brown:
>>>>
>>>> Or for my preferences, the CRC "DIGEST" would be put at the end of
>>>> the image, rather than near the start. Then the "from, to" range
>>>> would cover the entire image except for the final CRC. But I'd have
>>>> a similar directive for the length of the image at a specific area
>>>> near the start.
>>>>
>>>
>>> I really do not see a benefit of splitting the meta information about
>>> the image to two separate locations.
>>>
>>> The bootloader uses the struct for all checks.
>>> It is a much simpler implementation once the tools support it.
>>>
>>> You might find it easier to write a tool which adds the CRC at the
>>> end, but that is a different issue.
>>>
>>> Occam's Razor!
>>>
>>
>> There are different needs for different projects - and more than one
>> way to handle them. I find adding a CRC at the end of the image works
>> best for me, but I have no problem appreciating that other people have
>> different solutions.
>>
>>
>>
>>
> I'd be curious to know WHY it works best for you.
> /Ulf
I regularly do not have a bootloader - I am not free to put a CRC at the
start of the image. And if the bootloader itself needs to be updatable,
it is again impossible to have the CRC (or any other metadata) at the
start of the image. I want most of the metadata to be at a fixed
location as close to the start as reasonably practical (such as after
the vector table, or other microcontroller-specific information that
might be used for flash security, early chip setup, etc.). If I am to
have one single checksum for the image, which is what I prefer, then it
has to be at the end of the image. For example, there might be :
0x00000000 : vectors
0x00000400 : external flash configuration block
0x00000600 : program info metadata
0x00001000 : main program
: CRC
There is no way to have the metadata or CRC at the start of the image,
so the CRC goes at the end.
It would be possible to have two CRCs - one that covers the vectors,
configuration information, and metadata and is placed second last in the
metadata block. A second CRC placed last in the metadata block would
cover the main program - everything after the CRCs. That would let me
have a single metadata block and no CRC at the end of the image.
However, it would mean splitting the check in two, rather than one check
for the whole image. I don't see that as a benefit.
When making images that are started from a bootloader, I certainly
/could/ put the CRC at the start. But I see no particular reason to do
so - it makes a lot more sense to keep a similar format.
(Bootloaders don't often have to check their own CRC - after all, even
if the CRC fails there is usually little you can do about it, except
charge on and hope for the best. But if the bootloader is updatable in
system, then you want a CRC during the download procedure to check that
you have got a good download copy before updating the flash.)
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-05-09 20:34 +0200 |
| Message-ID | <u3e3oa$bcui$1@dont-email.me> |
| In reply to | #31900 |
Den 2023-04-30 kl. 16:19, skrev David Brown: > On 29/04/2023 23:03, Ulf Samuelsson wrote: >> Den 2023-04-28 kl. 15:04, skrev David Brown: >>> On 28/04/2023 10:50, Ulf Samuelsson wrote: >>>> Den 2023-04-28 kl. 09:38, skrev David Brown: > >>>>> >>>>> Or for my preferences, the CRC "DIGEST" would be put at the end of >>>>> the image, rather than near the start. Then the "from, to" range >>>>> would cover the entire image except for the final CRC. But I'd >>>>> have a similar directive for the length of the image at a specific >>>>> area near the start. >>>>> >>>> >>>> I really do not see a benefit of splitting the meta information >>>> about the image to two separate locations. >>>> >>>> The bootloader uses the struct for all checks. >>>> It is a much simpler implementation once the tools support it. >>>> >>>> You might find it easier to write a tool which adds the CRC at the >>>> end, but that is a different issue. >>>> >>>> Occam's Razor! >>>> >>> >>> There are different needs for different projects - and more than one >>> way to handle them. I find adding a CRC at the end of the image >>> works best for me, but I have no problem appreciating that other >>> people have different solutions. >>> >>> >>> >>> >> I'd be curious to know WHY it works best for you. >> /Ulf > > I regularly do not have a bootloader - I am not free to put a CRC at the > start of the image. And if the bootloader itself needs to be updatable, > it is again impossible to have the CRC (or any other metadata) at the > start of the image. I want most of the metadata to be at a fixed > location as close to the start as reasonably practical (such as after > the vector table, or other microcontroller-specific information that > might be used for flash security, early chip setup, etc.). If I am to > have one single checksum for the image, which is what I prefer, then it > has to be at the end of the image. For example, there might be : > > 0x00000000 : vectors > 0x00000400 : external flash configuration block > 0x00000600 : program info metadata > 0x00001000 : main program > : CRC > > There is no way to have the metadata or CRC at the start of the image, > so the CRC goes at the end. For the Bootloader, I keep the CRC right after the vectors. I keep a copy of the vectors right after the CRC, and compare the two vector tables. This is to always know the location of the CRC. > > It would be possible to have two CRCs - one that covers the vectors, > configuration information, and metadata and is placed second last in the > metadata block. A second CRC placed last in the metadata block would > cover the main program - everything after the CRCs. That would let me > have a single metadata block and no CRC at the end of the image. > However, it would mean splitting the check in two, rather than one check > for the whole image. I don't see that as a benefit. > > > When making images that are started from a bootloader, I certainly > /could/ put the CRC at the start. But I see no particular reason to do > so - it makes a lot more sense to keep a similar format. > You want more metadata like entry point and length, as well as text information about the image. Putting things in a header means that location is fixed. There are a number of checks in my bootloader to ensure that the information in the header makes sense. > (Bootloaders don't often have to check their own CRC - after all, even > if the CRC fails there is usually little you can do about it, except > charge on and hope for the best. But if the bootloader is updatable in > system, then you want a CRC during the download procedure to check that > you have got a good download copy before updating the flash.) In functional safety applications you regularily check the flash contents and refuse to boot if there is a mismatch. /Ulf > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-05-10 10:18 +0200 |
| Message-ID | <u3fk1c$kgrt$1@dont-email.me> |
| In reply to | #31935 |
On 09/05/2023 20:34, Ulf Samuelsson wrote: > Den 2023-04-30 kl. 16:19, skrev David Brown: >> On 29/04/2023 23:03, Ulf Samuelsson wrote: >>> Den 2023-04-28 kl. 15:04, skrev David Brown: >>>> On 28/04/2023 10:50, Ulf Samuelsson wrote: >>>>> Den 2023-04-28 kl. 09:38, skrev David Brown: >> >>>>>> >>>>>> Or for my preferences, the CRC "DIGEST" would be put at the end of >>>>>> the image, rather than near the start. Then the "from, to" range >>>>>> would cover the entire image except for the final CRC. But I'd >>>>>> have a similar directive for the length of the image at a specific >>>>>> area near the start. >>>>>> >>>>> >>>>> I really do not see a benefit of splitting the meta information >>>>> about the image to two separate locations. >>>>> >>>>> The bootloader uses the struct for all checks. >>>>> It is a much simpler implementation once the tools support it. >>>>> >>>>> You might find it easier to write a tool which adds the CRC at the >>>>> end, but that is a different issue. >>>>> >>>>> Occam's Razor! >>>>> >>>> >>>> There are different needs for different projects - and more than one >>>> way to handle them. I find adding a CRC at the end of the image >>>> works best for me, but I have no problem appreciating that other >>>> people have different solutions. >>>> >>>> >>>> >>>> >>> I'd be curious to know WHY it works best for you. >>> /Ulf >> >> I regularly do not have a bootloader - I am not free to put a CRC at >> the start of the image. And if the bootloader itself needs to be >> updatable, it is again impossible to have the CRC (or any other >> metadata) at the start of the image. I want most of the metadata to >> be at a fixed location as close to the start as reasonably practical >> (such as after the vector table, or other microcontroller-specific >> information that might be used for flash security, early chip setup, >> etc.). If I am to have one single checksum for the image, which is >> what I prefer, then it has to be at the end of the image. For >> example, there might be : >> >> 0x00000000 : vectors >> 0x00000400 : external flash configuration block >> 0x00000600 : program info metadata >> 0x00001000 : main program >> : CRC >> >> There is no way to have the metadata or CRC at the start of the image, >> so the CRC goes at the end. > > For the Bootloader, I keep the CRC right after the vectors. > I keep a copy of the vectors right after the CRC, and compare > the two vector tables. > This is to always know the location of the CRC. Fair enough - that is an entirely reasonable alternative. I have a knee-jerk reaction against duplication as a check, having cut my teeth on microcontrollers where 16 KB devices were "big", but of course a duplication of the vector table is not going to be a noticeable waste on a more modern device. It does, however, mean extra steps in checking, compared to a simpler CRC run over the entire image. > >> >> It would be possible to have two CRCs - one that covers the vectors, >> configuration information, and metadata and is placed second last in >> the metadata block. A second CRC placed last in the metadata block >> would cover the main program - everything after the CRCs. That would >> let me have a single metadata block and no CRC at the end of the >> image. However, it would mean splitting the check in two, rather than >> one check for the whole image. I don't see that as a benefit. >> >> >> When making images that are started from a bootloader, I certainly >> /could/ put the CRC at the start. But I see no particular reason to >> do so - it makes a lot more sense to keep a similar format. >> > You want more metadata like entry point and length, as well as text > information about the image. Putting things in a header means that > location is fixed. > There are a number of checks in my bootloader to ensure that the > information in the header makes sense. > I do have all that kind of thing too. It's only the CRC itself that is put at the end, and it is easily found since the length of the image is in the metadata. (We are talking about one pointer access more than having it at a fixed address - it's not hard to find it!). >> (Bootloaders don't often have to check their own CRC - after all, even >> if the CRC fails there is usually little you can do about it, except >> charge on and hope for the best. But if the bootloader is updatable >> in system, then you want a CRC during the download procedure to check >> that you have got a good download copy before updating the flash.) > > In functional safety applications you regularily check the flash > contents and refuse to boot if there is a mismatch. > Yes, that is a possibility. I've worked on safety-certified systems which required things like regular checks of flash while running (not just at bootup). A lot of the so-called "safety requirements" were directly detrimental. I believe many of these kinds of requirements were made by people who understood the "Swiss cheese" model of risks and safety, but not the more realistic "Hot cheese" model. And they seem more concerned about box-ticking and legal arse-covering than actual risk reduction.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-28 09:33 +0200 |
| Message-ID | <u2fsst$2bnd0$3@dont-email.me> |
| In reply to | #31861 |
On 27/04/2023 20:29, Niklas Holsti wrote: > On 2023-04-27 20:09, Rick C wrote: >> On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote: >>> Den 2023-04-20 kl. 04:06, skrev Rick C: >>>> This is a bit of the chicken and egg thing. If you want a embed a >>>> checksum in a code module to report the checksum, is there a way of >>>> doing this? It's a bit like being your own grandfather, I think. >>>> >>> The proper way to do this is to have a directive in the linker. >>> This reserves space for the CRC and defines the area where the CRC is >>> calculated. >> >> That assumes there is a linker. > > > Almost all toolchains have a linker. > It is possible that Rick is using Forth, rather than C (or other languages traditionally compiled in a similar manner, such as C++ and Ada). There are also some commercial C toolchains for brain-dead 8-bit CISC devices that are monolithic and offer very little control over the linking. Ulf is correct that the ideal place to handle this is part of the linking process. I do it with a post-link Python script run during the build, because the linkers I use can't handle this at the moment. But if Ulf's patch works its way into binutils then I'll be able to do it directly during linking, which is neater. (I will still have post-link scripts to handle things like renaming image files according to version, making zips for sending to customers, etc. - linkers can't do /everything/ !)
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-04-27 22:36 +0200 |
| Message-ID | <u2emd2$22pgk$1@dont-email.me> |
| In reply to | #31859 |
Den 2023-04-27 kl. 19:09, skrev Rick C:
> On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote:
>> Den 2023-04-20 kl. 04:06, skrev Rick C:
>>> This is a bit of the chicken and egg thing. If you want a embed a checksum in a code module to report the checksum, is there a way of doing this? It's a bit like being your own grandfather, I think.
>>>
>> The proper way to do this is to have a directive in the linker.
>> This reserves space for the CRC and defines the area where the CRC is
>> calculated.
>
> That assumes there is a linker. How does the application access this information?
>
>
Linker command file
public CRC64; start, stop
HEADER = .;
QUAD(MAGIC);
CRC64 = .;
DIGEST "CRC64-ECMA", (start, stop)
start = .;
# Your data to be protected
...
stop = .;
C source code.
extern uint64_t CRC64;
extern char* start;
extern char* stop;
uint64_t crc;
crc64 = calc_crc64_ecma(start, stop);
if (crc64 == CRC64) {
/* everything is OK */
}
>> I am not aware of any linker which support this.
>>
>> Two months ago, I added the DIGEST directive to binutils aka the GNU
>> linker. It was committed, but then people realized that I had not signed
>> an agreement with Free Software Foundation.
>> Since part of the code I pushed was from a third party which released
>> their code under MIT, the licensing has not been resolved yet
>> but the patch is in binutils git, but reverted.
>>
>> You would write (IIRC):
>> DIGEST "CRC64-ECMA", (from, to)
>> and the linker would reserve 8 bytes which is filled with the CRC in the
>> final link stage.
>
> You are making a lot of assumptions about the tools. I'm pretty sure they don't apply to my case. I'm not at all clear how this is workable, anyway. Adding the checksum to the file, changes the checksum, which is where this conversation started... unless I'm missing something significant.
>
I am assuming that no tool support this off the shelg, but the patches
are inside binutils, but reverted.
/Ulf
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2023-04-28 01:10 +0300 |
| Message-ID | <kb0a5rFlvc6U1@mid.individual.net> |
| In reply to | #31863 |
On 2023-04-27 23:36, Ulf Samuelsson wrote:
> Den 2023-04-27 kl. 19:09, skrev Rick C:
>> On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote:
>>> Den 2023-04-20 kl. 04:06, skrev Rick C:
>>>> This is a bit of the chicken and egg thing. If you want a embed a
>>>> checksum in a code module to report the checksum, is there a way of
>>>> doing this? It's a bit like being your own grandfather, I think.
>>>>
>>> The proper way to do this is to have a directive in the linker.
>>> This reserves space for the CRC and defines the area where the CRC is
>>> calculated.
>>
>> That assumes there is a linker. How does the application access this
>> information?
>>
>>
> Linker command file
> public CRC64; start, stop
> HEADER = .;
> QUAD(MAGIC);
> CRC64 = .;
> DIGEST "CRC64-ECMA", (start, stop)
> start = .;
> # Your data to be protected
> ...
> stop = .;
>
> C source code.
>
> extern uint64_t CRC64;
> extern char* start;
> extern char* stop;
>
> uint64_t crc;
>
> crc64 = calc_crc64_ecma(start, stop);
> if (crc64 == CRC64) {
> /* everything is OK */
> }
I'm nit-picking, but that C code does not look right to me. The extern
declarations for "start" and "stop" claim them to be names of memory
locations that contain addresses, but the linker file just places them
at the starting and one-past-end locations of the block to be protected.
So the "start" variable contains the first bytes of the "data to be
protected", and the contents of the "stop" variable are not defined
because it is placed after the "data to be protected", where no code or
data is loaded (it seems).
It seems to me that the call to calc_crc64_ecma should get the addresses
of "start" and "stop" as arguments (&start, &stop), instead of their
values. But perhaps calc_crc64_ecma is not a function, but a macro that
can itself take the addresses of its parameters.
[toc] | [prev] | [next] | [standalone]
| From | Ulf Samuelsson <ulf.r.samuelsson@gmail.com> |
|---|---|
| Date | 2023-04-28 10:54 +0200 |
| Message-ID | <u2g1jk$2cdfn$4@dont-email.me> |
| In reply to | #31867 |
Den 2023-04-28 kl. 00:10, skrev Niklas Holsti:
> On 2023-04-27 23:36, Ulf Samuelsson wrote:
>> Den 2023-04-27 kl. 19:09, skrev Rick C:
>>> On Thursday, April 27, 2023 at 12:26:47 PM UTC-4, Ulf Samuelsson wrote:
>>>> Den 2023-04-20 kl. 04:06, skrev Rick C:
>>>>> This is a bit of the chicken and egg thing. If you want a embed a
>>>>> checksum in a code module to report the checksum, is there a way of
>>>>> doing this? It's a bit like being your own grandfather, I think.
>>>>>
>>>> The proper way to do this is to have a directive in the linker.
>>>> This reserves space for the CRC and defines the area where the CRC is
>>>> calculated.
>>>
>>> That assumes there is a linker. How does the application access this
>>> information?
>>>
>>>
>> Linker command file
>> public CRC64; start, stop
>> HEADER = .;
>> QUAD(MAGIC);
>> CRC64 = .;
>> DIGEST "CRC64-ECMA", (start, stop)
>> start = .;
>> # Your data to be protected
>> ...
>> stop = .;
>>
>> C source code.
>>
>> extern uint64_t CRC64;
>> extern char* start;
>> extern char* stop;
>>
>> uint64_t crc;
>>
>> crc64 = calc_crc64_ecma(start, stop);
>> if (crc64 == CRC64) {
>> /* everything is OK */
>> }
>
>
> I'm nit-picking, but that C code does not look right to me. The extern
> declarations for "start" and "stop" claim them to be names of memory
> locations that contain addresses, but the linker file just places them
> at the starting and one-past-end locations of the block to be protected.
> So the "start" variable contains the first bytes of the "data to be
> protected", and the contents of the "stop" variable are not defined
> because it is placed after the "data to be protected", where no code or
> data is loaded (it seems).
>
> It seems to me that the call to calc_crc64_ecma should get the addresses
> of "start" and "stop" as arguments (&start, &stop), instead of their
> values. But perhaps calc_crc64_ecma is not a function, but a macro that
> can itself take the addresses of its parameters.
>
Whatever,
I did not put a lot of thought into that, and certainly did not check
it. The important thing is that you can declare labels in the linker
and use them in the code through extern declarations.
/Ulf
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web