sandsifter
docs
Our great sponsors
sandsifter | docs | |
---|---|---|
15 | 235 | |
4,821 | 1,714 | |
- | 2.9% | |
0.0 | 0.0 | |
about 1 month ago | about 2 years ago | |
Python | ||
BSD 3-clause "New" or "Revised" License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sandsifter
- Cascade: CPU Fuzzing via Intricate Program Generation
- I found a bug in Intel Skylake processors
-
The Cursed Computer Iceberg Meme
sandsifter
-
Speculating the Entire x86-64 Instruction Set in Seconds with One Weird Trick
This is a really clever technique! I was impressed by sandsifter[1] when it originally came out, and this seems an awful lot faster and less prone to false negatives (since it's purely speculative and doesn't require sandsifter's `#PF` hack).
At the risk of unwarranted self-promotion: the other side of this equation is fidelity in software instruction set decoders. x86's massive size and layers of historical complexity make it among the most difficult instruction formats to accurately decode; I've spent a good part of the last two years working on a fuzzer that's discovered thousands of bugs in various popular x86 decoders[2][3].
[1]: https://github.com/xoreaxeaxeax/sandsifter
[2]: https://github.com/trailofbits/mishegos
[3]: https://ww.easychair.org/publications/preprint_download/1LHr
-
Capstone Disassembler Framework
Idea:
If any assembler/disassembler author/team out there wants to produce an assembler/disassembler which is authoritative (difficult to do on x86, because there are so many different possible combinations of instruction encoding, https://github.com/xoreaxeaxeax/sandsifter : "Typically, several million undocumented instructions on your processor will be found, but these generally fall into a small number of different groups.") -- then what they'd do is to create a third program -- which "pits" the output of Assembler A vs. Assembler B, Disassembler A vs. Disassembler B...
That is, between any two assemblers (for the same CPU architecture/instruction set), or any two disassemblers, where are the anomalies?
If we think about an assembler as a simple function, y=f(x), that is, I give it a string of ascii bytes as input (x), and I get a string (1..n) binary bytes as output (y),
-
Tatradas – Disassembler for x86 executables written in Delphi/FreePascal
edge via patent and other legal protections" constantly-expanding-the-instruction-set approach.
So the issue, at least in x86-land is, "Who is the absolute source of truth with respect to the instruction set?"
Also, remember that Christopher Domas (Google him, you'll find a whole lot of interesting stuff) -- discovered that x86 processors typically can and do implement all sorts of undocumented instructions:
https://github.com/xoreaxeaxeax/sandsifter
>"Typically, several million undocumented instructions on your processor will be found, but these generally fall into a small number of different groups. After binning the anomalies, the summarize tool attempts to assign each instruction to an issue category:
o Software bug (for example, a bug in your hypervisor or disassembler),
o Hardware bug (a bug in your CPU), or
o Undocumented instruction (an instruction that exists in the processor, but is not acknowledged by the manufacturer)
Anyway, thanks for the link! (The second one! )
-
sandsifter — Breaking the x86 ISA
A discussion of the techniques and results can be found in the Black Hat presentation. Technical details are described in the whitepaper. Slides from the Black Hat presentation are here.
docs
-
Fedora Asahi Remix
https://github.com/AsahiLinux/docs/wiki/M1-Series-Feature-Su...
According to this page it should work on M1 MBP, but there is also a note about a specific patch released next week.
Unless Fedora has patches that haven't (yet?) been upstreamed, you could probably find that information on https://github.com/AsahiLinux/docs/wiki/Feature-Support
You might like even more: https://github.com/AsahiLinux/docs/wiki/Feature-Support which breaks it down by CPU and has some more detail.
It used to be rendered on the site, but it seems to have had a reshuffle with this release/announcement, or I can't find it now anyway.
-
Tuxedo Pulse Gen 3
> They don't support variations of software at all. They support the hardware. [...] Asahi does not need to support applications at all.
From their FAQ page[1]:
> We will eventually release a remix of Arch Linux ARM, packaged for installation by end-users, as a distribution of the same name. The majority of the work resides in hardware support, drivers, and tools, and it will be upstreamed to the relevant projects. The distribution will be a convenient package for easy installation by end-users and give them access to bleeding-edge versions of the software we develop.
As distro maintainers, it is their job to make sure the applications they package work on the hardware they support. This includes submitting patches upstream when that is not the case, as application maintainers likely wouldn't want to support such a niche environment directly. So, yes, they rely on volunteers to fix issues, but they will likely have to support many applications themselves.
There is still a lot of broken software, as this list[2] is surely not exhaustive.
> Same deal for any other hardware manufacturer. [...] Really not much different to other hardware manufacturers since Linux started.
No, it's very different. First of all, the amount of Linux hackers who volunteered to reverse engineer the wide variety of hardware was orders of magnitude larger than the Asahi team. Even if they limit the amount of devices they support, modern computers are far more complex than in the early days of Linux. Regardless of how talented the Asahi team is, maintaining all the hardware of a modern computer is a sisyphean task for a project run by volunteers.
Secondly, hardware manufacturers could see the benefit of getting their hardware to run in Linux, and many eventually took over support from volunteers. Apple has shown no interest in doing so, and has historically been hostile to open source.
> Asahi devs have made it clear that Apple has chosen to avoid blocking installation of other operating systems.
The fact they allow installation of other operating systems today, doesn't mean that this decision couldn't change in the future. Services are a large part of their business, and allowing a group of hackers to use their hardware without being part of their software ecosystem may seem like a non-issue today, but if this group grows larger assuming projects like Asahi are successful, this might become a considerable loss of income which wouldn't be in their best interest.
> Apple has no issue with it.
Can you point me to an official ackgnowledgment of Asahi Linux by Apple? Or any indication that leaving this door open was a sign of good will, instead of a lack of interest in closing it? What makes you think they wouldn't eventually lock down Macbooks in the same way they do iPhones and iPads?
> ARM is a stable well supported platform for Linux
It's really not. A lot of software works, but when it doesn't, the user is SOL. As you can see on their Broken Software page[2], the major issue is precisely with AArch64 support. This should improve eventually, and Asahi is certainly a torchbearer in this scenario, but today it's yet another hurdle of using Apple hardware.
[1]: https://asahilinux.org/about/#is-this-a-linux-distribution
[2]: https://github.com/AsahiLinux/docs/wiki/Broken-Software
- Speaker Support in Asahi Linux
-
Update on the Sonoma bug situation
More information about the macOS Sonoma ProMotion bug here.
- macOS Sonoma Boot Failures
-
Killing Windows 10 in 2025 could turn PCs into eWaste
> Asahi Linux is work in progress. Many hardware components are not yet supported!
-
The first conformant M1 GPU driver
> _clearly_ spent a lot of time and resources to make third-party OSes viable on Apple Sillicon Macs.
This actually isn't clear to me -- can you explain? Besides keeping an open bootloader [0], I'm not aware of any affirmative actions Apple has taken.
[0]: https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on...
The open bootloader didn't magically appear one night in Apple's git repository.
It boots in a notably different way than iOS machines do, and has some (AFAICT) pretty unique capabilities, including a fully-verified signed-boot of macOS partitions, while allowing third-party kernels at the same time.
Asahi's "Introduction to Apple Silicon" [0], and specifically "Security modes, Boot Policies, and machine ownership" paragraph outlines some of that, Apple's "Platform Security" [1] whitepaper does too.
Asahi's docs also explicitly state the same thing [2].
If you still don't think that shows significant amount of work and care were put into deliberately allowing third-party OS's to work on those machines, I don't think I can convince you otherwise.
[0]: https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
[1]: https://support.apple.com/guide/security/welcome/web
[2]: https://github.com/AsahiLinux/docs/wiki/Apple-Platform-Secur...
What are some alternatives?
idevicerestore - Restore/upgrade firmware of iOS devices
tinygrad - You like pytorch? You like micrograd? You love tinygrad! ❤️ [Moved to: https://github.com/tinygrad/tinygrad]
FEX - A fast usermode x86 and x86-64 emulator for Arm64 Linux
asahi-installer - Asahi Linux installer
nixos-apple-silicon - Resources to install NixOS bare metal on Apple Silicon Macs
AsahiLinux
linux - Linux kernel source tree
tatradas - Disassembler for x86 executables (16-bit and 32-bit) which supports PE, NE, MZ, COM and ELF file formats
trapcc - Computing with traps
mac-precision-touchpad - Windows Precision Touchpad Driver Implementation for Apple MacBook / Magic Trackpad
darwin-xnu - Legacy mirror of Darwin Kernel. Replaced by https://github.com/apple-oss-distributions/xnu
SwayM1 - A Guide on how to install and configure sway for M1 MackBooks.