Yes, the Xilinx space grade devices are engineered and qualified for radiation tolerance. These are FPGA socs and share no heritage with AMD desktop and server processors.
This is an economic problem due to the poor level of interconnection between the Iberian Peninsula and the rest of Europe. It is also something that is actively being worked on. With better interconnection, renewable power could be more readily exported to the rest of Europe during peak generation, rather than ending up in the situation described currently where renwable generation is forced offline.
To my knowledge neither AMD nor Intel ship any processors that are rad hard or rad tolerant. For aerospace applications this is a very specific type of device which requires specific engineering work to achieve. You don't just get rad tolerant design through standard error correction and you definitely don't get rad hard without designing for it.
I am a bit confused about your situation. Did you have a stolen card used to make a purchase at ebay that was not under your account? Or did you make a purchase at ebay and have an issue with the product you received?
>As a consumer, I thought I was safe; when saving my credit card to a billion dollar valued european merchant, or when i purchase something from supermarket and ignore the receipt, but the reality is slightly different from that.
>I got the money back via chargeback in short time.
So as evidenced, you are protected by the fraud infrastructure. The bank ate the loss for the fraud and you were made whole. In the end, the banking system cares about fraud loss. And they are exceptionally good at finding the fraud. Making changes to the card payment system is extremely difficult, due to the vast scale of the systems, so without a very good justification that a particular change will move the needle on fraud rates, the banks will opt to not make the changes.
>Even that ignores the fact that major corporations are frequently attacked by state actors, so really the minimum standard for protection against expected threats should include those as well, but I will leave that aside for now since the overwhelming sentiment is that protection against state actors is so utterly hopeless it is not even worth mentioning.
It always has been, it's just now the state actors are more and more active (and visibly so).
Pentests work to secure the product under test at the point in time of the test (if the company cares to fix the bugs...). The real solution is to design in security throughout the software lifecycle, not play pentest wack-a-mole game at the end of the cycle. If a pentester is finding trivial SQL injection in an app, then it is clear that the company never considered security. And unless the pentest makes them care, the cycle will just continue.
It is an investment problem, they need to invest in security expertise, not security products and services. And that is the sad part, absent the company really caring to spend that money or an external demand (regulatory or customers) it just isn't going to happen. They'll just layer on more products and services and call it a day.
The company I work for (consulting) upended the entire strategy to basically use pentests to sell managed services (XDR, NDR, SOC, vuln scanning, "continuous pentest") that does nothing to meaningfully move the needle on security. Which of course the market will buy, but it is incredibly demoralizing to see expertise sacrificed to the alter of recurring revenue.
I forsee issues with really getting use out of any commodity language model in the hardware security context, because hardware systems notoriously lack standardization. And often times, the technical knowledge (datasheets, app notes) is locked behind vendor NDAs, or straight up not documented, only existing in the minds of engineers. The implementations of said designs are similarly highly proprietary, with little public "real" systems to train models on.
So the issue is two-fold:
* The knowledge must be documented and accessible for training.
* A bespoke model must be trained this documentation.
It is unlikely that both of these things happen in the general model context. Perhaps individual chip vendors will eventually pursue this, but I suspect it is just not a priority for them.
I mean it in the sense that AI security hype and the larger geopolitical environment has woken up a lot of people to the reality that they need to consider security. And the ones that haven't woken up yet will get a wakeup call when they are breached. It also increases the demand for real security expertise, which is already scarce.
Also, in my niche (hardware and embedded product security), AI doesn't a have a functional impact to the work except in code analysis, but even that is difficult given the level of abstraction these systems are built at.
Whenever I tell people I work in computer security, their first question is "are you worried about AI taking your job"? To which I just laugh and respond "AI is job security"
Additionally, total dose is only one part of the equation. Single Event Effects (SEE) also must be mitigated.
You can read NASA JPL's ASIC design guidance for a brief intro.
https://parts.jpl.nasa.gov/asic/Sect.3.4.html#A0