I am just interested not trying to argue, found this link.
https://wiki.segger.com/Raspberry_Pi_RP2040
The RP2040 includes a boot ROM which needs to be executed after reset in order to guarantee proper functionality. In case of a valid application has been detected in the external QSPI flash, the boot ROM copies the first 256 bytes from QSPI to SRAM5. In the RP2040 user manual, this code is called "flash second stage" (2nd stage bootloader) which is not part of the boot ROM but is part of the application image thus can be adapted by the user. The J-Link performs a device specific reset which halts on the first instruction at address 0x20041F00 of this so called "flash second stage" (bootloader).
The quoted description is correct. The boot ROM loads code from flash: the "second stage" loader. That loader then (usually) configures the RP2040 to execute the actual application directly from flash.
But the "Easter egg" function discussed in this HN thread is not inside any code loaded/executed from flash. It is inside the boot ROM (as I've repeatedly stated); and that is indeed read-only memory, i.e., it cannot be modified except by manufacturing a new chip revision.
Okay. I have an idea. Let’s see what happens if we treat…
06: 00 B5 push {lr}
… as the start of this weird code(?) sequence. It pushes the link register (i.e., the return address to the caller).
08: 42 40 eors r2, r0
0a: 00 2A cmp r2, #0
This XORs R2 and R0 and compares the result against zero. But that’s just a decoy, as we’ll see.
0c: 00 F0 02 F8 bl #0x14
This calls into…
14: 70 46 mov r0, lr
16: 00 47 bx r0
… which moves the return address to R0, and then returns. Using the addresses in this disassembly (not in the actual boot ROM), the return address is 0x10; but LR and, therefore, R0 will actually contain 0x11 because the LSB signifies Thumb mode.
None of the previous three instructions modifies the flags. (I checked in the ARM reference manual.) Thus, “BHS” (branch unsigned higher or same) uses the flags from the “CMP R2,#0” above. _Every_ value of R2 is higher (in the unsigned sense) or same as 0. Hence, the following branch is always taken:
10: F6 D2 bhs #0
… to…
00: 11 38 subs r0, #0x11
R0 contained 0x11 relative to the start of this code sequence. (The absolute address in boot ROM is of course different.) Now, R0 points to the start of the code sequence.
02: C0 7A ldrb r0, [r0, #0xb]
This loads the byte at offset 0xB in this code sequence. Look above, it is 0x2A.
04: 00 BD pop {pc}
This returns to the caller, using the LR pushed at the beginning. The return value in R0 is 0x2A.
0x2A is 42 (decimal)! Could this be an Easter egg; a very obfuscated way of returning 42, the Answer to the Ultimate Question of Life, the Universe, and Everything? (Remember that the Raspberry design team is from Britain, same as Douglas Adams.)
Nice description of the correct intended behavior! It is indeed an Easter Egg; a function that returns the answer to the Ultimate Question of Life, the Universe, and Everything.
After the addition of double-precision floating point support in V2 of the boot ROM (B1 silicon), we had just over 30 bytes spare. Removing any of the slightly obtuse space-saving techniques already used in the code always resulted in code that didn't fit, so we were left with the free space.
Nature abhors a vacuum, so I decided on an Easter Egg (note there is no secure code in the RP2040 boot ROM). It was surprisingly challenging to come up with some very short code which actually did something, but whose purpose was not immediately obvious. I was also super interested to see how long it would take someone to find it - 15 months apparently :-)
Hopefully it provided you some amusement/puzzle value... I sort of hoped it would be more confusing the more ARM assembly you knew, as it potentially sets off all sorts of wrong pattern-matching in the brain.
That might be the case, but I wouldn't use Github search results to confirm this. I have no idea why, as this is super important, but code search in Github is surprisingly terrible. Not sure if this is just me or others have had similar experiences.
Not just you. It can give no results and partial results, which is sometimes fixed on a re-query.
But it also is just poor for code. I think it wants to find full words, so searching for substrings generally results in too few matches. That's made worse by its special character handling in word splitting and query parsing which makes some text impossible to find.
I think you're right. This instruction is essentially redundant, since the following instruction also adds an offset - so I think it's very deliberate.
I do see a point in it working like it does, though. I'm one of the lead developers on a free software project with over 20 years of history. Even though the project has used multiple version control systems (and hosting providers) over time, we have imported our entire project's history going back to the very first commit into git and GitHub.
Not every contributor has kept their email address for over 20 years. Some don't have access to the old addresses they once used for commits. Still they want the commits to be associated with their current GitHub account; even if it's just for statistics and "bragging rights".
If GitHub required email address verification, how would this be done?
EDIT: To be clear: With "working like it does" I'm referring to the possibility to add unverified email addresses to your account and have commits attributed to you.
> Still they want the commits to be associated with their current GitHub account
Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly).
GitHub should just show the e-mail address when it can't associate that to an account, maybe show it's unverified and link to a help page explaining anyone could have faked that in the commit. I don't understand why they care so much to put a face (the GH account) on the commit when the address is not verified.
> Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly).
This case might not be super important in the long run, but why does it have to be a fact of life? If a system doesn't work as its human operators intend, that's a system failure, not a human being failure.
"people can claim the commits without verification." - Well, tough luck? I don't think it's that important. Just accept it as a fact of life. You didn't cryptographically sign your commit and now nobody (including you) can prove who made it.
The distinction is in where the potential harm can be.
With the current status quo (unverified email addresses can "steal" commits), you create confusion in the general developer community. Anyone who looks at those mis-attributed commits will be confused, and possibly misled.
If GH didn't associate commits unless the email address was verified, then, yes, some people wouldn't get "bragging rights", but the harm would be limited to that person. Others who look at those commits would still see the correct person's name, even though it wouldn't be associated with a particular GH account.
> "Others who look at those commits would still see the correct person's name,"
They would see the name which was written into the commit; assuming that's "the correct person" is the same mistake. Associating to the GitHub verified email account is incorrect in the same fashion, but going the other way. They're both only text saying "Linus Torvalds", in the absence of signing, neither is more or less authoritative than the other. Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have.
Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text.
I think the issue is that this isn't a "fact of life", so github could either show the original email or pull in the account with a verified email. What it does now appears to be a bug.
Because we exist in the real world with real constraints. We have only two options, allow people to stick their name on others commits, or have unverified emails just show plainly.
Neither of these is ideal but at least the second one never tells lies.
You could add humans into the verification process. I imagine the number of people who want to associate old emails they don't have access to with accounts to be small. If you could prove that you owned the account via other means it could be manually added to your profile.
Exactly, such as.... by contacting Github support (which they offer as a way to undo the incorrect enhancement on the original commit anyway). I think Github should reverse course on this one.
> If a system doesn't work as its human operators intend, that's a system failure, not a human being failure.
Well, I think we have to consider who was responsible for it not working as its human operators intended (my use of 'who', rather than 'what', in that sentence is not a grammatical error; it is a clue as to the correct answer.)
Unless the outcome described here was one of the explicit goals of the creators of the system, then you cannot assume it was an intended outcome, as opposed to an unintended consequence of what they chose to do. If it was the latter, then "that's what it will do" is not a justification for what it does do; if it was the former, then it was just a bad choice. The only way to justify the situation is if there was no alternative that was not strictly worse, and if so, then it should be made clear that it is so.
I guess they can also say tough luck to you, because they don’t think preventing people from posting old commits that are credited to an unverified email is that important. Just accept that we don’t verify it as a fact of life; you can’t be sure of commit ownership.
Maybe github should use gravatar if the email doesn't match a github account. Not that that helps with old email address you no longer control but it does let you add an image to an arbitrary email you do control, separate from github.
in Github or in Git itself? While possible, I don't believe there's many floating commits around.
The other issue of course is that at this point in time, there would not be a .mailmap. Of course, github can then fall back to a .mailmap file in the latest commit of the main branch.
If somebody clones the repo they can even rewrite history. But that is not the same as them being able to claim the ownership of a commit in the original repo.
GitHub bases the association of commits to user accounts on the list of e-mail addresses configured in the user’s profile: https://github.com/settings/emails
> I do see a point in it working like it does, though
really? I'd think a product whose _primary_ value proposition is "integrity and assurance over what was committed when by who" this is such an odd edge case github refuses to fix. If their security team isn't looking at this and thinking "oh my these aren't the secure-by-design defaults we should have", fire them.
To say "oh but you ought to use cryptographic keys to allow attribution", then why not a color code, or a subtle warning, whatever ... to hint at the fact that attribution in this case isn't only weak but totally impossibly (instead of pointing to a user-id that is 100% wrong and saying "yupp, that's the one who we believe did the commit").
Not exactly great UE. Also terrible for supply chain security. The whole thing is hard to explain because it wasn't that UE was chosen over security. There is no logic to why it was half-arsed like this and they actually get away with it all while grand-standing about all the things they do for "security".
All Github-security brings to the world (other than hype) is:
- Cockpit: which allows me to produce security vulns in an automated manner, and
- the GHSA vulnerability severity scoring which essentially labels anything that has CVSS3 critical as moderate and allows downplaying of the real score.
As a Microsoft company perhaps this is just what it is and I'm to blame for expecting things to make sense.
> Still they want the commits to be associated with their current GitHub account; even if it's just for statistics and "bragging rights".
> If GitHub required email address verification, how would this be done?
If it can't be done securely - e.g. you verify you own the e-mail address - it shouldn't be done, IMO. It's like losing your 2FA token and all recovery methods; for the sake of security, you should consider that account lost. Because if you can get it back through other means, then a scammer / impostor can do so as well.
At some point you just have to give up. Anyway in the case of e-mail addresses, ideally you have your real name in the address itself for anything formal / work related.
Alternatively, what GitHub could do is mark these accounts as unverified. It would also mean they should allow multiple user accounts to be associated with a commit's e-mail address though.
And finally, some manual work might be involved. I'm sure there would be ways and means to get verified on github (like on twitter), and somehow claim that e-mail address in a more formalized fashion - and to dispute it. In the case of Linux and Go, it's obvious and well-known who the original authors / committers are, so a bit of manual work to associate those commits to a GH account shouldn't be too much of an issue.
One idea: just show the statistics of unverified commits, demarcated as such, in the user’s profile. This is a more transparent variation on the current behavior.
Doesn't changing the author affect the commit sha? If so, doing this would cause some amount of pain with syncing all copies of the repo, branches, etc, making it a non-starter I think.
that's great but it requires an active step on behalf of the user which is violating secure defaults principle. it also violates the principle of good UE
Thank you, wanted to know, if so, this should really be noted when suggesting these sort of things since it has unaccounted consequences especially when you consider most people use git but don't necessarily know how to use it beyond the basics.
Hm, the article makes it sound as if mmWave radars are a fairly new addition to cars. But 77 GHz radar sensors have been in cars since over a decade now, thanks to suppliers such as Bosch and Continental.
If your question was for a machine to run Atari System V Unix on, though, I'm afraid the answer is: an Atari TT. None of the m68k machines (or FPGA emulations thereof) mentioned in the other comments will run it.
Perhaps (but I didn't test) Atari System V Unix would run under the Hatari emulator.
That's not as much fun. It's like installing Linux on a SPARCstation, an SGI, or an IBM RS/6000. It's possible, but just not as much as exploring the uniqueness of those machines.
Yeah, NetBSD is the same everywhere. Partition, configure, set the network, pkgin, pkgsrc, repeat. CTWM today will run fastly enough on almost any X supported arch. It's really useful, and because of that, it's boring :).
With OpenBSD the same, too. Except for some webkit browser, a DE with CWM and XTerm plus ksh's will not differ at all from a PC with the same config.
In all fairness it needs to be said that the libc's implementation has to consider portability to more "exotic" architectures. For example, not every CPU allows to make unaligned 32-bit or 64-bit writes, or it takes a huge penalty for such writes.
Can't look right now, but you might not have benchmarked against libc, but against an optimized version included in Raspbian (https://github.com/simonjhall/copies-and-fills). I'm not sure if that's still active in the latest Raspberry Pi OS releases.
Is that 32 bit ARM code on 64 bit kernel? I thought ARM (since v6) allows unaligned access, although it might have to be emulated through the kernel which is going to be super-slow.
