480 karma · joined February 15, 2013
It's not impossible to do in the field, but you can't really count on vendors surfacing that interface usually.
Some related work in the SR-IOV & iommu space makes this a lot easier to implement as well. I would be very surprised if zero new security edge cases get discovered in the next five years or so however. Regardless, I'd look forward to seeing the results of RedoxOS's work here, as this would be a practical alternate implementation of driver domains like you see used in Xen and Qubes.
The whole system falls on the floor though when the common carriers aren't, and have low quality processes that don't actually enable the counterclaim half of this process.
They have arguably correct reasons for doing this, but it's a false comparison to say that the software is inefficient when its just as efficient that anything else at that privilege level on the phone can do.
Of these there is a sample integration for XDPDropper to fail2ban that never got merged https://github.com/fail2ban/fail2ban/pull/3555/files -- I don't think anyone else has really worked on that junction of functionality yet.
There's also wazuh which seems to package ebpf tooling up with a ton of detection and management components, but its not a simple to deploy as fail2ban.
Specifically I refer to the debacle around the pebble 2 variants and the 1st round pebble core that totally got the ball dropped on it.
Its due to some strangeness in general with tcpip layers that don't forward PMTU discovery ICMP messages. You'll see the same thing in some cell networks, and wireguard is particularly fragile here, because wireguard itself doesn't have a PMTU discovery mechanism.
Or, to be more exact, wireguard currently doesn't have a method to 'bubble up' a PMTU process to the inner wireguard interface from mtu-impacting events in its outer layer.
There's hacks like https://github.com/luizluca/wireguard-ipv6-pmtu/blob/main/wi... that try to handle this by monitoring outer route discovered MTUs and then applying them to wireguard routes.
In applications where I've had to deal with this (wireguard over cellmodem networks), I tool my network setup to poll whatever the cell network mtu happens to be and then set the wireguard MTU appropriately.
This gets really painful though if you think you wanna do something like run a network that really wants a >1280 MTU over tailscale. It's pretty much not doable, and it is, in fact, my biggest gripe with tailscale. Yes, its suboptimal for the 'whole-internet' usecase, but I really do want my wireguard links to be 9000 MTU.
Maybe wireguard will get that in the future, since it is an acknowledged problem. I bet someone in the conjunction of secure networking and HPC spaces could even justify paying the wireguard team to implement it.
I'm aware that there a bunch of sqlite-compatible implementations and extensions that add MVCC. How close are those to actually being SQLite? Are they just a totally different table storage and transaction engine sitting behind SQLite's SQL parser/compiler and VM?
It turns out there is https://www.electricity-magnetism.org/magnetic-storage-devic... -- its a bit more complicated than what I'm more familiar with, which is film-grain-to-digital-equivalent resolution.
Anyway, you could do the work to work out the bit depth/signal rate you'd need to equate to reproduction of a given fluxdensity/recording rate. I would bet the numbers for classic PCM/PDM devices line up surprisingly close to certain tape systems.
On the flipside, once you know those numbers, you could also calculate what the expected analog equivalents could be, sample existing analog media/playback systems and use those to systematically characterize their quality, instead of going by earfeel, as it were.
You have a similar requirement for DFS handling on 5-7Ghz wifi as well, specifically for radar detection and transmission disable when an operating radar is detected: 47 CFR 15.407(i)(1) ( https://www.ecfr.gov/current/title-47/part-15#p-15.407(i)(1) ) -- This version of the requirement is what triggered the wifi aps lockdown issues back in 2016.
The communicated view of the FCC is generally that devices that easily permit operation outside the 'licensed boundaries' essentially become radio nuisances. A plurality of vendors will then essentially act aggressively to lock down their devices. If they don't, the FCC will and has leveraged the FTC to prevent import and impound shipping of such devices. Some other nations do something similar as well.
All that is probably ripe for a Chevron challenge, but even if you have a case that could win in court, taking the FCC to court is fraught, at best. It's definitely not for the faint of heart. In the case of big companies and vendors, where most of the IP for 4G/LTE/5G lives anyway, it would be pretty strictly a commercial mistake to pick that fight.
As for the political reasons they do it, it boils down to funding and the political fights that produced the system of auctioned spectrum and gatekept spectrum we have today. Tearing some of that system down is more likely to succeed. I have no idea what the second and third order effects of that would be though.
In that sense, there's real value in letting a situation develop its own consensus as the actors involved communicate and complete discovery of the factors and motivators involved in any situation, especially if it's clear that the actors have yet to explore that space.
That leaves you with the only remedy for a signal account that has accepted a link to a 'bad device' being to burn the whole account. (maybe rotating safety numbers/keys would be sufficient, i am uncertain there) -- If you can prove the malicious link was only a link, then yeah, the attack i described is incomplete, but the issues in general with linked devices and remedies described are the important bits, I think.
I'm only surprised it took this long for an in-the-wild attack to appear in open literature.
It certainly doesn't help that signal themselves have discounted this attack (quoted from the iacr eprint paper):
"We disclosed our findings to the Signal organization on October 20, 2020, and received an answer on October 28, 2020. In summary, they state that they do not treat a compromise of long-term secrets as part of their adversarial model"Every time I see a service purporting that it works best only with a single link to your Real Identity™, I'm reminded that the vendors only abstractly care about actually protecting the user, and then only sometimes.
Imagine being able get immediately three or four steps closer to doxing anyone interacting on YouTube. That's the actual impact of this bug IMO. It's good that this was fixed, but I don't think this class of bug goes away anytime soon. What do we need to do to get vendors and big companies to realize that this sort of design is landmines waiting to happen?
I have one, it works. Look at that board though! Given that component and board density, I don't find it very surprising that it costs around 200$ USD. Maybe you could get clever and design one that tries to work 100% via pcie device functions, and cut down the (physical) complexity of the IPMI device, but then the wide system and interface compatibility of the IPMI board would suffer.
To wit, the card needs to do the following, at a minimum:
1. Provide a VGA/UEFI/VFB-equivalent framebuffer for display capture
2. Provide a USB-device interface to emulate keyboard+mouse.
3. Provide a network interface of some sort for remote control
4. Provide GPIO headers/sinks at the appropriate power levels to replace traditional motherboard front-of-device switches -or- provide a PMBus header to perform equivalent functions with a support PSU.
You can get away with a subset of the above, but without that, you will be missing something critical to enabling lights-out-management. On top of that, a full-featured IPMI board is also generally expected to provide some fashion of environmental monitoring and fan control, which the PAUL does provide. It throws in some extra features as well, and provides some maintenance/lifecycle management capabilities of the board itself.
Providing all the above, is about the same amount of complexity of shipping a SBC and ecosystem itself, made moreso by the compatibility requirements.
You don't have nearly as big a market willing to pay $200 for all that -- its certainly not a matter of adding the chip and flash and dropping some vias.
Even having a standardish system-on-chip and non-bespoke firmware is 'new' (post-2020?). It could have been done 10-15 years ago sure, but noone was willing to do the long tail of tasks needed to get a product to market yet.
All it really takes is some investor pressure or a bright idea that they could chase some large enterprise sales money, and then youll see more optimizations in that direction.
Sometimes they're useful, like in cases where theres features that are important and even critical for medium-large enterprise usecases, but most people find boring to develop for. The risk comes, IMO, if you dilute the core product value while chasing those objectives.
Not lies, strictly, but I see plenty of evidence pointing to the 'fake job' phonemena that seems to be discounted, like this example: https://www.teamblind.com/post/Intuit-firing-up-ads-in-local...
Filtering out real information from data and anecdata is a challenge at the best of times, but I am ill convinced of the honesty of most of the recruitment market.
Some of the forgejo devs apparently believe that a collective copyright header is the same thing as a copyright assignment: https://github.com/go-gitea/gitea/pull/27455 & https://codeberg.org/forgejo/discussions/issues/67 I disagree on that point personally, but is there precedent here anywhere in the world?
Now that forgejo is not hard-tracking the gitea source, maybe we'll see in a year or two which project has better technical velocity or whatnot. IMO it's a coin toss between the two at this juncture.
IMO that would arguably be the more correct option, but it would also remove the sort of information pool that can enable leakage or fishing expeditions the current law seems aimed to generate.