Note that the status on this is entered/not assigned, so it's in the works. However, the court may have required that they do so before proceeding.

The offending use does not have to be a 1:1 match to dilute.

(not a lawyer; not legal advice)

Trademarks are about recognizability, not about some objective similarity. There's no magic Levenshtein distance from a trademark.

However, they are also scoped to domains, so if there was some non-car business with such a name, they would also be entitled to the name, and the domains tend to be first-come first-serve in those kinds of cases.

Think of all the "Acme" or "A-1" companies that all have different products, and the general public doesn't have an issue conflating them.

(not a lawyer; not legal advice)

I agree pretty strongly. A translation layer like this is making an intentional trade: Giving up performance and HW alignment for less lead time and effort to make a proper port.

They have a Ubuntu derivative called DGX OS, that they use on their current lines.

I wonder which [publicly listed] companies would look at the abandonment of Jetson and still commit to having Nvidia set the depreciation schedule for them.

It's my opinion that nvidia does good engineering at the nanometer scale, but it gets worse the larger it gets. They do a worse job at integrating the same aspeed BMC that (almost) everyone uses than SuperMicro does, and the version of Aptio they tend to ship has almost nothing available in setup. With the price of a DGX, I expect far better. (Insert obligatory bezel grumble here)

At least in most jurisdictions, the egress to a gathering area can __never__ be blocked, there is some provisions for delay on emergency exits, but those require NRTL certification, and are actually usually mechanical.

You might be able to lock it down during periods of limited occupancy, and you can rig it to an annoying alarm, and maybe try to identify the person, and ban them from future. It is possible to get variances for this, but you usually need to either be a medical or penal facility.

Thanks for clarifying the finer points, my exposure to these systems is sending people to wire them up (mostly electrical but sometimes the control wiring) and not so much on the code side.

I looked up a wiring diagram for a similar gate and saw it had a fire alarm input so I assumed the AHJ in this case approved it based on the ability for the gate to open when an alarm condition is detected. That being said, it seems like a danger to me.

A regional hardware store chain has turnstiles at the entry points and swing gates at exits, which seems much safer for access control in a big box store.

Two main reasons I can think of:

Most current BMC platforms are older than seL4

Most run on hardware that is not supported by seL4, or at least on hardware where it has not been validated.

Not to mention that a task manager would be needed as well as tons of other services which aren't provided out of the box, and don't share the verification provided guarantees.

Pretty much all of them allow unrestricted access from KMS from factory, tough all of them have a way to disable it once configured, and HPE even throws shade until it's limited. KMS only works from the host itself.

Do we know if this is also the case for other systems that use Aspeed/ami BMCs, or if the key pair in question is exclusive to SM?

Yes it is.

Supermicro is one of the only vendors that tries to prevent this attack at all through RoT.

Other vendors you can flash whatever unsigned firmware you want. It’s very useful for adding in microcode for intel engineering samples, or malware…

This is not true. Almost all firmware is signed by every vendor, and there are standards from Intel and amd on implementation of code signing.

Look up Intel pfr.

Signed ≠ enforced.

At least for 4677 Intel stuff, gigabyte & HP and others let you modify the firmware and flash it.

HPE at least makes you flip a DIP switch, otherwise it complains loudly and halts.

I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd.

Imagine that:

* I have an evil system at 192.0.2.1

* target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq.

* foobar.com has a nameserver that silently drops any request with a ! in the first label

I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com"

192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped.

While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months.

If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.

That's surprising to me that DNS records received for domains not queried for can be set. I would expect DNS to require a query before being able to handle a response. I don't know why such behavior would ever be wanted.

RFC 2181 section 5.4.1 covers this a bit. Search for “additional data section”. So since at least 1997 you shouldn’t trust it. Subsequent rfcs also reference this topic a bit.