intern4tional

arene_base provides low level C++ facilities to help development of safety critical software in compliance with Woven by Toyota's C++ development best practices.

You misunderstand.

Ben is a random engineer, he is definitely not the proper point of contact. FOSS compliance is serious, so if this is real, do escalate it.

Correct, that was my intent - Ben isn't the proper channel as he is just an engineer responding to comments here. Stuff like this is serious and so should be escalated.

Compliance with FOSS licenses isn't a joke.

Nothing. This isn't something that is even tracked. AI usage is obviously encouraged but HR has far better things to do than go gather this kind of data.

Internally, depending on what product is being worked on teams will have different development flows and different usage points of AI. For things like VSCode, teams have freedom on how they use it completely.

Assuming this is real and you have the authority to share your work from previous location; you should reach out and contact Microsoft Legal directly.

A random engineer on Hacker News is not the proper channel.

Link: https://www.microsoft.com/en-us/legal/compliance/sbc/report-...

QNX is heavily used in industries where functional safety or particular high assurance models are required.

Sure FreeRTOS has a SafeRTOS mode, but its not sufficiently functional for a modern ADAS stack or complex robotics systems. QNX is used in all major automotive companies around the world for a reason, and a crucial part of NVIDIA's DriveOS stack.

He was freed in 2020: https://arstechnica.com/tech-policy/2020/02/man-who-refused-...

https://web.archive.org/web/20061023112233/http://software.s...

"Microsoft made both changes in response to antitrust concerns from the European Commission. Led by Symantec, the world's largest antivirus software maker, security companies had publicly criticised Microsoft over both Vista features and also talked to European competition officials about their gripes."

Perhaps reactive, but there were definitely conversations between EU and MS.

As someone that watched the video (and directly worked on this stuff during my time at MS), I think Marcus has no idea on how the OS vendors relationships work with governments. He misses the fact that if Windows releases user-level APIs that provide similar functionality, it would break existing functionality and force a migration.

For the example he uses patch guard, existing functionality did not break anywhere as significant as say would evicting drivers from the kernel.

Windows does have the ability to have sovereign builds (and has had this since 2016?), but the capability wasn't present when the decision was made (in 2006). Windows build is complex and tightly coupled with performance testing, telemetry collection, etc and at the time this decision was made, not feasible to do.

Reversing a change from 2006 would likely bring anti-trust action from the remainder of the world immediately, as that change from 2006 is relied on by everyone else globally today.

The EUs stance isn't bad either, as MS has a competitor in this space that also relies on a kernel driver (MDATP does use a kernel driver) and it is unlikely MS would remove its own competitor from the kernel (at least this item was not discussed during my time at MS and I was in the security space of Windows).

Industry forum was external, MS did not start that.

I do not know enough to properly answer on the concrete reasons why, only that it was external. Sorry.

As someone that worked at MS, on a team that worked directly on this issue (among other things) some years ago, MS did figure out better solutions and did discuss it with industry.

