<marcan>
alright, time to catch up with everything...
<marcan>
sorry for yet another week mostly offline, it's been a bit hectic in my life
<marcan>
things should calm down now though
* marcan
catches up on a pile of email...
<kloenk>
marcan: I have my boring lecture tomorrow again. Should I try to covert adt to rust, or build some fat support (if fat, where to hook it?)
<marcan>
adt isn't an attack surface; if the adt is compromised then the whole system is
<JTL>
marcan: good luck
<marcan>
if you want something to investigate, I'm curious whether we can bypass cargo and just git submodule in the things we need, to make the whole system more self contained (one recursive clone like we already do, no extra network access or anything for builds)
<marcan>
also, since this code is only for chainloads, it means we can support the use case of people installing "official" m1n1 in non-chainload mode (from a binary) and then doing local m1n1 builds for development, without depending on rust at all
<marcan>
which I think is worth it; as cool as rust is, it's worth keeping m1n1 builds as friction free as possible for folks, and the big part that benefits from it is not something needed for most use cases
<kloenk>
Would you be willing to change to meson for that? I saw how to call rustc from kbuild. I’m damaged for life xP
<kloenk>
The submodule stuff is actually why I can’t currently build it with one command on my Linux machine. My builder does not copy the submodule
<marcan>
is it really that bad? I thought it was just a compiler down behind the scenes
<marcan>
I've been meaning to learn meson, but I don't know if doing that on top of the rust stuff is really called for right now :p
<marcan>
if we can get cargo to use pre-downloaded assets for all the deps and never talk to the network, then using cargo to build the rust chunk is fine
<marcan>
(this is partially driven by me having had, er, bad experiences with language-native package manager stuff when doing things like building distro packages... the tool is fine, going out to the internet to download stuff isn't)
<kloenk>
marcan: Yes, that’s possible. But not that good with submodules. What about a dist make target, which creates a tarball?
<marcan>
hm, what's different between that and submodules?
<kloenk>
marcan: Totally agree. I’m from the nix side.
<kloenk>
marcan: Cargo would download it from crates.io
<kloenk>
I can try with submodules though
<marcan>
I mean what would the tarball contain?
<kloenk>
Cargo config to use the vendor dir, and the vendor dir, created by cargo
<marcan>
right, so ideally we'd build that vendor dir out of submodules; alternatively we could just vendor in the deps in the main git tree, which we already do for tinf/lzma/vsprintf/dlmalloc/chunks of pdlibc anyway
<kloenk>
Yes rustc is basically a compile, but cargo handles all the cross compile stuff. That’s why I would prefer it
<marcan>
(fwiw: I know cargo makes life easier for more complex projects, especially around dependency updates... but I'm not too worried about that because the scope of this part of the code is so simple, I don't see us ever really needing to upgrade the deps, unless there is some catastrophic security fail in the ed25519 package or something)
<kloenk>
Ok, will try that
<marcan>
anyway poke around and see if you can show me how things would look; I'll do that myself too and decide at some point, but first I've got more pressing things on my plate :)
<kloenk>
Yeah, no worries. Thanks for the answers so far :)
<kloenk>
The ed25519 lib is not completely no_std. The batch feature needs alloc. So probably will create a globalAlloc next, and then try to add the crates as a dependency for testing
jeffmiw has quit [Ping timeout: 480 seconds]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<marcan>
we don't need the batch feature
<marcan>
we shouldn't need any of the optional features
arnd_ has quit []
arnd has joined #asahi-dev
<sven>
we'll also need a GPT crate, but i'm sure there's something with no_std for that one as well
MajorBiscuit has joined #asahi-dev
<kloenk>
I think alloc still has an advantag, for strings and CStrings for ffi and so. It should be fairly simple to implement
<sven>
imho the whole thing should be as simple and as dumb as possible
nsklaus has joined #asahi-dev
manawyrm has quit [Ping timeout: 480 seconds]
V_ has joined #asahi-dev
mixi has quit [Ping timeout: 480 seconds]
leah1 has joined #asahi-dev
kloenk has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #asahi-dev
psykose has quit [Ping timeout: 480 seconds]
Dragoon has joined #asahi-dev
jn_ has joined #asahi-dev
Dragoon is now known as Guest1237
psykose has joined #asahi-dev
null-nop[m] has quit [Ping timeout: 480 seconds]
DiscoPenguin[m] has quit [Ping timeout: 480 seconds]
cde[m] has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
IbrahimMAkrab[m] has quit [Ping timeout: 480 seconds]
leah has quit [Ping timeout: 480 seconds]
nsklaus_ has quit [Ping timeout: 480 seconds]
Shiz has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Ping timeout: 480 seconds]
GraysonGuarino[m] has quit [Ping timeout: 480 seconds]
IsfarSifat[m] has quit [Ping timeout: 480 seconds]
josipknezovic[m] has quit [Ping timeout: 480 seconds]
MatthewLeach[m] has quit [Ping timeout: 480 seconds]
sppdqd[m] has quit [Ping timeout: 480 seconds]
legarts[m] has quit [Ping timeout: 480 seconds]
xorly[m] has quit [Ping timeout: 480 seconds]
svenpeter[m] has quit [Ping timeout: 480 seconds]
Dementor[m] has quit [Ping timeout: 480 seconds]
ryanhrob[m] has quit [Ping timeout: 480 seconds]
samfromspace[m] has quit [Ping timeout: 480 seconds]
rethematrix[m] has quit [Ping timeout: 480 seconds]
RowanGoemans[m] has quit [Ping timeout: 480 seconds]
matthewayers[m] has quit [Ping timeout: 480 seconds]
NotHere[m] has quit [Ping timeout: 480 seconds]
long[m] has quit [Ping timeout: 480 seconds]
landscape15[m] has quit [Ping timeout: 480 seconds]
citruscitrus[m] has quit [Ping timeout: 480 seconds]
ybk[m] has quit [Ping timeout: 480 seconds]
wollymilkcap[m] has quit [Ping timeout: 480 seconds]
casperes1996[m] has quit [Ping timeout: 480 seconds]
roxiun[m] has quit [Ping timeout: 480 seconds]
_andy_t_ has quit [Ping timeout: 480 seconds]
djk121[m] has quit [Ping timeout: 480 seconds]
timokrgr has quit [Ping timeout: 480 seconds]
nirusu[m] has quit [Ping timeout: 480 seconds]
abbas_faiz[m] has quit [Ping timeout: 480 seconds]
jn has quit [Ping timeout: 480 seconds]
V has quit [Ping timeout: 480 seconds]
ryanhrob1[m] has quit [Ping timeout: 480 seconds]
mariogrip[m] has quit [Ping timeout: 480 seconds]
sproede[m] has quit [Ping timeout: 480 seconds]
lockna has quit [Ping timeout: 480 seconds]
houlton[m] has quit [Ping timeout: 480 seconds]
kjm99[m] has quit [Ping timeout: 480 seconds]
ghantaz[m] has quit [Ping timeout: 480 seconds]
kloenk has joined #asahi-dev
<kettenis>
can we please avoid pulling in the world?
<kettenis>
(full disclosure: I'm a rust skeptic)
<sven>
i'm not gonna enable that chainload from fat for my machines anyway. i'm very happy with the 1TR roundtrip fwiw
Shiz has joined #asahi-dev
<marcan>
it's mostly for distros that want to ship m1n1 and do end to end upgrades, which will need that for DT updates
<marcan>
if you're rolling your own kernels you don't care
<marcan>
(if you don't mind the round trip)
<marcan>
I'll use it for dogfood purposes on my production machines with Arch once it's done
<sven>
sure, i can see why it's useful. i just don't want to manage my own signatures if I can just use the 1TR thing to take care of it
<marcan>
kloenk: alloc has interactions with C malloc; either we build it on top of that (expands the attack surface to some extent) or we have them fight for heapblock (which is doable but not optimal)
<marcan>
if we can get away without alloc I'd rather do it that way
<kloenk>
I would have set rust alloc onto the dlalloc used by the C portions
<kloenk>
kettenis: Totally agree not to pull the world. But I also see no advantage in reinventing the wheel, and writing an own fat driver, if there is somtihg good usable available
akemin_dayo has joined #asahi-dev
eragon has joined #asahi-dev
<marcan>
it wouldn't be that bad to reinvent FAT, but yeah in this case I think reasonable implementations exist so there isn't much point
<marcan>
the main point of this exercise is to just use Rust to get memory correctness guarantees which basically makes the whole thing close to provably secure (if not formally, then very easy to informally convince yourself it's secure)
<kettenis>
well, if you are using alloc...
<kloenk>
The fat library says it does not need alloc, so even all is stack based
<marcan>
if rust guarantees malloc/free correctness at the interface that *could* be done, but since it looks like we can get away without it, that's better
<kettenis>
anyway, don't just use tools because they're cool
<marcan>
the dumber the C<->rust interface the better
<kettenis>
I see too many open source software projects that end up with insane build-dependencies
<marcan>
rust should be "read block, write block" on one end and "give me a verified m1n1 blob" on the other, no more
<sven>
write block? :-P
<marcan>
er, yeah, just read block
<marcan>
kettenis: don't worry, you don't need to tell me about left-pad :p
<marcan>
as I said, my intention at this point is to make this entire thing both self-contained without a build system going off to the internet, and optional (and in fact disabled by default)
<marcan>
in fact even distros won't have to build any of this, unless they want to ship their own installer
<marcan>
only I will
<marcan>
since the 2nd m1n1 stage doesn't need it
<marcan>
and in the installer I can provide a 1st stage with the verification, which will be triggered by a payload command/var thing inclunding the distro public key
<marcan>
then the installer just needs to let you pick what distro you want to install to select a known pubkey (or pick for you if you choose an embedded install)
<marcan>
it will of course also have a mode to load a 2nd stage without any verification, for those who don't care
<kloenk>
Nixos already uses a ed25519 key for binary signing. I wonder if it would be possible to reuse that. But that's for the far far future :)
manawyrm has joined #asahi-dev
timokrgr has joined #asahi-dev
robher has quit [Ping timeout: 480 seconds]
manawyrm has quit [Ping timeout: 480 seconds]
robher has joined #asahi-dev
timokrgr8 has joined #asahi-dev
timokrgr has quit [Ping timeout: 480 seconds]
timokrgr8 is now known as timokrgr
manawyrm has joined #asahi-dev
<ChaosPrincess>
even as a rust enthusiast, being 'written in rust' does not equal the software being secure, to actually claim that, someone would need to audit fatfs crate code and probably pin the version.
<povik>
]/win 2
<povik>
oh sorry
_andy_t_ has joined #asahi-dev
<marcan>
ChaosPrincess: if the interface to C is guarded to ensure no invariant violations, and Rust itself memory safety, then modulo DoS bugs (which aren't really relevant), there is no real need to audit the fatfs code since its job is just to pull bits from disk that will then be signature-verified
<marcan>
that's the point of using rust for this
<marcan>
it's kind of rare to be in this position; we can say this because of how simple the problem we're trying to solve is
<marcan>
main thing I can think of is I should make sure stack overflows aren't exploitable; I think I got rid of guard pages during a refactor recently, I should reintroduce those
<marcan>
*Rust itself ensures
<marcan>
of course that's predicated in no unsafe blocks in fatfs, but that's easy to check for
<marcan>
and we will pin the version of everything; as I said I have no intention of letting cargo go out to the internet during the build process
<ChaosPrincess>
i guess we are not guarding from hostile nvme controller so that rules out toctou, and fatfs is just an inert blob of bits that way
<marcan>
toctou doesn't matter either because we're loading a file once and then verifying it
<marcan>
all the fatfs side has to do is pull a blob of bits from disk, once
<marcan>
doesn't really matter how it does that; either it passes verification after that or it doesn't
<sven>
i'm also not sure what threat model would include a hostile nvme controller (which has signed firmware loaded by iBoot) at that point
<sven>
if you can sneak in unsigned nvme controller firmware you can probably own iBoot anyway
<marcan>
yeah, even though I do want to audit the rtkit code a bit to plug any obvious vulns, this is a fairly far fetched threat model
<marcan>
in principle you could exploit the ANS codebase via the PCIe links to the NAND somehow, and then try to escalate from there
<marcan>
but I somehow doubt iBoot itself is fully hardened against this, being written in C itself...
<sven>
don't they claim to use some kind of memory safe C variant since a while? :D
<marcan>
there was something, yeah
<marcan>
but I mean, how do you do memory safety against DARTs and the RTkit interface?
<marcan>
there's no way the language itself is helping you with the buffer munging happening there