rpnx has quit [Quit: My laptop has gone to sleep.]
<zid>
day4 was mainly about figuring out how little processing you can actually get away with doing, I used a very dumb incremental approach where I went 250ms -> 1ms -> microseconds
<zid>
as I realized less and less of the code was actually needed
virt has quit [Ping timeout: 255 seconds]
rpnx has joined #osdev
* blockhead
never uses i and j for variables as they look too much alike
<blockhead>
zid: just woke up and saw your link. checking now...
<zid>
j has a hanger though!
<blockhead>
i recognize the "idiot" part :)
<blockhead>
it compiles with tcc as well as cc. nice
<zid>
That's more about whether your compiler can compile C or not
<zid>
I don't write non-C unless it's very obviously using gcc attributes
pretty_dumm_guy has quit [Ping timeout: 264 seconds]
<zid>
to achieve some platform specific behavior
vivihexe has left #osdev [#osdev]
<blockhead>
no two compilers are alike. some things gcc never notices get picked up by tcc, like subroutines that don't return a value at the end
<zid>
gcc notices that very very well
<zid>
it often over-warns on it infact
<blockhead>
not here
<blockhead>
and totally goes over gcc's head
<zid>
'not here' -> you didn't enable -Wall or optimizations
* blockhead
keeps it simple: cc -o proggy proggy.c
<zid>
yea, never ever do that with gcc
<blockhead>
-l as needed
<zid>
it produces useless code that it hasn't checked for correctness
rpnx has quit [Quit: My laptop has gone to sleep.]
<blockhead>
which would explain why you get the (no) return values warnings and i don't. i see
<zid>
gcc is *very* clever
<blockhead>
i sit corrected :)
<zid>
but only part of various optimization passes will it obtain the information to tell you about a lot of the things it can find out
<zid>
(also generates code that you might actually want to run, too)
rpnx has joined #osdev
rpnx has quit [Quit: My laptop has gone to sleep.]
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 246 seconds]
rpnx has joined #osdev
<geist>
indeed. for probably historical reasons gcc defaults to very very basic options. not very good optimization (though i think that may be configured by triple?) and almost no warnings
<mjg>
it warns now by default
<zid>
It's also like, computationally expensive
<mjg>
a lot more than it used to anyway
<zid>
that's why diagnostics is tied to optimization in the first place, gcc does not *do* the passes that would find out the problem
<geist>
well, sure i mean it warns, but it only warns about really basic stuff
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<zid>
I just p++; the entire string, strcmping one/two/three/four
<zid>
final match wins, done
<zid>
I never even found out the strings overlapped until reddit told me
<heat>
I don't think mine is that much worse
<heat>
you're just not familiar with it (neither am I)
<heat>
granted the code is probably not... rustonic? rusty?
mkwrz has joined #osdev
<heat>
because i don't know what I'm doing
<zid>
rustonic -> cthonic
<zid>
chthonic
<Mutabah>
heat: "rustic"
<Mutabah>
cthonic is some of the unsafe code I write
<Mutabah>
Seen the UDI rust bindings I was owkring?
<Mutabah>
*I was working on
<heat>
no
<kazinsal>
seeing the acronym UDI in this channel is a blast from the past
<heat>
I don't really know rust
<Mutabah>
Converted rust async into UDI calls, with a massive pile of hacks under the hood
<heat>
rust async tokio serdes upvotes left
<Mutabah>
kazinsal: Reading the docs was a blast from the past. I did find that USB-IF had some draft bindings
<kazinsal>
I just remember the days of L4B building AMD64 ABIs for it as a labour of love and unfortunately getting nowhere because GNU tanked the effort of the whole UDI plan
<kazinsal>
the good ol' days
mkwrz has quit [Ping timeout: 268 seconds]
<heat>
hot take: UDI was kind of a crap idea to begin with
<Mutabah>
Despite having spent far too long over the last month fiddling with it... I half agree
<Mutabah>
Device interfaces are just a little too complex to capture in such a spec.
<kazinsal>
the one networking/osdev hackery wish I have is that broadcom would open up their 1/2.5/5/10GBASE-T switching
<kazinsal>
"whitebox" switching has for the past five years been really just "choose between three linux-based OSes with binary blobs for the switching"
<heat>
my one osdev hackery wish I have is that broadcom would blow the fuck up seriously what the fuck kind of cursed hardware do they make the fuck up
<kazinsal>
their switching ASICs are phenomenal
<kazinsal>
it's their cheapest level of dogshit PCI ethernet cards that are dodgy
* mjg
sticks to his trusty ne2000
<mjg>
fuck the haters
<kazinsal>
had some good luck with their 25GbE
<heat>
rtl8139?
<Mutabah>
8139 ftw
<Mutabah>
although curse that random 0x10 byte offset
<kazinsal>
8139 is the realtek equivalent of the e1000
<kazinsal>
reuse 90% of your code with the remaining 10% being a bunch of if statements for various model edge cases
<Mutabah>
Pretty much.
<heat>
but the 8139 is objectively a crap NIC
<heat>
the e1000 is pretty solid
<Mutabah>
e1000 is nicer than 8139 due to being a little newer, but damn the 8139 was common
mkwrz has quit [Ping timeout: 268 seconds]
<heat>
the 8168 i have is really similar to the e1000 in the base design
<kazinsal>
at some point once I get around to redoing my kernel core I'm going to do an XL710/E810 driver
<zid>
I don't think my part 2 is going to finish running
<heat>
ring buffer of rx descs, ring buffer of tx descs, ezpz
<zid>
unless I write a range checker instead of this for loop
<kazinsal>
get that sweet 200GbE going
<heat>
i'm not sure how the really big really fast NICs work
<heat>
but for 1GbE and shit? yeah, ring bufferz of descs
<kazinsal>
enormous amount of offload
<kazinsal>
and dozens of MSI-X interrupts
<kazinsal>
it's almost entirely built around making sure you can spread all you need around as many CPUs as possible and let the other side's offload reorder shit
<heat>
i don't think i've bothered to implement TSO and GSO yet
<heat>
i do have csum offloading tho
<zid>
You have completed Day 5!
<zid>
real 3m59.506s
<zid>
oopsie?
heat has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 255 seconds]
mkwrz has joined #osdev
mkwrz has quit [Ping timeout: 256 seconds]
<zid>
scary, thought my monitor had finally totally died
<zid>
turns out it just forgot the latch status of the power button
<zid>
so unplugging it and plugging it back in did nothing, had to turn it off then on
<netbsduser>
interesting to hear about the great revival of UDI
<netbsduser>
i was feeling like being interoperable one day so i looked at it, left it alone, and implemented a shim for windows storport drivers instead
mkwrz has quit [Ping timeout: 276 seconds]
roper has joined #osdev
srjek has quit [Ping timeout: 268 seconds]
mkwrz has joined #osdev
mkwrz has quit [Ping timeout: 245 seconds]
zetef has quit [Ping timeout: 264 seconds]
kof123 has joined #osdev
mkwrz has joined #osdev
mkwrz has quit [Ping timeout: 240 seconds]
mkwrz has joined #osdev
mkwrz has quit [Ping timeout: 260 seconds]
mkwrz has joined #osdev
foudfou has joined #osdev
mkwrz has quit [Ping timeout: 256 seconds]
<moon-child>
udi revival?
<zid>
universal derial is
<netbsduser>
moon-child: apparently so
<netbsduser>
now the RUST language has a binding for it seemingly
<Mutabah>
Nah, I just got bored and decided to try it out
joe9 has quit [Quit: leaving]
zid` has joined #osdev
<zid`>
Stupid internet, I blame the series of tubes
zid has quit [Ping timeout: 246 seconds]
zid` is now known as zid
srjek has joined #osdev
bradd has quit [Ping timeout: 260 seconds]
mkwrz has joined #osdev
sbalmos has joined #osdev
Turn_Left has quit [Ping timeout: 268 seconds]
Turn_Left has joined #osdev
Turn_Left has quit [Max SendQ exceeded]
Turn_Left has joined #osdev
<Ermine>
udi?
<zid>
It's what it's called when it hurts when you pee
zid has quit [Read error: Connection reset by peer]
<netbsduser>
geist: rust bindings have been created to it
<geist>
oh well there you go!
<geist>
it's official!
<netbsduser>
i remember there being a prior initiative for its revival a while ago but it got dragged down into this ridiculous argument to make the drivers bytecode
<netbsduser>
which was in any case irrelevant as the bytecode advocate didn't lift a finger to try to realise his vision
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
<geist>
yeah, i've been hearing about UDI for what seems like at least 20 years
<virt>
coming from c# and windows, how difficult would it be to learn xcode? It seems a lot more complicated at first glance.
zxrom_ has joined #osdev
zxrom has quit [Ping timeout: 260 seconds]
zxrom_ is now known as zxrom
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
xenos1984 has quit [Ping timeout: 256 seconds]
bleb has quit [Ping timeout: 256 seconds]
bleb has joined #osdev
xenos1984 has joined #osdev
bauen1 has joined #osdev
benlyn has joined #osdev
pebble has quit []
wereii_ is now known as wereii
virt has quit [Quit: bye <3]
node1 has quit [Quit: Client closed]
joe9 has joined #osdev
Starfoxxes has joined #osdev
srjek has quit [Ping timeout: 255 seconds]
node1 has joined #osdev
<node1>
When someone say "Microcode" what does it mean?
<bl4ckb0ne>
its code you need a microscope to look at
<gorgonical>
I normally hear about this in the context of shit like "a microcode patch to fix a vulnerability"
<gorgonical>
So to me that's the code that the IME runs on
<zid>
I made my day 5 code a bunch faster with CLEVER HAX
<node1>
How about Trusted Execution Environment (TEE)
<zid>
It now runs in 3 minutes instead of 4 minutes :(
<gorgonical>
a tee is a separate, parallel software stack
heat has joined #osdev
<heat>
gorgonical: the IME does NOT run on microcode
<zid>
what's an IME
<gorgonical>
heat: That's why I said "to me"
<gorgonical>
I'm not an authority
<zid>
other than input method editor
<heat>
the ME runs on a separate coprocessor
<heat>
486-like
<zid>
oh, the ME
<gorgonical>
sorry, wasn't sure whether we called it the intel ME or the IME
<zid>
yea, ME runs either on your cpu if it's old, a seperate CPU if it's mid, and internal silicon if it's new
<node1>
How about Trusted Execution Environment (TEE) ??
<zid>
I've had all three now
<gorgonical>
node1: A TEE is a separate software stack that you cordon off to be more secure
<gorgonical>
It almost always runs with extra hardware security enforcement in place to ensure this
<node1>
when you say separate software stack means?
<gorgonical>
a parallel kernel and userspace
<gorgonical>
living somewhere else in the address space, sometimes even in physically separated memory
<heat>
yeah thats the ME as well
<heat>
separate CPU, separate memory, with a kernel and userspace
<gorgonical>
If it's purpose is to do "secure computing" work on a machine then it could be characterized as a TEE, sure
<gorgonical>
That usually implies that *you* can issue work to it, but I don't think it's necessary
<node1>
When someone mentions the 'Trusted Computing Base,' they are typically referring to all the security components, including hardware, software, and firmware, that are integral to the system's security.
<node1>
???
<heat>
gorgonical: anyway to be clear, the ME is a completely motonous piece of software that does, erm, management
<heat>
the vulns have nothing to do with the ME
<gorgonical>
broadly yes, but sometimes TCB refers only to the software, with the implicit assumption that the hardware is "secure enough"
<heat>
*usually*
<heat>
monotonous*
<gorgonical>
heat: thank you for the clarification
<zid>
heat, day2, stat
<node1>
gorgonical thanks, but still i am unable to visualize TEE
<gorgonical>
node1: that figure is a reasonable architectural diagram
<gorgonical>
I can't link you the ones in my paper because they aren't hosted lol
<heat>
hehe littlekernal go brrrrrrr
<gorgonical>
op-tee's not lk-based I don't think
<gorgonical>
though nvidia has used lk before
<heat>
trusty is
<gorgonical>
they call it "trusted little kernel" so that way you know its secure
<gorgonical>
node1: one way to think of the TEE is analogously to processes. You *could* just run all your code in the same address space and trust that the software is correct. This is a bad idae, so we invent hardware mechanisms that enforce separation between processes, all managed by the kernel. A TEE is like doing this same thing but at the kernel/OS layer
<gorgonical>
And for basically the same reasons. If it were trivial to determine if software were correct we would basically not need any hardware help. If you could just press "check for bugs" in your editor and it said "yep no bugs" then everything would be much simpler
<node1>
And what it execute in this space???
<gorgonical>
node1: whatever you like: kitten, linux, andix, littlekernel, raw ASM
<heat>
softwear
<node1>
ok
<gorgonical>
the "traditional" use of the TEE is do to things like identity/key management or DRM enforcement
<gorgonical>
but you can run whatever. Ultimately it's just another processor mode. Technically in ARM you have to explicitly turn OFF security at the firmware level. You start up by default in secure mode
<node1>
Also what ths Application Binary Interface ?
<node1>
well i think It's not related to programming rather then how to design programming languages
<heat>
why do you come here asking for definitions?
<heat>
we're not a dictionary mate
<Ermine>
Does nvidia drop their hw to geist?
<heat>
geist gpu plox
<heat>
thank
<node1>
that should adhere to some specific rules how these applications runs on target OS
<node1>
What's your thought?
<zid>
no, he has an A750 :D
<zid>
My nvidia friend said they had a like, internal store, at cheapish prices
<zid>
but he never got like, free gpus
<zid>
unless it had 'wires coming out of it'
Turn_Left has quit [Ping timeout: 259 seconds]
kfv has joined #osdev
<kof123>
node1: i have a hypothetical, language, any language, that compiles down to asm. how are arguments passed to a "function" ? what if i want to call that function like a library, from another program? how is all this going to be coordinated for 10,000 programs that other people write and want to do the same?
<heat>
>buy gpus at cheap prices on the internal store
<heat>
>resell gpus at a huge markup
<heat>
>$$$
<heat>
>get fired
<zid>
If they have any
<kof123>
ibm did give a discount on like refurbished stuff, maybe mcro d should go there for that :D
<gorgonical>
It would be pretty cool to have a newer POWER workstation
<gorgonical>
IBM must have some of those kicking around internally somewhere
dude12312414 has joined #osdev
<geist>
haha nvidia give me anything? haha
<gorgonical>
you're telling me they aren't giving you a Grace(TM) Hopper(TM) Superchip(TM)(R) for free, geist???
<geist>
:(
<gorgonical>
I went to SC and I swear nvidia has outfitted reps with shock collars to make sure they say that superchip part
<Ermine>
Boo bad nvidia!!!!!!!
<zid>
nvidia events should have goodie bags with 4090s in
<zid>
I need something to play gta6 with when it comes out afterall
gbowne1 has joined #osdev
node1 has quit [Quit: Client closed]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
<heat>
geist: im well aware nvidia aren't giving you anything, i just want you to buy me a GPU
<heat>
can you do that? thanks <3
Turn_Left has joined #osdev
eddof13 has joined #osdev
Turn_Left has quit [Max SendQ exceeded]
Turn_Left has joined #osdev
<netbsduser>
kof123: the solution to your problem is to define a convention for calling
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
eddof13 has joined #osdev
<kof123>
yes, node_one asked what an ABI was :D > Arguably the biggest and most important part of an ABI is the procedure call standard sometimes known as the "calling convention"
<heat>
the most important part of the 386 sysv abi is the X11 interfaces
<bslsk05>
libera.irclog.whitequark.org: #osdev on 2023-11-19 — irc logs at libera.irclog.whitequark.org
* CompanionCube
wonders how you would fill that hole in the log
zetef has joined #osdev
[_] has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
[itchyjunk] has quit [Ping timeout: 268 seconds]
zetef_ has joined #osdev
zetef has quit [Ping timeout: 256 seconds]
netbsduser has joined #osdev
roper has quit [Quit: leaving]
PapaFrog has quit [Ping timeout: 264 seconds]
PapaFrog has joined #osdev
danilogondolfo has quit [Quit: Leaving]
heat has quit [Quit: Client closed]
srjek has joined #osdev
zetef_ has quit [Ping timeout: 246 seconds]
rpnx has joined #osdev
rpnx has quit [Client Quit]
valshaped7424880 has joined #osdev
sortie has quit [Quit: Leaving]
sortie has joined #osdev
joe9 has quit [Quit: leaving]
netbsduser has quit [Ping timeout: 256 seconds]
joe9 has joined #osdev
<immibis>
the main purpose of a trusted computing base is to make sure you don't own the hardware you bought
<immibis>
otherwise you'd make it a process or a kernel module
<immibis>
even the OS kernel isn't allowed to mess with the TCB
<immibis>
so they put all the DRM and backdoor stuff there
<clever>
yeah, the kernel needs to lock down the datapath from the decryption program to the gpu
<clever>
so you need to prevent a debugger from attaching to things like the video player and X server
<clever>
you need to prevent any modifications of the kernel (sign the kernel and modules) so the kernel cant be used to sniff things
<clever>
and also to protect the keys
Turn_Left has quit [Ping timeout: 256 seconds]
<clever>
immibis: i can picture ways to allow partial kernel changes, lets say there is a trusted kernel in EL3, and if the EL1 kernel is signed, it gets the keys, but if EL1 is unsigned, it still runs, but lacks key access
<clever>
that would give the user partial control over the device, and the ability to run any kernel they want, the keys for DRM would just not be accessible
<clever>
until they restore the "authorized" kernel