MS has an entire forum for discussing these things with industry (https://learn.microsoft.com/en-us/defender-xdr/virus-initiat...) and has had variants of said forum for some time (I think the first effort was in 2010).

Kaspersky was running an SSL/TLS Proxy in the kernel IIRC and didn't want to have to move it elsewhere due to the fact it would require them to rework their product quite a bit.

The solutions MS (we) proposed were agnostic and overall better, the anti-malware industry simply doesn't want to make the changes as these things do impose technical work on existing products.

Here's an actual compliant at MS to the EU from an anti-malware vendor: https://www.techtarget.com/searchsecurity/news/450420491/Mic...

This is and has been a thing for quite some time. Windows is a highly regulated OS.

There is basis for that assertion.

Via Google: https://www.techtarget.com/searchsecurity/news/450420491/Mic...

(Also via myself, as I was at MS when we wanted to make this change and the EU said no.)

So the grandparent poster has a fundamental misunderstanding of how Windows works, and why CrowdStrike has a kernel driver in the first place.

Microsoft has long desired to kick AV vendors out of kernel space and has even attempted to do so prior, however because of its dominant position in the market, it is unable to do so. I was at MS when an iteration of this effort was underway, and the EU said no.

See, Windows is a highly regulated OS today, and making a change like kicking out AV vendors from the kernel runs afoul of antitrust laws.

Example: https://www.techtarget.com/searchsecurity/news/450420491/Mic...

Microsoft does provide user-space capabilities: https://learn.microsoft.com/en-us/windows/win32/amsi/antimal... but vendors are not required to use it, nor can Microsoft require vendors to use it (for the aforementioned antitrust reasons).

Microsoft also has ELAM: https://learn.microsoft.com/en-us/windows-hardware/drivers/i... which is a rootkit / bootkit defensive mechanism. A defect in the definition files (as noted in the twitter thread) is what caused the crash in an ELAM driver. CrowdStrike obviously was not following the required process for ELAM drivers.

Mind you, the claim about CrowdStrike not impacting Linux is also bogus: https://www.neowin.net/news/crowdstrike-broke-debian-and-roc...

I think returning results in a timely manner is more than an acceptable assumption.

The poster clearly thought about search in terms of the existing Google search functionality which is near instantaneous.

Usability matters to the average end user and a delayed search is not usable for most people.

This makes it something that the average person cannot do; you're suggesting something that already requires more time and resources than 75% of the population has access to.

If you're serious about this than go talk to a non-tech person and tell them to self-host email and see how they do. Look at their challenges, build a solution and then offer it.

I don’t disagree with this either, I just didn’t think of it when I put my response in.

Naming and shaming does work.

Of course, but it that’s good in most cases as then you don’t get an overreaction.

The right people will read it (Chattr.ai’s customers) and respond . Right now everyone looks at it and some CISO will overreact and make everyone go check their Firebase configurations which may likely be a non-value add.

Title: I pwned Chattr.ai via Firebase misconfiguration

That’s what you should call it. It explains to readers what’s going on without over sensationalism.

That isn’t too long either.

No, as company employee is directly tied to and the responsibility of the company.

These companies are responsible for their employees behavior and data but they are not responsible for nor legally liable for (in most cases, some exceptions apply) the actions of a third party that they have retained to help with hiring.

In fact the contract they have with said third party likely absolves them of any liability.

The title should be: I owned an AI startup via Firebase misconfiguration.

You can even name the startup if you want. That’s not flashy though and this person wants marketing.

This isn’t owning fast food chains; rather compromising some AI startup that has some of them as a customer.

Title is misleading.

So this is mostly a solved problem at other OEMs, and I do not know how Ford does it.

I know that other OEMs do variant testing, have complex SILS (software in the loop) test systems so that all potential failure scenarios are tested in software prior to update. The downside is that updates are slow to release then, with some other OEMs only putting out an update once or twice a year, but they avoid this scenario.

Software wise, the industry is moving towards defined standardized interfaces for sensors that are versioned. Example: https://blackberry.qnx.com/en/ultimate-guides/software-defin...

Back to the topic though, all major domain ECUs will have an A/B partition. Usually one of these is the OTA master, and has the capability to update the other microcontrollers via UDS. For safety critical microcontrollers that do not have a A/B partition, about half will not support OTA (this is just a thing for small MCUs), and the other half are flashable completely. So something like this is rare and should only happen on a secure boot failure or some other catastrophic scenario, which ideally your SILS system will have tested (SILS won't test all scenarios but will definitely test all failure cases).

Larger OEMs may even have HILS (hardware in the loop systems) where these things are also tested on physical hardware prior to launch, but with software defined vehicles this is slowly going away.

I think there is one other unaccounted aspect that the article doesn't acknowledge.

I've never seen a SRE lead go to prison for an outage, but as of late a few CISOs have been charged, convicted, and sentenced to prison for failings on their watch.

Cybersecurity may not be special but the results of a failing there are unique compared to SRE work.

Likely not their code.

OTA is generally developed by tier 1, so this is probably a bug in the tier 1's code. (Samsung, Panasonic, Sony, etc are common tier 1s in this space.)

So, this will be my last response to this thread as I think it's run it's course.

voluntary standards aren't standards

Most of the worlds standards work this way. They are standards, and it is up to various legislative bodies to decide how to enforce these things. In automotive, compliance with a standard is generally attested to a government and included in the package that is shared with other governments to allow import or sale of the car in their country. Tesla simply flaunts that.

safety related bugs

This kind of thing isn't a thing if you understand automotive safety, or shouldn't be. You should have sufficient safety controls such that an unsafe condition will not occur. If this is a thing, you're talking about a bug then in the applied safety mechanism that allows an escape.

watchdog timer expiring is an appropriate response?

Keys for SecOC get out of sync and throw an error. Not a safety problem per say, but your health check (since I consider watch dog timers an implementation of health and state management), you'd trigger a restart of the software to resync the keys.

pretend certification is bullet proof even if it is useful it can miss glaringly obvious errors

I don't, but when it works it is sufficient. Open sourcing something adds nothing when it works. Importantly, usually TUV assumes liability for things they certify in many cases (not all, but generally that is how it works)

limited to black box rather than in depth review and formal guarantees

We get the latter at my place from them, so I would poke at this area more if you think its black box only. This likely depends on the contractual terms, and who assumes liability.

VW managed to bamboozle them in a way

The VW code is likely not safety relevant, so it wasn't reviewed as in depth. Most ECU code also isn't reproduceable even today.

So I don't think anybody is looking too hard.

On this I generally agree as someone in this space. The amount of money invested in Pwn2Own is small given the barrier for entry: https://www.zerodayinitiative.com/blog/2023/8/28/revealing-t...

Tesla being non-compliant is precisely my point: they get away with that because they don't have to open up their code to scrutiny.

This is an inaccurate assumption. ASIL compliance is something that you can publicly state, and Tesla explicitly does not. Most automotive products that do follow such standards generally state such. (Example: https://www.aubass.com/products/cp_top.html - search for ASIL D)

Making something open source does not in any way make it safe, unless your enforcement plan is having lawyers look into it and in which case you end up with lawsuits and likely endless litigation that results in a closed platform again. Tesla's calculation is that no one will enforce safety controls or standards compliance on them, and to be fair to date they (Tesla) are right.

Personally I would consider any watchdog error that was not directly related to a hardware fault (say a bitflip) as a failure and I'd like to have my car report such failures.

This is an opinion and does not properly account for the multitude of scenarios that must be dealt with in automotive. Automotive, unlike aerospace, rarely has failover hardware or in some cases even A/B partitions on the disk for failover in software. Add in the need to process signals in real time and you will encounter situations where use of a health check (watchdog timer) is an appropriate response, and the use of one should not need to be reported.

embedded software developers do not get to claim the high ground around what they consider safe or unsafe given the code from that world that I've had my eyes on.

They (embedded software developers) don't make such claims; when something is safety certified, an external third party does the validation and verification and asserts that an implementation and processes are either safe or not. In the EU this is usually done by TUV (https://www.tuv.com/world/en/) or Horiba-Mira (https://www.horiba-mira.com/).

This gets extremely complex as this is often hard tied to the hardware (support for a safety island, how memory is managed on the SOC, etc) and the overall E/E architecture (selected messaging protocol for the backbone) and layout of the vehicle. Analyzing a system of systems to determine all the possible impacts and make sure that the chance of failure is small enough to be acceptable is a hard problem to solve and not one any single engineer does.

This comment chain appears to have a fundamental misconception of what constitutes safe and what does not.

Automotive standards and automotive coding standards approach safety in a different way than most people think (and given your comments I would say this includes you). If you're curious, you can have a look at some rules to evaluate automotive code that are published here: https://github.com/github/codeql-coding-standards

In short, the rules do not aim to eliminate failure or crashes, but rather make the crash predictable and uniform when a crash occurs so that it can be dealt with. This is further complicated by where and how the automotive manufacture chooses to implement safety controls. It is entirely possible to have a bunch of unsafe code running somewhere on a car, and simply have a small safety shim around said code that prevents the unsafe code from impacting the safe operation of the vehicle.

With that in mind, let's take the example that you use here of emissions cheating software. Emissions is likely not considered safety relevant (it might not even be QM, it just might be some code) and so no safety requirement applies to it. So, no real scrutiny would happen there regardless, at least from a safety perspective. See, validating that software passes a particular safety certification is time and money intensive and manufacturers therefore keep the amount of code that they qualify as safe to a minimum. This means as an example that the infotainment systems of many manufacturers are not safety relevant and no safety function should exist on or interact with them.

A few other things to consider from other threads:

- Telsa doesn't necessarily follow or adhere to safety standards. They (Telsa) are explicitly non-compliant in some cases, and this is partially why there are investigations into their practices.

- Industrial robotics code is just as bad if not worse than most automotive software from what I've seen. As you note, its that these robots are not under manual control

- None of this prevents the software from being open source. There are plenty of safety qualified open source projects. This simply limits who can contribute and how contributions are managed. The main reason why many things in automotive are not open source is that the ECU manufacturer isn't interested in doing so, and the Tier 1/2/3 that does the implementation is even less so.

Even that is not sufficient to ship a 2,000 machine there.

This is fanfiction or she told them her address and consented to receive the shipment. Delivery companies do not simply take location coordinates to deliver a laptop for a multitude of reasons, including insurance liability.

This also may run afoul of privacy regulations etc depending on where she lives.

Anti-trust settlements and legislation, along with regulation as a result of those do dictate multi-browser support for some things.

Microsoft and in particular Windows is heavily regulated.

Former MS:

Different development teams have different attestation requirements. My team did not require commits to be attested via yubikey when I was there, although I know at least one team that had that requirement.

It was an internal team specific requirement though and one of their own choosing (meaning they imposed it on themselves).

A few other things:

- Azure DevOps is public, you can see it or try it out here: https://azure.microsoft.com/en-us/products/devops

- Internally at MS, stuff is dogfooded on dev / test / pre-production builds so things are broken often. Think like being on Windows Insider constantly only its even earlier in development (canary releases or other trial branches).

- MS doesn't require you to use a specific browser internally. IIRC the internal standards actually require internal sites to support Firefox, as there are places in the world where MS has employees where Firefox usage must be supported.