<klange>
tl;dr: I read a Python implementation and rewrote it in C
<wleslie>
nice
<Mondenkind>
that is a _weird_ bswap :P
[itchyjunk] has quit [Read error: Connection reset by peer]
<wleslie>
could be (val >> 8) | (val << 8)
<Mondenkind>
also why lut for cos?
<klange>
It's not a lookup table for cosine. It's the eight discrete cosine transforms JPG uses.
<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"
<kingoffrance>
i would trust anything else is "faster"
<kingoffrance>
so that does not bother me
<klange>
I'm reasonably certain gcc at least is 'aware' of xorswapping and will likely shit out whatever it feels like anyway.
<kingoffrance>
:)
h4zel has quit [Ping timeout: 268 seconds]
m3a has joined #osdev
guodong has quit [Quit: WeeChat 3.3]
guodong_ is now known as guodong
guodong is now known as guodong000
guodong000 has quit []
C-Man has quit [Ping timeout: 265 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
GeDaMo has joined #osdev
<rb>
klange: thanks for the hint! if i get stuck on something with the spec, i'll take a look.
<Ermine>
My previous phone has 32-bit android, despite chip was aarch64
<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
mahmutov has quit [Remote host closed the connection]
<clever>
any lower modes, must be of the same or smaller width
<clever>
so if the non-secure EL2 is aarch32, then everything below (EL1 + EL0) must also be aarch32
mahmutov has joined #osdev
<Ermine>
Well then, if I write assembly for aarch32, will it remain valid for aarch64?
<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
biblio has joined #osdev
<clever>
i dont think its compatible in the binary form
<zid>
if it were, they'd be the same isa
<clever>
but depending on the chip, you can ask a higher power to run your code in aarch32 mode
<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?
<j`ey>
clever: "like aarch64 only in EL1 but both 32+64 in EL0" isnt wonky, it makes sense!
<zid>
I've not ran x86 as ring0 outside of grub in a very very very long time
<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
<j`ey>
Ermine: 32-bit support in aarch64 is optional
<zid>
if it booted straight 64bit I'd literally not need 32bit control regs ever
<clever>
zid: exactly
<clever>
but from somebody that doesnt think about hw design, it can seem more wonky
<clever>
also with x86 and arm dealing with bit width changes in different manners
<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
<j`ey>
you can probably run a 32-bit program then
<j`ey>
just try it!
<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
<clever>
as long as the cpu has 32bit EL0 support, and its enabled in the kernel
<j`ey>
which is very likely for the alpine kernel
<geist>
not compatible
<Ermine>
Okay, thank you guys!
<geist>
Arm64 is similar, but not the same isa and not particularly ISA]]
<geist>
N]
<geist>
Er not particularly compatible at the instruction syntax
<geist>
Just similar
<geist>
Just go
<geist>
Er damnit having trouble typing tonight
<zid>
someone put fresh batteries in geist
<geist>
Heh its an unfamiliar unlit keyboard that’s getting me
<zid>
I just got a new keyboard, I type /better/ on it because my last one was so trash :p
Oli has joined #osdev
mctpyt has quit [Ping timeout: 265 seconds]
Kerum has joined #osdev
dbana has joined #osdev
dbana has quit [Read error: Connection reset by peer]
<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.
zacque has joined #osdev
<zid>
would that actually corruption or just cause EBADFD?
<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)
<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)
<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.
<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"
<sortie>
I'm not a fan though of closing a file descriptor in the kernel that could not unexpectedly point to something else
<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
<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
<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
<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)
<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.
<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
<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
pretty_dumm_guy has joined #osdev
m3a has quit [Quit: leaving]
mahmutov has quit [Ping timeout: 264 seconds]
ElectronApps has quit [Remote host closed the connection]
nyah has joined #osdev
srjek has joined #osdev
C-Man has joined #osdev
immibis has joined #osdev
gog has joined #osdev
wleslie has quit [Quit: ~~~ Crash in JIT!]
Kerum has quit [Ping timeout: 265 seconds]
sonny has joined #osdev
sonny has left #osdev [#osdev]
ElectronApps has joined #osdev
isaacwoods has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
mahmutov has joined #osdev
alexander has joined #osdev
biblio has quit [Quit: Leaving]
<sortie>
klange, spotted a couple bugs in the jpeg implementation, interesting to read some of it, much smaller than I'd have thought
<zid>
baseline_dct.. if that fread fails you're in trouble
<zid>
it's immediately followed by a malloc multiply w*h which are read from the file, or uninitalized buffer, depending
<zid>
maybe length was checked to be >7 beforehand though
<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
<zid>
fair
<zid>
I'm pretty anal about this stuff these days even on a first draft
<froggey>
write it in a language that traps buffer overflows, problem solved
<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.
<sortie>
I mean my OS stuff has become super cautious in everything new I do and it's also totally stalled me for years
<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
<zid>
I don't go super all in on the error code being nice, I just want it to be there
<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
<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
[itchyjunk] has joined #osdev
<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
<zid>
yea I like NIHing
<zid>
Add extra exploits and call it a training Os for exploit dev
ElectronApps has quit [Remote host closed the connection]
MiningMarsh has quit [Ping timeout: 268 seconds]
MiningMarsh has joined #osdev
zacque has quit [Quit: Goodbye :D]
isaacwoods has quit [Ping timeout: 260 seconds]
dude12312414 has joined #osdev
isaacwoods has joined #osdev
h4zel has joined #osdev
h4zel has quit [Ping timeout: 260 seconds]
h4zel has joined #osdev
mniip has quit [Ping timeout: 624 seconds]
h4zel has quit [Ping timeout: 268 seconds]
mniip has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
dormito10 is now known as dormito
h4zel has joined #osdev
h4zel has quit [Ping timeout: 245 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rorx has quit [Ping timeout: 245 seconds]
h4zel has joined #osdev
GeDaMo has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
h4zel has quit [Quit: WeeChat 3.0.1]
_eryjus has quit [Remote host closed the connection]
eryjus has joined #osdev
mahmutov has quit [Ping timeout: 245 seconds]
mahmutov has joined #osdev
mctpyt has joined #osdev
rorx has joined #osdev
rorx_ has joined #osdev
rorx has quit [Ping timeout: 260 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
rorx_ is now known as rorx
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
janemba has quit [Ping timeout: 264 seconds]
dormito has quit [Ping timeout: 265 seconds]
mahmutov_ has joined #osdev
mahmutov has quit [Ping timeout: 245 seconds]
janemba has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.3]
nyah has quit [Ping timeout: 264 seconds]
mahmutov_ has quit [Ping timeout: 252 seconds]
<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 ?