<stikonas>oriansj: do you think it's acceptable to skip range check for label calculation in UpdateShiftRegister <stikonas>we'll only ever use it for a couple of programs (hex2.hex1 and I guess catm.hex1) <Hagfish>xentrac: a given user of a piece of software should be able to estimate the value of an attack to better than 10 orders of magnitude <Hagfish>for a start, most users don't have teradollars worth of assets <Hagfish>(yes, i suppose theoretically an attack could somehow cure ageing and enslave you for a billion years, but i don't think such tail risks are above the noise floor of any calculation) <xentrac>but it isn't a user that makes these decisions; it's the developers, collectively <Hagfish>yeah, the user can't afford to trust the claims a developer makes about their software <Hagfish>unless the developer is offering a warranty, backed by a good enough insurance policy <xentrac>anyway, I think what you're talking about is making execution deterministic, and that's real security, not the kind of "raise the cost of the attack" stuff you were describing <xentrac>similarly with running code without access to the network or the filesystem <Hagfish>removing non-determinism doesn't make software secure <fossy>probably a cross-kernel checksum issue? however that will not be a problem shortly <xentrac>it makes it secure against containing certain kinds of malware <Hagfish>xentrac: yeah, having formal proofs of a program's properties is valuable <stikonas>I'm trying to debug my hex1 label offset calculation... <stikonas>mostly working but there is a small problem with risc-v I-type jumps <xentrac>what's the problem with the jumps, stikonas? <stikonas>xentrac: actually on second though there isn't any problem. I think the difference is because I still have to implement other thing pointers (with & symbol) <stikonas>just noticed that only those labels that point to pointers were incorrect <stikonas>that's just something I haven't implemented yet <stikonas>minus all the irrelevant bits, that we don't need <stikonas>hmm, maybe we don't really need them though <stikonas>but that means we can implement them in hex2 <stikonas>which means I just need to do hex encoding of my current code <stikonas>should be able to do it withing a week before I become busier with other stuff for some time <stikonas>it's about 500 lines of assembly though... <stikonas>but at leas it's the last piece of risc-v code where manual jumps have to be calculated <stikonas>oriansj: I think there might be some problems with label calculation in hex2 when . are used <stikonas>I was trying to see why M1 files don't build into binaries, but can't see anything bad with M1 itself <oriansj>stikonas: the point of range check is just to do a basic sanity check on the input to make catching certain bugs easier. It doesn't need to be implemented in hex1 or hex2 but it is probably the correct idea in the C version of hex2 (unless I have missed something completely obvious) <oriansj>and WordStorePointer will only need to be done for hex2 as the %label1>label2 will absolutely be needed for generating ELF sizes <oriansj>Hagfish: the big problem with exceeding the cost to benefit ratio is the massive value in targetted attacks. For example there are 8 people in google which if compromised would enable an attacker to compromise everyone who is using a google product. There are 4 people at Intel if compromised will result in compromise of *ALL* customers of Intel. <oriansj>That it why I *DO NOT* want anyone to trust me or any code I release. To reduce the benefit from compromising me. <oriansj>Why I recommend that all code written needs to be done with the auditor in mind. Make it as easy as possible for someone to catch any possible compromise or to simply classify any confusing code as evil. <xentrac>right, that's what I was saying about how developers don't know how valuable their users' assets are <gforce_de1977>stikonas: thanks for your input, i will revalidate with a 64 bit build, if the perl-hash-problem persists and report <fossy>i think overall our new winner in long term for "random stupid things that take a long time" is going to be gnulib-tool <vancz>is there documentation for what the various bootstrap tools like hex take as input? <stikonas>basically hex0 just strips out comments and encodes ASCII hex characters into binary equivalent, it's basically a well commented machine code <stikonas>hex2 also supports assembly labels and can calculate jumps, so instead of encoding jump 10 instructions forward, source can contain jump to certain label <stikonas>vancz: hex1 is slightly simplified version of hex2, it only supports single character label (and I think it does not support absolute pointers), so only relative jumps are supported <stikonas>all of these are rough guide, might be tweaked a bit depending on what are the requirements for that specific architecture <stikonas>and finally M1 takes assembly language as an input, although it's a special dialect that is easy to parse <stikonas>it's not NASM or GAS syntax but is essentially the same thing content-wise <stikonas>(modified a bit so that it can be parsed token by token and does not require processing the whole line) <oriansj>vancz: and we actively encourage questions as a way to improve our documentation and onboarding processes. <stikonas>yes, PRs to improve documentation are always welcome <vancz>so the tools dont have anything like man pages yeah? <vancz>is stuff still too in flux for that to be worth the effort? <stikonas>vancz: I think there are some in mescc-tools repo <stikonas>vancz: and this is C version of hex2 which is built a bit later <stikonas>like I said, assembly versions are a bit arch specific <stikonas>vancz: there is also a bit of a case that some tools are only use once or at most a few times... <stikonas>so sometimes it's better to look at the example <stikonas>e.g. to see what hex1 accepts as input, you can look at hex2.hex1 file <stikonas>vancz: also if you are interested in those low level tools, high-level prototypes are a good place to look ***pgreco_ is now known as pgreco
<stikonas>hmm, I think even after my yesterdays fix hex2 might now be dealing with . correctly... Need to think about them more carefully...