Morello boards are hard to come by, but there have been efforts to offer cloud-computing style use of them, especially now that bhyve support exists; if you're interested I can try to find out more (I'd offer you time on my cloud-computing Morello cluster from MSR, but it's offline for silly reasons). The "Big CHERI" RISC-V FPGA boards are indeed quite expensive, but CHERIoT-Ibex runs on the Arty A7 or the purpose-built Sonata board, and those are much more reasonable. (I'd still love to see it brought up on cheaper boards, too...)

You might be interested in a very timely blog post: https://cheriot.org/cheri/myths/2024/08/28/cheri-myths-safe-...

It's great! The CHERI team at U. Cambridge has recently released their initial performance characterization of Morello, Arm's experimental ARMv8 w/ CHERI: https://ctsrd-cheri.github.io/morello-early-performance-resu... . The major take-away there is a little buried, but is:

> The above 1.8% to 3.0% is our current best estimate of the geometric mean overhead that would be incurred for a future optimized design

That seems to be well within people's tolerance for security features, especially as we think having CHERI would also allow us to turn off, and so stop paying for, some existing mitigations.

While there's a wealth of stuff to read about CHERI (https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...), if you're new to it and want something more presentation flavored than text, you might enjoy my talk from HOPE 2022: https://www.youtube.com/watch?v=dH7QUdXeVrI

Comments URL: https://news.ycombinator.com/item?id=32742699

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=12083259

Points: 1

# Comments: 0

There's no such thing as "the block doesn't decrypt" absent MACs/MICs or AEAD schemes -- encryption and decryption are just maps from N bytes to N bytes.

http://dyna.org/wiki/index.php/Publications

But, I don't think I understand your concern about abstract hashing and how it would need to be something fundamentally new. Both the order normalization and self-reference are simply preprocessing stages on your data, albeit slightly different forms. The sortedness requirement, I think, is captured by MIME type parameters (the "charset=" in "text/html;charset=UTF-8"), as it does not change the fact that the document is an RDF graph. For the placeholder trick, I think you're right and that you'd want something like a "text/rdf+selfref" MIME type to indicate that it is not in fact valid RDF until preprocessing has been performed. All told, your RDF module would be described in MIME as something like "text/rdf+selfref;sorted=".

There's a bug for firefox here: https://bugzilla.mozilla.org/show_bug.cgi?id=528148

Like so many similar works, this fails to cite the magnet: URI scheme (see, for starters, http://en.wikipedia.org/wiki/Magnet_URI_scheme) of which trusty URLs and the cited niURI scheme both seem to be small subsets. Introduced in 2002, these already defined a way of stably identifying an immutable object and providing one (or more!) suggestions for retrieval, which the present paper calls "authorities" but are likely better viewed as caches; one cache may be authoritative, but that's optional. The "modules" defined are probably better encoded as MIME types (and could be integrated into a magnet URI as "x.mime=.../..." attributes; the draft standard does not have a field for MIME type, sadly), rather than introducing yet another namespace for describing document types.

Speaking of caches, the paper's assertion that "any artifact that is available on the web for a sufficiently long time will remain available forever" is extremely worrying; the search engines of the Internet (other than Internet Archive, perhaps) are not altruistic entities out to serve your data forever. Their caches cannot and must not be depended upon by the scientific community; we must host our own data or pay for its archival, as much as that may be painful. There Ain't No Such Thing As A Free Lunch.

The trick for deriving self-reference is analogous to how IP packets carry their own checksum; it's an old trick, dating back to at least RFC 791 (section 3.1, heading Header Checksum; earlier RFCs do not seem to ) but almost surely earlier, and probably merits a citation of something. The use of the same technique for Skolemization is cute, providing a nice workaround for RDF's poor handling of existentials.

The performance numbers are worrying; streaming a search-and-replace pass (to transform out self-references) followed by a SHA256 verification through 177GB of data should not take 29 hours, especially given that the data is already sorted. CheckSortedRdf and CheckLargeRdf both exhibit linear time in figure 3, suggesting that the data being verified is already sorted (which would be consistent with earlier assertions that the existing implementation only generates sorted files); a better comparison would be to show CheckLargeRdf on randomized inputs, as all we see now is the overhead of a pre-processing pass that is, essentially, just verifying the sortedness of input.

ETA: I should have said "one possible technology"; there may be others, but I am pretty sure that an IP-less Tor node requires that you play the Tor Bridge game and stream the Tor protocol over a non-IP link. I have had a prototype of this design running, but have yet to have it to a point I consider robust.

It appears that ZFS lacks a full consistency checker -- scrub only walks the tree and computes checksums; notably absent in this procedure appears to be validating the DDT. While ZFS claims to be always on-disk consistent--and I certainly believe that the intent is that it be so!--I seem to have tripped over some bug ( http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016... ) which corrupted the DDT, and now I have no way of rebuilding it, so I dropped $$$ (for me) on a new disk array and zfs send | zfs recv so that everything rebuilt. That's sort of crazy, if I may be so bold.

I suppose I could take the pool offline for several days and poke at it with zdb, but that is not really desirable either.