Hastlayer based Antikernel

[plasticalligator]

I have this unshakable desire of prototyping a proof-of-concept in Hastlayer where the FPGA bootstraps a small operating system and then behaves as a hardware-based Kernel responsible for performing all Ring-0 operations in lieu of a hard-CPU and have been wondering if anyone has attempted such an sziszüphoszű-megszentségteleníthetetlenségeskedéseitekértékony task - ^{_{did I just make the longest word even longer? I suppose I did.}}

This is essentially equivalent to the idea called an "anti-kernel" proposed in this paper: https://eprint.iacr.org/2016/55 whose author maintains not-so-active GitHub repository: https://github.com/azonenberg/antikernel

The ancestral bacteria living in my gut has me thinking Hastlayer could be uniquely suited for borrowing code inspiration from Microsoft's SingularityOS and CosmoOS ^{_{or even Midori if we combine our brain cells to launch an all-out assault sneak past the two security personnel in charge of guarding Microsoft's tape drive archives.}}

Or less poetically my old-wolf spirit animal gave me a vision and a tátos living on top of the égig érő fa said such a thing could be the Eallra Gerihtreccunga Mōdor for Hastlayer's seaworthiness to provide true real-time resilient analog I/O akin to the mythical AGC of the 1960s baked directly into a modern operating system kernel for satellites & telecomms where rebooting might require raising enough venture capital to build a stratosphere-capable ladder and determine the difference between life-and-death especially in fly-by-wire inertial navigation systems^{_{or robotic surgical equipment where a kernel panic might end up with a a patient's nose being grafted to their forehead.}}

Given my budget constraints I am seeking some input into how much of an undertaking it would be to hack Hastlayer to work on XC7A100T-L2FGG484E, XC7A200T-2FBG484E or XC7A200T-2FBG484I which are in the same Xilinx family as the Nexys A7-100T // XC7A100T-1CSG324C ^{_{unless some generous soul out there wants to fund my blockchain-powered time machine running on a solar powered quantum computer embedded inside a tungsten cube that sends you into the future one second at a time by staring at it cross-eyed.}}

I would also be willing to settle for Hastlayer running on a "budget-friendly" SoC-FPGA such as the Xilinx Zynq to get a easily-replicated proof-of-concept project working.

[Piedone]

Having kind of a hardware kernel is a very cool idea! Something that I'd expect somebody with Hungarian ancestral bacteria to come up with :D. I've also opened a discussion under Cosmos about it: CosmosOS/Cosmos#2838. I'm curious what the people there will think.

Both FPGAs you mention are indeed similar to what we support with Nexys indeed. The first one is basically the same, the second one almost, but with roughly twice as much resources.

However, while the FPGA chip itself might not be an issue, its board and integration with a host PC is really complex, it needs to be newly done for pretty much every board. And the Nexys is very different from anything in the M.2 form factor.

Can you tell which specific FPGA board you're thinking about, though? Because if it supports Vitis (https://www.xilinx.com/products/design-tools/vitis.html) then it's perhaps doable, since Hastlayer uses Vitis under the hood. How we use it is as kind of an adapter layer, so the level of effort for a new Vitis-compatible board is manageable. Certainly less than a space ladder :).

The most budget-friendly option would certainly be a Zynq. It's also cool that you can run everything, also your .NET software, on the same chip, as an embedded device.

However, if you don't insist on having a physical device right there with you, renting an FPGA-capable VM in Azure is not just easier, but also cheaper if you don't leave it running. Your code will be compatible will all devices Hastlayer supports, within the resource limitations of each device (i.e. a large code base may fit on a large FPGA only).

See the relevant docs here.

[plasticalligator]

Zynq or Azure probably makes the most sense and have been looking at Zynq boards.

I got so absorbed with nyelveken szólás that I forgot provide the link to the M2 FPGAs: https://github.com/RHSResearchLLC/NiteFury-and-LiteFury.

Assuming that the manufacturer intends to keep producing them for this price ($100 ~ $200 in Amerikai Pengő // 35k ~ 70k Forint)
it might be nice to get Hastlayer running on these boards - especially considering that the Raspberry Pi 5 now has an PCIE slot.. It's a hare-brained idea but you might be able to partner with a company to produce Hastlayer Hats.

The idea was for the FPGA to mimic a solid-state drive during the boot process and then have the CPU defer to it for anything Ring-0
related but systems leaving the Earth's surface would probably need boards with the FPGA running on a lower level than PCIE can provide.

Before signing off I'll toss some more erdélyi szász talaj into the thread - one of the interesting aspects of hardware-based kernels is the possibility of interprocess communication that uses homomorphic encryption.

Hardware-kernels could assign public/private keys to each spawned process IDs, determine what other processes should be able to access their data, and then perform tipsy-top-secret calculations on the hard-CPU on data without it being able to read any of the data.
Naturally it would be limited by the FPGA's RAM in absence of the aforementioned low-level control but it's still fun to think about.

[Piedone]

Thank you for your continued szász talaj :).

Thanks for the NiteFury link! These boards are quite interesting and look quite capable. The challenge for Hastlayer compatibility is gaining access to its DDR3 RAM (since the Alveo boards we support use DDR4). Though the Zynq we support also has DDR3, so probably with Vitis it would just work. PCIe is supposed to work too. However, due to the different form factor and thus physical connections, different FPGA family than what we support with PCIe, and that the boards aren't by Xilinx, I wouldn't say that due to the Alveos working this should more or less work too.

Do you perhaps have some time to do some testing, poking around with these boards?

Also thanks for the other creative ideas. Using FHE for inter-process communication is something I have never thought about; though perhaps that would only benefit from hardware support if it's significantly hardware-demanding for a given use case.