Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=10&d=17

Sunday, 17 October 2021

05:19:00 <klange> sortie: https://github.com/klange/toaruos/blob/master/lib/jpeg.c
05:19:00 <klange> rb: ^
05:21:00 <klange> tl;dr: I read a Python implementation and rewrote it in C
05:22:00 <wleslie> nice
05:25:00 <Mondenkind> that is a _weird_ bswap :P
05:28:00 <wleslie> could be (val >> 8) | (val << 8)
05:30:00 <Mondenkind> also why lut for cos?
05:31:00 <klange> It's not a lookup table for cosine. It's the eight discrete cosine transforms JPG uses.
05:34:00 <kingoffrance> i always thought swap was: a^=b; b^=a; a^=b; but that was mainly if you dont want to use another variable -- i would not trust it to be "fast"
05:35:00 <kingoffrance> i would trust anything else is "faster"
05:35:00 <kingoffrance> so that does not bother me
05:35:00 <klange> I'm reasonably certain gcc at least is 'aware' of xorswapping and will likely shit out whatever it feels like anyway.
05:36:00 <kingoffrance> :)
08:30:00 <rb> klange: thanks for the hint! if i get stuck on something with the spec, i'll take a look.
09:20:00 <Mondenkind> huh, what's the difference between .data and .data1?
09:20:00 <vdamewood> One has a 1
09:20:00 <Ermine> Hello, is aarch64 backward compatible with arm?
09:20:00 <j`ey> Ermine: no
09:20:00 <Mondenkind> vdamewood: yea but...
09:21:00 <vdamewood> Ermine: Do you mean backwards compatible with aarch32?
09:22:00 <zid> most of the chips are, the isa is not
09:23:00 <j`ey> the chips are because the architecture has optional 32-bit support too
09:23:00 <j`ey> some chips have dont have that support
09:23:00 <clever> some have wonky support, like aarch64 only in EL1 but both 32+64 in EL0
09:23:00 <Ermine> vdamewood: Yes
09:24:00 <vdamewood> For example, I think the M1 is aarch64 only.
09:24:00 <vdamewood> But I think all Snapdragons support aarch32, even teh 64-bit ones.
09:25:00 <clever> https://i.imgur.com/JBx0Rtg.png is a screenshot from an arm64 manual
09:25:00 <Ermine> My previous phone has 32-bit android, despite chip was aarch64
09:26:00 <clever> if EL3 is in aarch64 mode, then the secure EL2 must also be aarch64, and the non-secure EL2 can be aarch64 or aarch32
09:26:00 <clever> any lower modes, must be of the same or smaller width
09:26:00 <clever> so if the non-secure EL2 is aarch32, then everything below (EL1 + EL0) must also be aarch32
09:27:00 <Ermine> Well then, if I write assembly for aarch32, will it remain valid for aarch64?
09:28:00 <clever> Ermine: in think at the textual form, you have to deal with r0 vs x0 for all register names, so you need to at least run sed over things, if you want to assemble it into aarch64 mode
09:28:00 <clever> i dont think its compatible in the binary form
09:28:00 <zid> if it were, they'd be the same isa
09:28:00 <clever> but depending on the chip, you can ask a higher power to run your code in aarch32 mode
09:29:00 <clever> Ermine: so the question is, what EL is the code running in, and do you want to run it in aarch32 mode or not?
09:31:00 <j`ey> clever: "like aarch64 only in EL1 but both 32+64 in EL0" isnt wonky, it makes sense!
09:32:00 <zid> I've not ran x86 as ring0 outside of grub in a very very very long time
09:32:00 <clever> j`ey: yeah, it does make sense from a hw view, no need to support all of those 32bit variants of every control register
09:32:00 <j`ey> Ermine: 32-bit support in aarch64 is optional
09:32:00 <zid> if it booted straight 64bit I'd literally not need 32bit control regs ever
09:32:00 <clever> zid: exactly
09:33:00 <clever> but from somebody that doesnt think about hw design, it can seem more wonky
09:33:00 <clever> also with x86 and arm dealing with bit width changes in different manners
09:34:00 <Ermine> clever: this is el0 for now. I'm attending a course on systems programming and we are taught arm assembly, so I want to practice using this assembly. So I tried to set up an arm qemu vm. But alpine linux for arm fails to boot, while its aarch64 version boots successfully
09:34:00 <j`ey> you can probably run a 32-bit program then
09:35:00 <j`ey> just try it!
09:35:00 <clever> Ermine: if you tell your toolchain to generate a static aarch32 elf binary, then you can just ignore 64bit support, even on a 64bit kernel
09:35:00 <clever> as long as the cpu has 32bit EL0 support, and its enabled in the kernel
09:35:00 <j`ey> which is very likely for the alpine kernel
09:41:00 <geist> not compatible
09:42:00 <Ermine> Okay, thank you guys!
09:42:00 <geist> Arm64 is similar, but not the same isa and not particularly ISA]]
09:42:00 <geist> N]
09:42:00 <geist> Er not particularly compatible at the instruction syntax
09:42:00 <geist> Just similar
09:43:00 <geist> Just go
09:44:00 <geist> Er damnit having trouble typing tonight
09:54:00 <zid> someone put fresh batteries in geist
09:55:00 <geist> Heh its an unfamiliar unlit keyboard that’s getting me
09:58:00 <zid> I just got a new keyboard, I type /better/ on it because my last one was so trash :p
11:17:00 <sortie> Subtle potentially-corrupting bug in my kernel: pipe(2) allocates two file descriptors, one after each other, but each step may fail. If the first succeeded and the second failed, the first is close(2)'d.
11:18:00 <zid> would that actually corruption or just cause EBADFD?
11:18:00 <sortie> Sounds good? Unfortunately the overall operation is not atomic. Another thread in user-space could've done something to the first file descriptor (closed it and replaced it with something else)
11:19:00 <sortie> This doesn't even need to be too explicitly evil, could even a closefrom(2) call (although that's super rude in a threaded process)
11:20:00 <sortie> It doesn't corrupt the kernel but it could technically do unexpected things to the file descriptor table in the process. Totally the process's own fault.
11:20:00 <zid> It's hard to make a judgement on things like this, whether it's "don't do that" or "I should stop people doing that"
11:20:00 <sortie> I'm not a fan though of closing a file descriptor in the kernel that could not unexpectedly point to something else
11:21:00 <sortie> The thing is that it's trusted piece of code overseeing untrusted code and cases like this could potentially be used to trick it into doing things it isn't meaning to
11:22:00 <sortie> The solution in this case is to have the kernel preallocate file descriptor table entries, so there isn't any error cases where it has to roll back like this in the end
11:23:00 <sortie> In cases like this I worry that there's a way I didn't think of where these cleaning up error paths can be used to trick the kernel into doing something it's not supposed to
11:25:00 <sortie> Another similar case would be e.g. if the kernel happens to copy the same memory from user-space multiple times, but the memory changes midway by another thread, and the initial assessment is now wrong and leads to a wrong outcome (whereby the kernel does something it's not supposed to)
11:26:00 <sortie> Ordinarily I have a policy of only reading the same memory from user-space once for that reason, also the right choice for efficiency and just what good coding leads to.
11:27:00 <sortie> Though in my Unix socket file descriptor passing code, when I read the msg_control data, I actually have to pre-read it to know how much kernel buffer space I need (depends on the control data, e.g. an int for a file descriptor requires a matching kernel uintptr_t in the buffer), which is done before the socket is locked, and then then it waits for the buffer space and does the operation reading the control data again
11:29:00 <sortie> In that case, I very explicitly designed it such that if user-space fucks with the control data buffer midway, it gets a consistent if unexpected result such as truncating it, but the kernel remains fully consistent
14:04:00 <sortie> klange, spotted a couple bugs in the jpeg implementation, interesting to read some of it, much smaller than I'd have thought
14:04:00 <sortie> https://github.com/klange/toaruos/blob/master/lib/jpeg.c#L120 ← & 0xF, but that's 16, and quant has 8 entries.
14:05:00 <sortie> https://github.com/klange/toaruos/blob/master/lib/jpeg.c#L168 ←That should be i >= 3, rather than i > 3, as quant_mapping has 3 entries and quant_mapping[3] would be a buffer overrun
14:07:00 <zid> baseline_dct.. if that fread fails you're in trouble
14:07:00 <zid> it's immediately followed by a malloc multiply w*h which are read from the file, or uninitalized buffer, depending
14:08:00 <zid> maybe length was checked to be >7 beforehand though
14:09:00 <sortie> I mean it depends on what they're trying to do. This is written in a casual style kind of code and yeah it isn't that defensive against malicious inputs. But this is also part of a huge project to rewrite all the third party stuff so totally makes sense to just get stuff working
14:09:00 <zid> fair
14:09:00 <zid> I'm pretty anal about this stuff these days even on a first draft
14:10:00 <froggey> write it in a language that traps buffer overflows, problem solved
14:10:00 <sortie> I am too. It's much more work in the long run to adapt code to be defensive and secure, but it's a trade off with more work in the short term.
14:10:00 <sortie> I mean my OS stuff has become super cautious in everything new I do and it's also totally stalled me for years
14:11:00 <sortie> Back in the day I'd just have shipped stuff years ago but these days I spend so much time on every god darn edge case
14:12:00 <zid> I don't go super all in on the error code being nice, I just want it to be there
14:13:00 <sortie> Honestly it's because it's pretty darn frightening to actually put my OS in production on the actual internet for my own purposes and so scared of being hacked
14:13:00 <sortie> I have an endless backlog of local priv escalation vulns but at least I do my very best not to have any remote ones
14:16:00 <sortie> In any case, I totally love all this NIHing of things like image decoders and fonts. I totally want to learn more about that stuff myself
14:16:00 <zid> yea I like NIHing
14:16:00 <zid> Add extra exploits and call it a training Os for exploit dev
23:52:00 <sdfgsdfgs> I want to understand the initialization of OS and how memory space is setup according to instructionset etc, whers a good place to start ?