The purpose of this bootloader is to avoid executing malicious code sent over the internet, such as by a MITM attack.
The author explains that it does not attempt to defend against hardware attacks or attempts to replace the bootloader:
> SentinelBoot's threat model focuses on thin client devices which do not store their own OS and over-the-air updates (e.g. how phones are updated): both of these cases involve executable code being sent over a network, usually the internet. We ignore the risk of direct hardware modification, as an attacker can just swap out the bootloader (making any potential defence implemented by SentinelBoot in vain).
This is a very specific type of bootloader for devices that get their code over the internet:
> SentinelBoot's threat model focuses on thin client devices which do not store their own OS and over-the-air updates (e.g. how phones are updated): both of these cases involve executable code being sent over a network, usually the internet. We ignore the risk of direct hardware modification, as an attacker can just swap out the bootloader (making any potential defence implemented by SentinelBoot in vain).
The author readily acknowledges that it does not defend against hardware modification. The other comments here trying to vilify this project don't understand what it is supposed to do.
> Have I been living in a fantasy bubble where CPU's do exactly what you asked of them (and errors come from not holding it right)?
These are gaming CPUs clocked right up to the threshold of stability (and in some cases, past it)
Server CPUs with ECC RAM are significantly better.
However, if you haven’t experienced much CPU instability, you may not have operated at scale where it appears. Get into the scale where operations occur across 100,000s of CPUs and weird things happen constantly.
One of the previous discussions of this instability noted that it was happening to the server equivalents (which are after all the same die) at stock settings as well.
I feel like the entire fiasco has been multiple issues being lumped together as one, and muddied to the point that even a bluescreen out of an attempt to run XMP at extremely high MT/s are now being claimed as degradation. From what I can make out of this mud, there seems to be (1) a failure caused by high current due to some boards unlocking IccMax/PL1/PL2 by default, and (2) high voltage during a single-core boost (TVB). The former is caused by overclocking, and the latter seems to be Intel's failure to validate the CPUs at low load/long period of single-core boost, where IccMax/PL no longer matters as much (since single-core boost never exceeds PL1 anyway).
Most Raptor Lake "server boards" right now are W680 with client CPUs because the C266/Xeon E-2400 took a long time to come out. The one intended for workstations typically has overclockable settings or is even overclocked by default, which means it's likely to get hit with the failure (1). The one intended for servers do have more conservative settings, but can still be hit with failure (2) under some conditions.
Buildzoid released a video on the Supermicro W680 blade a bit ago that were having issues after running a single-core load 24x7, which is essentially 24x7 boost[1] (aka issue (2)). Xeon E-2400 _could_ be affected in this scenario, although even the highest clock E-2400 SKU (E-2488) is only running at 5.6GHz without Thermal Velocity Boost, and most others are ranging from 4.5 to 5.2 GHz boost (rather than the 5.8 to 6 GHz boost some client SKUs do). I feel like the actual B0 Xeon E-2400 would be a lot less prone to both failures (1) and (2) due to this (but it could happen, though there's no reports of such).
But then the conversation gets muddied enough that "even servers and Xeons are affected" becomes the common narrative (while the former is true, the circumstances needs to be noted; and for Xeons, it's a _maybe_ at most, since right now there's no report of Xeon E-2400 failing).
Looking around, I'm seeing reports of 1.4-1.5V core voltages using Intel's stock profiles, with some even going to 1.7V. That's insanely high for a 10nm process and I'm not surprised about the degradation. For comparison, in the 45/32nm days 1.2-1.3V was the norm, with some extreme overclockers (who don't expect CPUs to survive for more than a few minutes, using liquid nitrogen etc.) hitting ~1.5V, and 1.4V was a commonly quoted safe upper limit for 24x7 operation.
I remember hearing that server motherboards also played a role in overclocking out of the box, which is frankly fucking stupid. I don't recall anything about Raptor Lake-based Xeons suffering from degradation.
Unless they disable Turbo Boost (which is horrible for performance, but great if you want benchmark consistency), the CPU will automatically overclock until it reaches the limits, adjusting both voltage and frequency.
All the evidence I've seen points to electromigration as a cause of this degradation, and IMHO excessively aggressive automatic overvolting by Intel's microcode is to blame.
There is actually a simple experiment which can determine whether that is true --- remove the fan from the heatsink, or even let the CPU run without a heatsink. As the CPU will automatically throttle once it reaches its designed maximum temperature (and AFAIK that is a hardcoded limit), it will lower its frequency and voltage to maintain that temperature. If this results in a stable CPU, while the one that has great cooling becomes more unstable, it confirms the hypothesis.
There are numerous stories of machines where the heatsink was not in contact with the CPU for some reason, yet they remained perfectly stable (but slow) for many years. I can also say that I've had an 8th-gen i7 running at 100% 24x7 with all power and turbo limits disabled, with its temperature constantly at the design limit of 100C, and it has also remained stable for over 5 years.
> There are numerous stories of machines where the heatsink was not in contact with the CPU for some reason, yet they remained perfectly stable (but slow) for many years.
I once had a laptop, which came from the factory with the four screws which hold the heatsink to the CPU missing. It was very slow, and shut down after a few minutes (the reason being thermal shutdown in the BIOS event log helped diagnose the issue). After the four screws were replaced (each screw came in its own large individual cardboard box), it worked fine for many years, BUT after a couple of years (still under warranty), the motherboard failed with a short in the power input. I suspect that all the extra heat from when the CPU was without a working heatsink went to the power supply components through the motherboard ground plane, and cooked them, significantly shortening their useful life.
That's a lot of cpu time. Maybe they just don't make them like they
used to. If there's some crazy complicated numerical or combinatorial
problem you've been trying to crack, do tell.
>Unless they disable Turbo Boost (which is horrible for performance, but great if you want benchmark consistency), the CPU will automatically overclock until it reaches the limits, adjusting both voltage and frequency.
Turbo Boost (and Thermal Velocity Boost if applicable) frequencies are according to specifications, it's not an overclock.
That's part of it, but intestinal parasites also interfere with normal digestive processes. Their presence and secretions (waste products and the compounds they use to prevent being digested) can cause a lot of problems. It's common for people with intestinal parasites to have reduced appetite, intestinal inflammation, and digestion issues.
The weight loss isn't just a result of the parasite competing for nutrients, though that doesn't help.
> You can almost never get through those thick-skulled reps that email you out of the blue...
He did get through to the sales rep. The responses are directly in the article. The sales rep responded within hours and showed him how to sign up for the free trial option to extend the free usage period longer while he decided.
> He did get through to the sales rep. The responses are directly in the article. The sales rep responded within hours and showed him how to sign up for the free trial option to extend the free usage period longer while he decided.
> What more would you want the rep to do?
Not send a threatening, inaccurate email with a 4-day (1 business day Friday->Monday) deadline in the first place?
Also for the record, this was not a sales manager. This was someone in "growth" that sent the email. I guess maybe that just means "sales."
> Your API usage is higher than lots of other Yelp Fusion developers
You're right it wasn't just inaccurate it was outright deceptive, trying to frame this as something specific to OP that he is responsible for rather than a change in their business applying to all API users.
Employ a shred of critical thinking and realize this app probably drives more value to Yelp than the cost to run the API, and flag it for an exception.
Customer service or sales people like that are usually at the lowest point on the totem pole. It’s likely that they have zero leeway, either you’re gonna pay exorbitantly or you’re out. It’s an institutional problem.
In that case it's not customer service but a customer firewall. If the CS employees are not empowered to induce solutions even if they benefit both the customers and the company then they are literally useless.
And yes, many companies have "customer service" like that designed to waste your time until you go away. That doesn't mean it's the only possible way.
> which is to point out the overt hostility to and powerlessness of API users. That should be concerning to anyone working on projects that use APIs, which is, um... almost everyone, these days.
Not everyone. Business that build on top of other company's APIs will arrange contracts with their API providers. Those contracts generally include warning periods for changes or discontinuation and penalties for early termination.
The key here is that it was a free API with no contract or guarantees. Four days is short notice and frustrating, but it wouldn't have really changed the trajectory of his business if they had given him 180 days. If he didn't intend to pay for the API, he couldn't really sell an app that was going to stop working in a few months.
So I know we're supposed to be angry about the 4 days thing. It's not good, obviously. However, I don't think it actually changes the situation at all if he wasn't going to sign up anyway.
> So I know we're supposed to be angry about the 4 days thing. It's not good, obviously. However, I don't think it actually changes the situation at all if he wasn't going to sign up anyway.
As I said in the post and comments here if it made financial sense and they gave me a more reasonable deadline with a less threatening email I would be willing to pay for the API. In this case it didn't make financial sense, so you're right at the current API prices it wouldn't make sense even with 6 months-notice.
That said, 6-months (your suggested time period) is a much better grace period for our shared users (users of Restaurants who use it as a frontend and continue to read more reviews at Yelp.com) and much more likely to make me convert to a paid API customer if it had made financial sense.
> and much more likely to make me convert to a paid API customer if it had made financial sense
I don't understand. Are you saying that even if it did make financial sense, you would have voluntarily shut the app down in protest of the 4-day notice period? Even though the sales rep pointed you toward the free trial option to continue using the API beyond the 4 days while you decided?
I know you're angry and want us all to be angry at Yelp too, but I have a difficult time believing that anyone would choose to destroy a profitable application out of protest just to stick it to the company about a short notice period.
> I don't understand. Are you saying that even if it did make financial sense, you would have voluntarily shut the app down in protest of the 4-day notice period? Even though the sales rep pointed you toward the free trial option to continue using the API beyond the 4 days while you decided?
An app that sold 467 copies over 10 years at less than $5 a copy is not worth the trouble of dealing with a company that gives you Friday->Monday ultimatums. Obviously, if it were a big source of my income I would have to seriously consider it. But luckily, it's not. I discussed this in the "Development Ends" section of the post. Here is the pricing deck they sent me:
https://drive.google.com/file/d/1Cb_8laDpxZdfwJPtYBmibZgvLZ8...
It seems to indicate a $229 base monthly price on the third slide for my use case.
> I know you're angry and want us all to be angry at Yelp too, but I have a difficult time believing that anyone would choose to destroy a profitable application out of protest just to stick it to the company.
I'm sorry you're reading so much anger in my post. I thought my blog post was pretty balanced. The worst I called them is "quite rude" (I think it's hard to read their emails otherwise) and spent the first half of it describing my app. I never expressed much emotion in my post, and frankly as mentioned above it really doesn't matter in the scheme of things for my life. What I do want is Yelp to change the way it treats developers. Perhaps if someone there reads this it will cause a tiny reflection on their part. I also hope the experience here expressed in the "Lessons Learned" section of the post is useful to other indie developers.
Both your neutral tone and the fact that you want Yelp and other big companies to treat developers better were very clear!
That's what's crazy to me about all these comments. What does it say that so many developers have glossed over this simple ask for more considerate and respectful treatment for THEMSELVES? What does it say that the knee jerk response is fatalism to whatever big tech does?
Thank you. It's actually just a couple users who have posted multiple negative comments in this thread like gp. Not sure what nerve my blog post hit with them but they are free to not like it! It seems like they're more upset about my blog post than I am about the actual situation.
>> I don't think it actually changes the situation at all if he wasn't going to sign up anyway.
This is kind of the salient point.
Either you test on the free API and plan on paying for access slightly before its ready to go live, or you try the "free lunch" approach and see if you can get one by the tendy and see how long you can go before you get shut down and have to pony up the money.
Either way. they should've had the cost of the API in their budget.
We should all know by now. . . . nobody rides for free.
> Either way. they should've had the cost of the API in their budget.
There was no cost to the API ten years ago. I submitted a prototype of my app to their developer program, described its functionality and exchanged a few emails back and forth with someone in developer relations. They specifically approved it and decided how many API calls to give me. A paid API didn't exist back then to my knowledge (perhaps there was some kind of enterprise API but I don't know?). The point of the post is how badly Yelp handled the transition from free to paid. They are perfectly in their right to transition to paid. But they should've handled the emails and transition better.
As mentioned in the post I developed the app on a whim. But after 10 years, it had a few users, although not many. They and I should have received more than a few days notice from Yelp that the API was going to become unsustainable (see my comments elsewhere in this thread).
It sounds like he requested API access in order to make a native Mac application for Yelp. The specifics matter a lot here, but “if you develop a native Mac application for Yelp, we’ll give you free API access” sounds a lot like consideration. That could be completely false based on exactly how that went down, of course.
> Developing an app to use someone's free API is not an exchange of consideration.
I would never pursue anything further over this app that had about $2,000 of revenue over 10 years. That said, for the record there was consideration.
I had to go through an official approval process that required providing evidence of the app's functionality and a few emails back and forth. I think I actually sent them a prototype of it. And based on that process they decided how many daily API calls to give me. A normal free user did not receive 25,000 API calls per day. I believe if you didn't go through approval back then you got something like 1,000 per month. So there was a consideration process on their part and a determination to green light my use case.
You could argue that the indefinite API access was in exchange for writing the app (service for service), but if this were me, I probably wouldn't bother. Maybe I'd write an adversarial-interoperability backend to replace the API, or open-source the app to allow other interested parties to do so. Or maybe I'd just say "It was a nice run", and let it die.
If you care enough to send a polite email, you could say that Yelp has a prior agreement, you'd appreciate them not reneging, and if they do, you'd appreciate compensation for your labour (minus, of course, the money you made from the software). Probably won't go anywhere, but…
granting API access in excess of the free tier would most likely constitute something of value, but yeah - probably wouldn't bother, it would be expensive to pursue and not worth it.
Officially, yes, something of value. In practice, just something.
> To my mind the acquiring and delivering of the [used chocolate bar] wrappers was
certainly part of the consideration in these cases, and I see no good reason
for drawing a distinction between these and other cases. — Lord Reid
> It is said that when received the wrappers are of no
value to Nestlé’s. This I would have thought irrelevant. A contracting
party can stipulate for what consideration he chooses. A peppercorn does
not cease to be good consideration if it is established that the promisee
does not like pepper and will throw away the corn. — Lord Somervell of Harrow
Oh thank you for that clarification. That's very interesting, but of course it is not worth it to me to pursue for the reasons mentioned in the post and the comments here on HN.
Yeah I think the only option in which this would make sense for you to peruse legal action is in small claims court for however much you had to pay in refunds. It’s fairly easy to do that pro se (representing yourself). And often companies are motivated to negotiate if they are sued in small claims, because just sending a lawyer to represent them would cost as much, if not more than just paying the damages. Obviously this depends a lot of jurisdiction and the specifics.
But at that point it’s not a question of cost, it’s a question of how much of your time and headache you want to spend. So yeah, probably not worth it
> My hunch is these start-ups don't want to show an empty hiring pipeline to investors.
This wouldn't make any sense. If a startup has headcount and budget, they're going to want to hire someone as quickly as possible.
Investors don't care about the minutia of how many people are in your hiring pipeline. If portfolio company had board-approved budget and headcount and was failing to fill those roles in a timely manner, that would be a huge red flag that something is not right within the company.
Investors care about result and efficiency. I don't think any startup is going to impress investors by wasting a bunch of time deliberately fake interviewing people and then failing to hire anyone.
What's more like is the company wants to hire, has told the teams they can hire, but the board is reluctant to approve more headcount until the team starts showing results. Another possibility is that they're waiting for financials to improve enough to justify the hire.
The article doesn't claim that at all.
The cryptographically secure part comes from doing cryptographic verification of the code before running it.
The article talks about using Rust to improve memory safety.
reply