gog has quit [Read error: Connection reset by peer]
ebrasca has quit [Remote host closed the connection]
mimmy has joined #osdev
<doug16k>
mrvn, intel documents several cases where perf counters miscount. they aren't extremely forthcoming about what happens exactly, but it's probably extra counts from restarting the pipeline after it speculated
smpl has quit [Quit: smpl]
<doug16k>
they list them in the errata
<doug16k>
I have never seen a counter miscount badly though, ever
<doug16k>
their real purpose is sampling, so they expect you have noise in your data anyway
<doug16k>
like NMI into every 10000th dumbass lock cmpxchg across page boundary
<doug16k>
nobody would mind if it was the 10003rd
<doug16k>
or 9993rd
<doug16k>
just getting sparkle of samples at crap code
<doug16k>
think of it more as a crappy event divisor
<doug16k>
that's really close with large number of samples
gog` has quit [Quit: byee]
gog` has joined #osdev
<doug16k>
branch prediction is about 95% right on average, so at most 5% of samples are speculation miscounts
<doug16k>
not samples. the samples would have that 5% miscounts mixed in
<clever>
something else ive heard, is that modern cpu's build a prediction table, per jump source
<doug16k>
better than that. they have a bunch of histories, and it selects which one based on whether the last few branches were taken
<clever>
so if you restructure a `while (true) { switch (foo)` so that `break;` is instead `jump table[foo]`
<clever>
then the cpu can predict it better
<clever>
instead of it being a single `jump table[foo];`, its now many, one per case block
<clever>
and if your running a bytecode interpreter, youve now turned that jump predictor into a bytecode predictor
<doug16k>
let's say you had if (debug) print("stuff"); a bunch of times. if that if is not taken, it will switch to a history where the following instances of that if have a history that says always taken
<doug16k>
s/always taken/always not taken/
<clever>
that sounds like its just building a stat table for that specific conditional
<doug16k>
usually. it's hashy so it might alias
<clever>
it found that the jump has never been takem, so assume it wont be taken next time either
<doug16k>
no
<doug16k>
it switches to an entirely different set of history
<doug16k>
it's for correlation
<clever>
ah, where if debug suddenly is true, it changes out all of its stat tables?
<doug16k>
observations showed that when prior branches aren't taken, it can tell you what the following ones will probably do
<clever>
because it knows that its idea of what is true, has suddenly changed?
<doug16k>
like that if (debug) example
<doug16k>
it's going to be the same taken or not on the following once
<clever>
but, depending on how many args you pass to printf, the pc-relative jump to skip it, will vary in size
<doug16k>
ones. so if that if branch is taken it changes the histories used on following branches. they will end up with that if being the same, taken or not
xhe has joined #osdev
<clever>
and its hard for the cpu to know one `if (debug)` is the same as another
<clever>
enless its tracking the source of the debug var
<doug16k>
so the following ones are taken every time or not taken every time
<doug16k>
and if that first if mispredicts, suddenly the rest of those if debug don;t
<doug16k>
because it switched to the history where those branches always go one way
<clever>
i'm also reminded me a thing linux does, there is a profiling option in gcc, that injects a function call into the prologue of every single function
<clever>
and linux builds the kernel with that
<clever>
but, the cost of jumping to a `if (!debug) return;` function is still costly
<clever>
so linux will dynamically patch the call-sites out with nop's, if profiling is disabled
zaquest has joined #osdev
<clever>
but, to avoid the costly i-flushes and locking the world while editing code, it queues those call-sites up, and does them in batches
<clever>
and that delay, has wound up bricking some NIC's
<clever>
the .init section of a kerne module got unmapped, and then MMIO mapped in its place
<clever>
and the self-editing code, wound up writing to the firmware of the NIC
<clever>
and the NIC was nice enough to translate MMIO writes, into permanent changes to its own flash
<doug16k>
it's not hard to know if it is the same
<doug16k>
cpus spend almost all of their time in loops. almost nothing is straight through
<doug16k>
it learns those patterns in microseconds
<clever>
yeah, bytecode interpreter is a perfect example of that
<doug16k>
the average is something like 16 to 20 instructions between branches, and plenty of those are branching to the start of the loop
<clever>
but if i was to do bytecode stuff, i might look into llvm
<clever>
and just do bytecode -> IR -> native!
<clever>
i think the emu68 project is even dumber, where its just m68k -> aarch64, no optimizer and no middle-man
<clever>
and like you said, it only translates up to the next jump
<clever>
the jump opcode is a function call, that will lookup the next block in a hashtable, and possibly JIT it
wand has quit [Ping timeout: 268 seconds]
<doug16k>
yeah, extracting basic blocks
<doug16k>
I have been meaning to make a toy JIT that does little more than call stuff generated by the compiler
<doug16k>
curious how good or bad it would be
<clever>
emu68 is crazy though
<clever>
all of the JIT performance counters (hit rate, cache size) are exposed to the "guest" in co-processor registers (like what arm has)
<clever>
and the host MMIO, is directly mapped into the guest
<clever>
so its less of a guest, and more of a kernel for the wrong ISA
<clever>
and that leads me to a fun idea
<clever>
could you write an LLVM IR JIT engine, and then compile your kernel to IR, and run that kernel on any cpu?
<doug16k>
a few people here attempted that over the years
<clever>
then you only have to deal with irq handlers, context switching and jit, and the rest is reused without even a recompile
<doug16k>
you have to target each one though. so you do have to recompile. so you might as well use an AOT language
<doug16k>
learn from quakec. they realized it was stupid
<clever>
why do you need to recompile?
tsraoien has quit [Remote host closed the connection]
<doug16k>
bootstrap
tsraoien has joined #osdev
<clever>
yeah, _start is the only part that really needs to be compiled
<clever>
_start, context switching, irq handlers, and the JIT core
<clever>
everything past that can just be reused IR, that runs on any platform, in theory
tsraoien has quit [Client Quit]
tsraoien has joined #osdev
<doug16k>
clever, do you use java?
<doug16k>
why not? :P
<clever>
i have used java in the past
<doug16k>
android right?
<clever>
most recently, for android, but it got translated into dalvik and then the phone further translated it into native
<doug16k>
forced into it kicking and screaming by android
<doug16k>
me too
<clever>
i did use it on pc as well
<clever>
there was a game i played years ago, the entire gui and client engine was something like 20mb of solid minified javascript
<clever>
and it crippled my computer :P
<doug16k>
they dragged me into learning swift, and I wouldn't have touched it with a ten foot pole outside work
<clever>
i RE'd the game engine, and then wrote a java library that could interface with it
<clever>
i then wrote 2 frontends, using SWT i think for the desktop, and android for mobile
<clever>
then i got bored, and made a pixel perfect recreation of one of the gui's in the game
<clever>
right down to one of the textures being 1 pixel short, and not lining up right, lol
tsraoien has quit [Client Quit]
<clever>
complete with pinch zoom
<clever>
one problem the original JS gui had, was the chat pane
tsraoien has joined #osdev
wand has joined #osdev
<clever>
every time somebody speaks, it gets added to the DOM, and the elements just pile up
<doug16k>
I can run a physics simulation on 1000 divs with 50% border radius bouncing off eachother at 165fps. I'm happy with js
<clever>
until you have too many dom elements for your pc to handle
<clever>
i fixed that on android, to the extreme
<clever>
all chat messages go into a sqlite database, which is then rigged into a scroll view in android
<clever>
behind the scenes, android implements scrolling by only having ~10 elements live, when one scrolls off the bottom, it gets reused at the top, and the content is just modified
<clever>
so you dont need 1000 elements eating up ram, only the 10 elements you can see
<doug16k>
it's reflow that makes it hard. if things are absolute they don't create a dependency chain
<clever>
discord kinda does this, where you if you scroll too far, it deletes old messages from the DOM to save ram
<doug16k>
people want quark xpress layout engine and 0 cpu and handle million of boxes
<clever>
in android, the scrolling can only run on a single axis
<clever>
so you just need to know the size of every visible element, which element is at the top, and the offset for that top element
<clever>
and then reflow is easy
<doug16k>
nothing stopping you making a recyclerview
<clever>
it doesnt matter if your in the middle of a 10 million item list
<clever>
recycler view?
<doug16k>
I made one for work. we can have a ridiculous number of notifications
<doug16k>
it only makes enough elements to fit the view and reuses them to make it look like scrolling
<doug16k>
"recycles" them
<clever>
ah yeah
<clever>
thats exactly what android does
<clever>
it both limits how many elements are created, and also avoids GC pressure by reusing, rather then deleting and re-creating
<clever>
also saves any costly init
<doug16k>
yeah. they are obsessed with the GC in java UI code
<clever>
i lost the link, but i also saw a whole presentation on how to make stable framerates in android
<clever>
and it basically boiled down to a few things
<clever>
1: create as little garbage as possible, dont use local vars or heap vars, always use class members
<clever>
2: turn gc off during the actual gameplay, and due to 1, you can survive a whole level without gc
<clever>
then force a gc during a loading screen, when nobody will notice a few lost frames
<clever>
cant remember if there was anything else
<doug16k>
I keep about 165000 notifications in my account at work to hammer it
<doug16k>
try 165000 divs
<doug16k>
it's hopeless
<clever>
i made a 64x64 grid of text inputs one day
<clever>
for messing with the rpi vpu
<clever>
it nearly crippled my computer
<clever>
it came complete with webusb functions to talk to a real rpi, and copy the whole matrix between the html and the real vector core
<clever>
and a way to run a vector opcode remotely
<clever>
that allowed visualizing the effects of the opcode, and changing what i do very easily
* clever
checks notes
<doug16k>
nice
<doug16k>
android dev tools (rightfully) whine about creating resources in paint handlers
<doug16k>
fools creating pens every paint
<clever>
heh
<clever>
do you buy a new pen every time you write a note?
* clever
slaps fools
mimmy has quit [Ping timeout: 276 seconds]
<doug16k>
exactly
<clever>
i cant find my notes now
PapaFrog has joined #osdev
<clever>
but the VPU's matrix registers, one region is reset to 0 on bootup, by the boot rom
LostFrog has quit [Ping timeout: 272 seconds]
<clever>
the rest, they get corrupted if you hold RUN low to reset it
<clever>
i forget what happens if you use a watchdog reboot
<clever>
if the contents are list when you pull RUN low, what could that imply?
<clever>
1: its sram, and the internal rails are killed by that (it did have an internal SMPS), so it looses data
<clever>
2: its dram, and the auto-refreshing was killed
<clever>
which do you think is more likely for a DSP's internal memory?
<doug16k>
something like 90% of dram bits will last over a minute without losing their value, with no refresh
<clever>
that implies that the registers are sram, and the power rail simply died
<doug16k>
but you can expect some bits to go wrong after 100ms though
<clever>
the entire vector bank went random
<doug16k>
that's why ripping out the server dimm attack works. if you are quick you can read the dimm with no errors, with a bit of luck
<doug16k>
if you are slow, you get most of it too
<clever>
i helped a random dude on the rpi forums, with how to do a similar attack on a pi
<doug16k>
that's why they have full system memory encryption. that and reboot attacks
<clever>
yeah, this was more of a reboot attack
<clever>
with a special blob, that doesnt trample as much
<bslsk05>
forums.raspberrypi.com: Attempting to dump SDRAM using Bare Metal OS - Raspberry Pi Forums
<clever>
with this, you can create a bootcode.bin that will init the dram
<clever>
then you just have to swap the SD card on a running pi, whack the RUN pin low for a brief moment, and boom, the dram controller is back online, and you can hexdump anything
xenos1984 has quit [Read error: Connection reset by peer]
<clever>
unlike the official firmware, it can be configured to not write a single byte to dram
<clever>
and to run entirely out of the L2 cache
<clever>
so the attacking binary wont overwrite anything
<clever>
so, your purely down to how long you held RUN, how long the rom takes to load bootcode.bin from SD, and how long that bootcode.bin takes to init the dram
xenos1984 has joined #osdev
<clever>
aha, found my notes
<clever>
it says that a watchdog reboot preserves the vector contents
<clever>
but holding RUN low by hand, corrupts the vector
<clever>
this might lead into what you said earlier, about inductors and capacitors in a SMPS
<clever>
how many cycles can it last at a given current
<clever>
and holding RUN by hand, was just too long
bg117 has joined #osdev
<doug16k>
there is some research into algorithms for lowering the extremely excessive refreshing of most DRAM cells. systems where you divide memory into buckets and you use ECC to handle gradually stretching out the refresh and speed it back up on ECC corrections
<clever>
yeah
<clever>
ive mentioned before, how you might have a seperate timer for every single row in the dram
<clever>
and it resets to a different number
<doug16k>
yeah
<clever>
so they are all refreshing at the slowest each row can handle
<clever>
but now you need a way to compare against 1000 timers, and pick the next one to expire
<clever>
and the whole reason dram is dram, is because each cell is just a dumb capacitor with a transistor for the row&column selector
<doug16k>
might be a good idea to just mark everything that isn't way above spec as bad
<clever>
so having each row inteligently detect its own ecc errors, would turn it into sram, lol
<clever>
doug16k: you mean like just skip any row that cant hold data for 2 seconds?
<clever>
and treat them like bad ram?
<doug16k>
yeah, tell the OS it can't put pages in it
<doug16k>
maybe even remap it in the chip so the good ram is all contiguous
<clever>
thats complicated, by the question of how an address maps to ram
<clever>
if i give you a 64bit addr, can you tell me exactly which row on which chip in which module it maps to?
<doug16k>
if you know how the addresses are wired, yeah
<clever>
i asked in the coreboot room a few weeks ago
<clever>
and every memory controller does it differently
<clever>
and with a closed-source bios, good luck :P
<doug16k>
hence knowing how it's wired :D
<clever>
doing it the same way as flash seems like a far better idea
<clever>
over-provision your dram cells
<clever>
and then remap around them
<clever>
so from the outside observer, it looks like every row is perfect
<doug16k>
exactly
<clever>
although, that requires that every cell in the entire row be perfect
<doug16k>
imagine they just exposed all the bad memory in ssd? lol
<clever>
if a shotgun sprays bad cells over the entire array, your going to have a lot of rows with only 1 bad bit
<doug16k>
OSes are way too dumb for that
<clever>
yeah
SpikeHeron has quit [Quit: WeeChat 3.6]
<clever>
also, my notes say that an 8 row tall, 64 column wide, chunk of the vector memory, is set to 0 by the boot rom
<clever>
512 bytes total
<clever>
due to how early it is in the boot process, there is virtually no way to not do that (you would need jtag)
<clever>
you could then store keys in that region
<clever>
and know that any attempt to reboot the system, will wipe them
<doug16k>
that and/or hope all the firmware revisions wipe it
<clever>
its wiped by the boot rom
mimmy has joined #osdev
<clever>
so there is no way for an outsider to change the code
<clever>
you would need to re-wire the rom in the silicon, while the chip is on
<clever>
and at that point, its simpler to just attach probes to the register :P
<doug16k>
you make a good point though. there should be some spec to tell the HW what to clear on reboot. too bad it tells the attacker where to look!
<clever>
thats where hw encrypted ram comes in
<clever>
design the hw, so the key changes on every boot, and you can never read the key
<clever>
then you can store secrets anywhere in ram
[itchyjunk] has quit [Ping timeout: 240 seconds]
<doug16k>
yeah
<clever>
the rpi-zero2 kinda has a form of that, but its static
<clever>
the addr/data busses beng mis-wired
<clever>
being*
<doug16k>
I tried filling all RAM with garbage in qemu. seabios fails
<clever>
sounds like a bug!
<doug16k>
yeah
<clever>
i had something similar in my bootloader
<clever>
i forgot to reset .bss on boot
<clever>
but the heap used a magic# to know if it was initiailized
<doug16k>
you can use the thing for mapping the huge pages to map a shred'ed file
<clever>
so normally, it reset itself
mimmy has quit [Ping timeout: 272 seconds]
<clever>
then i got lazy, loaded a new .elf over gdb, and just set pc=0 to restart it
<clever>
the heap didnt reset itself, and OOM'd
<clever>
but, in a nasty way
<clever>
malloc() just silently returned null, and the code didnt check for that
<clever>
the SD routines treated a null dest as a no-op, so it didnt read
<clever>
the MBR routines then tried to parse the _start code, lol
[itchyjunk] has joined #osdev
<doug16k>
yeah, it's a feat of strength to fix a memory corruption
<clever>
once i zero'd .bss, it ran better
<clever>
and obviously, fix all of those missing null-ptr checks!
<doug16k>
did everyone claim their free Samsung 980 pro 1TB for $150?
<doug16k>
nvme
<doug16k>
prime day
<clever>
havent heard of that
<clever>
ah
<doug16k>
my 1TB 960 pro was almost 1000 when it was shocking
tsraoien has quit [Ping timeout: 240 seconds]
<doug16k>
years of hammering disk image builds and it's at 5% wearout in smart
<clever>
how does it internally compute that nmber anyways?
<doug16k>
it knows how many times it erased the blocks
<doug16k>
the wear levelling knows
<doug16k>
you get to erase them N times and expect it to work. it might keep working for a random time after that
<clever>
temperature : 35 C (308 Kelvin)
<clever>
mines cooler then yours by a tad
<clever>
power_on_hours : 31,520
<clever>
oh, i have way more hours then you
<clever>
3.5 years on
<doug16k>
I have years on this
<clever>
vs your 340 days on
<clever>
your power_on_hours is only 340 days
<doug16k>
that on time is on and doing stuff time
<doug16k>
no computer is on time
gog` has quit [Quit: byee]
<doug16k>
not*
<clever>
why is mine in the 30k range then?
<doug16k>
you using it to record a camera stream?
<clever>
nope
<clever>
just chrome doing its idle writes
<doug16k>
I noticed that on new drives. go look at it after a week, it won't say 24*days
<doug16k>
my computer is on forever btw
<doug16k>
no such thing as off
<clever>
zfs reports that chrome is modifying up to 200mb per day
<clever>
same
<clever>
my uptime would be higher, if the system wasnt crashing hard so often
<clever>
memtest even crashes, lol
<doug16k>
and you keep going? wow, I am so much more risk averse
<clever>
i really need to replace this machine
<doug16k>
you don't have fantasies of horrifying bits in blocks written to /boot?
<clever>
its horid slow and now its crashy
<clever>
/boot is easily repaired
<doug16k>
not if it confused it ingeniously such that when it mounts it makes a total mess
gildasio has quit [Remote host closed the connection]
<doug16k>
we are talking like practically 0 probability, but you venture there with bad ram
<clever>
its hard to even confirm if it is bad ram, with how badly memtest crashes
<doug16k>
possibly
<clever>
all i can really say, is that i have confirmed a single bit-flip in a libpam.so
<doug16k>
it's 0 probability to hit a 1mm by 1mm spot on the ground if you drop a dart from 1M feet, but it's gotta land somewhere
<clever>
yeah
<clever>
sometimes it kills chrome by segfault
<clever>
sometimes the entire machine just locks up
<clever>
sometimes it takes weeks, sometimes hours
<doug16k>
bad ram is actually a very strong RNG
<doug16k>
there are research papers showing sense amplifiers used as hardware RNG
<doug16k>
it will cover the entire possibility space, eventually
<clever>
there was one guy from #raspberrypi-internals that used the rpi ram for fingerprinting
<clever>
he would intentionally turn the refresh off, let the data corrupt in unique ways, and use that as a fingerprint
<clever>
and thru the wizardry of stats, it acts like a predictable one-way function
<clever>
so a remote system can give you a challenge, you can let the dram corrupt it, then send it back, as proof of who you are
<clever>
and only if you have that exact dram module, will you pass the test
<doug16k>
that's next level paranoia, but I like it
<clever>
its kinda like having an HSM with keys, but you dont need special hw
noeontheend has quit [Ping timeout: 240 seconds]
<doug16k>
how does the other end check that you corrupted it correctly?
<clever>
i'm guessing it has a training phase, where you corrupt various data, and learn how quickly each bit fades
<clever>
and if bits depend on neighbors
<doug16k>
that would mean you could playback attack
<doug16k>
unless every hash is different
<clever>
i'm guessing the challenge wont always be setting bits that can fade
<clever>
so each reply has a unique set of bits being flipped
<clever>
you could also hide the challenge/response behind a DH encrypted session
<clever>
so a 3rd party cant see either one
<doug16k>
I had an IBM AT with 286, and it actually used the timer for refresh, I tweaked it out by making a program that slows the rate, then disables all interrupts except keyboard, and halts, so fetch won't help refresh
<clever>
though, mitm could then do the DH on both ends...
<clever>
would need to mix the DH key in with the challenge somehow
<doug16k>
it tolerated a lot less refresh if the cpu was still fetching
<clever>
yeah, the cache-miss was effectively refreshing the hot rows
<clever>
but the dead rows?
mimmy has joined #osdev
<doug16k>
no cache in my case, but on modern one yeah
<clever>
i wanted to mitm diablo 3, and i heard that blizzard uses srp6a for all of its authentacation
<doug16k>
clever, dead rows were riding on that 90% luck of cells with hardly any leakage
<clever>
basically, with some crypto wizardy, the server knowing your username and pw-hash, and the client knowing the user&pass, the 2 parties can agree on a shared secret key
<clever>
but, its immune to replay attacks and mitm attacks
<clever>
like a DH exchange
<clever>
and if the server has the wrong pw hash, the exchange falls apart
<clever>
so it also validates the server at the same time
<clever>
the only weakness i could find, is a mitm where the middle-man knows your pw
<clever>
he can then successfully play the role of both client and server
<clever>
then just decrypt, and re-encrypt
<clever>
but i didnt want an active mitm, because i was paranoid about what else they might be testing for
<clever>
my goal was a 100% passive mitm, at the damn router :P
SpikeHeron has joined #osdev
TorusField has quit [Read error: Connection reset by peer]
<doug16k>
that is actually a fun project idea. make a rig with a manually done memory controller (not the built in one in fpga) and do weird stuff like not violating the timings like refresh
<doug16k>
s/not//
<clever>
i have been wanting to learn more about dram, enough to do that
<doug16k>
re-bin your memory :D
<clever>
more just to understand how it works
<doug16k>
hard to do ddr4 and up though, so touchy about the physical part
<clever>
that reminds me
<clever>
somebody on the rpi forums, was asking about a pcie thing i hadnt heard of before
<clever>
running the pcie link without the clock pair
<doug16k>
aspm?
<clever>
from reading the posts, it sounds like the spread-spectrum stuff, will make the pcie link clock wiggle around
<clever>
so you dont cause a single pure tone in your RF leakage
<clever>
but then the data lanes need a dedicated clock signal, so they know when to latch data
<doug16k>
yeah, that's easy. you just add a small sine wave to the PLL VCO
<clever>
but, if you turn the spread-spectrum mode off, the pcie clock is just a pure tone, and you can recover the clock from the data lanes
<clever>
and then you can just run clock-less
<doug16k>
it might be chasing back and forth already by itself
<bslsk05>
www.sparkfun.com: Raspberry Pi Pico W - DEV-20173 - SparkFun Electronics
<clever>
CYW43439 + rp2040
<clever>
the drivers for the wifi have some weird license, that allows you to use it on any board with an rp2040 on it
<geist>
Yes and notice how un available it is
<clever>
yep
<geist>
Hmm what sort of language/etc is the drivers in?
<clever>
*looks*
<geist>
I have seen hardware locked licenses before. The ST code for the STM32 is locked into only being usable on ST hardware, which i thought was silly before
<geist>
However. Given that there are a bunch of clones of ST hardware out there it starts to make a bit more sense
<clever>
> This cyw43-driver is free only for non-commercial use (see LICENSE in this directory). This cyw43-driver is also available for use with Raspberry Pi Ltd semiconductor devices under different terms (see LICENSE.RP in this directory).
<geist>
stm32 seems to be the defacto low end embedded cortex-m hardware that multiple companies are straight up cloning it down to the hardware blocks
<clever>
looks like its free for non-commercial, probably a fee for comercial stuff, but the rp2040 is an exception
<geist>
Ah
<clever>
so RPF made a deal with them, so people can use the pico-w in comercial products, without having to pay the cyw43 guys
<clever>
and if your RF voodoo is strong, that still applies to a custom board with CYW43439 + rp2040
<geist>
Yah i guess you can build a carrier board with it attached
<clever>
so any clone using the same chips, is also free
<geist>
Which all in all isn’t a bad idea, as long as you can score some sort of guaranteed supply of them
<geist>
Which may be the real issue
<clever>
the wording i saw, didnt say "pico-w", but rather, "any board using rpi silicon"
<geist>
But may not be a problem for some sort of low volume thing
xhe has quit [Read error: Connection reset by peer]
<geist>
Ah that helps
<clever>
yeah
<clever>
both future-proofs it, and lets clones using the same chips in
<clever>
from the limited datasheets, the CYW43439 in the pico-w, is from the same family as the wifi on the zero/pi3/zero2/pi4(00) lineup
<bslsk05>
seemoo-lab/nexmon - The C-based Firmware Patching Framework for Broadcom/Cypress WiFi Chips that enables Monitor Mode, Frame Injection and much more (399 forks/1887 stargazers/GPL-3.0)
DanDan has joined #osdev
<clever>
so in theory, you can take your existing rp2040 fork of LK, toss cyw43-driver in, and wire it into your IP stack
<clever>
and boom, wifi!
wand has quit [Remote host closed the connection]
<clever>
yeah, here it is:
<clever>
> Raspberry Pi Ltd (Licensor) hereby grants to you a non-exclusive license to use this software solely with the Licensor's microcontroller chip (RP2040) or any other semiconductor device produced by the Licensor.
<clever>
> No other use is permitted under the terms of this licence.
<clever>
Redistribution/modification is allowed, as long as its still limited to usage on rpi silicon
<clever>
so you can do pretty much anything with it, as long as the license stays attacked, and you only use it on rpi silicon
<clever>
attached*
wand has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
noeontheend has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
freakazoid333 has quit [Ping timeout: 240 seconds]
frkazoid333 has joined #osdev
xhe has quit [Ping timeout: 272 seconds]
xhe has joined #osdev
xhe has quit [Read error: Connection reset by peer]
xhe has joined #osdev
frkazoid333 has quit [Ping timeout: 244 seconds]
<geist>
cool
<clever>
just to poke around a bit, i loaded one of the firmware blobs into ghidra
<clever>
and i do see a decent amount of thumb code, as i expected, along with some printf statements
<clever>
but the printf function itself, appears to be in the rom, so i cant see anything
bg117 has quit [Read error: Connection reset by peer]
mzxtuelkl has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.5]
ThinkT510 has joined #osdev
xhe has quit [Ping timeout: 240 seconds]
xhe has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
the_lanetly_052_ has quit [Remote host closed the connection]
<doug16k>
clever, it doesn't pass pointers to format strings you can see?
<doug16k>
odd for it to run directly from rom, usually you copy the whole thing to shadow ram
<doug16k>
ah I see, you mean just examining the blob, not the real thing
xhe has quit [Ping timeout: 272 seconds]
the_lanetly_052 has joined #osdev
xhe has joined #osdev
GeDaMo has joined #osdev
xhe has quit [Ping timeout: 240 seconds]
<clever>
doug16k: yeah, the format string and args are all visible, but the addr of the printf routine itself is in the rom
<clever>
so i have zero clue where the logs wind up
jafarlihi has joined #osdev
<jafarlihi>
How do I know if reading an address will crash the LKM before actually doing it?
mzxtuelkl_ has joined #osdev
<klange>
jafarlihi: You were informed previously that this is not a Linux kernel channel.
<jafarlihi>
ok sorry
<jafarlihi>
#linux is all about distro hopping and shit
mzxtuelkl has quit [Ping timeout: 264 seconds]
<GeDaMo>
Try ##kernel
<GeDaMo>
There are also distro-specific kernel channels
<klange>
There are also several channels on another network, oftc.
<kazinsal>
this happens to be the channel for people who are bonkers enough to write their own kernels, specifically non linux ones
<zid`>
he's been told all this repeatedly
<GeDaMo>
Maybe they like the abuse :|
<kazinsal>
I'm glad that in my absence I have not strayed from the reality of this channel
<zid`>
ooh maybe
<kazinsal>
it's been a few weeks since I've been able to do any kernel hacking and it's equal parts horrifying and pleasant to know that nothing has changed in those few weeks
<zid`>
Actually we swapped the universe out for an entirely different one last tuesday
<zid`>
not a lot has changed but we left in a few REALLY silly easter eggs
<kazinsal>
did we figure out gravity manipulation in that switch? because what I'm hoping for is gravitic unifields
<zid`>
no, france is now 2 inches further south though
<zid`>
farther
<kazinsal>
so we haven't figured out how to extrude post-transuranic supermolecules while I've been in an alternate universe. shit
xhe has joined #osdev
<jafarlihi>
Can I ask an assembly question?
<kazinsal>
your question has been exhausted by your question; please submit form 1138-C before submitting your question about assembly languages
<jafarlihi>
Here goes
<jafarlihi>
I'm disassembling a legit function in a legit kernel that legit works but 0xe-th instruction is this: 0xe: callq 0xfffffffffffffec0
<jafarlihi>
How is that a legit instruction? Shouldn't that always crash?
the_lanetly_052 has quit [Remote host closed the connection]
<jafarlihi>
I mean, those addresses are unmapped right?
<kazinsal>
unmapped just means the kernel can handle it however it wants in software
<jafarlihi>
But calling into it is surely a crash right?
<kazinsal>
it could be, or it could be a "magic number" for the kernel to handle it specially
<jafarlihi>
Magic number would get a chance to be captured at MM?
<jafarlihi>
How does it get captured and tested
<kazinsal>
so if it's unmapped at the MMU then it raises a page fault and the kernel handles it accordingly
<kazinsal>
alternately it could be mapped specifically to somewhere by the kernel and it executes normally
<kazinsal>
what kernel are we talking about here
<GeDaMo>
calls are relative, that's a backwards jump, is there another function at that address?
jafarlihi has quit [Ping timeout: 272 seconds]
jafarlihi2 has joined #osdev
<jafarlihi2>
GeDaMo: How do you know it is a "backwards" jump?
<jafarlihi2>
kazinsal: Linux
<GeDaMo>
Because calls are relative and that offset is negative
<jafarlihi2>
But does it make sense to be such a big number?
<GeDaMo>
That's a 64-bit value, not sure that's valid unless it's an indirect call
<GeDaMo>
Yeah, it's indirect so it's reading the call target from the address
<jafarlihi2>
My base address for disassembly is 0x0, I guess it is an underflow right?
<klange>
mrvn: Going to guess because it's never used.
<klange>
clang produces the expected warning without anything using it, but gcc seems to be too greedy on just ignoring the fact that you typed anything at all in the source file
<mrvn>
int insertInBST(BinaryTree *, int) { BinaryTree *prev; return prev->data; } still no warning
<klange>
is that still in a class you never touch?
pretty_dumm_guy has joined #osdev
<klange>
gcc be like "lol nice class you got ther, just gonna ignore it"
<doug16k>
it would essentially mov the address of the ret to the word just below the stack pointer, then return
<doug16k>
good interview question
<doug16k>
assuming you meant: call .Lpush_ip ; .Lpush_ip: ret
<mrvn>
doug16k: If it just pushed to the stack but not the return stack buffer then the call to g would return from foo with a corrupted stack
<doug16k>
so it would push .Lpush_ip's address, then ret would mispredict, because the call of next line disrupted the RSB, then the ret would execute again after it restarted
<mrvn>
yep
<mrvn>
I guess that's ok. compilers don't generte such code.
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
jafarlihi has joined #osdev
noeontheend has quit [Ping timeout: 260 seconds]
<jafarlihi>
I've got this x86 instruction: 0xE8ADFEFFFF. E8 is "call" opcode, so the 0xADFEFFFF part is the immediate relative address right?
<mrvn>
if E( has an imm32
<mrvn>
E8
<GeDaMo>
Yeah, it is
<jafarlihi>
But it is in the negative direction, right?
<GeDaMo>
Yes
<jafarlihi>
Cool thanks
<jafarlihi>
It kinda doesn't make sense because it appears at 0xffffffff936d8bce and disassembler shows the immediate part as 0xffffffff936d8a80. The difference between those two are a lot smaller than 0xADFEFFFF. How come?
<mrvn>
It's only -339
<mrvn>
you are looking at little endian data
matt__ has joined #osdev
matt__ is now known as freakazoid333
opal has quit [Ping timeout: 268 seconds]
noeontheend has joined #osdev
<jafarlihi>
Oh right, thanks
jafarlihi has quit [Quit: WeeChat 3.5]
<gog>
lmao
freakazoid333 has quit [Ping timeout: 244 seconds]
opal has joined #osdev
_xor has quit [Quit: brb]
nj0rd has quit [Quit: WeeChat 3.6]
mzxtuelkl_ has quit [Quit: Leaving]
arch_angel has quit [Read error: Connection reset by peer]
nj0rd has joined #osdev
xhe has quit [Ping timeout: 255 seconds]
xhe has joined #osdev
xhe has quit [Read error: Connection reset by peer]
xhe has joined #osdev
k0valski1889 has joined #osdev
[itchyjunk] has joined #osdev
frkzoid has joined #osdev
noeontheend has quit [Ping timeout: 240 seconds]
frkzoid has quit [Ping timeout: 244 seconds]
frkzoid has joined #osdev
frkzoid has quit [Ping timeout: 244 seconds]
* geist
yawns
<geist>
good morning everyone
the_lanetly_052 has quit [Ping timeout: 244 seconds]
<bslsk05>
en.wikipedia.org: Herbivore men - Wikipedia
<gog>
zid`: me too
<geist>
i need to mow grass today
<mjg_>
no yard gang unite
<mjg_>
i remember moving the loan as a kid at my parents house, good 5 hours every 2 weeks
<mjg_>
rotating with my brother
<mjg_>
cured me out of ideas of having this kind of bullshit to take care of
<mjg_>
mowing even
<gog>
yes
<gog>
lawn bad
<geist>
yah thankfully it only takes about 30-45 minutes to mow the lawn
<mjg_>
f me man
<mjg_>
i mean you do you
<geist>
and i have a nice new electric mower so it's not a big noisy mess
<mjg_>
no teenagers to pay to do it in the area?
<geist>
oh i could. it's just pricey
<mjg_>
i thought you worked at G
<zid`>
I bought some white bathroom tiles and adhesive
<geist>
sure, but that doesn't mean i want to spend it
<zid`>
and had a cheeseburger
<zid`>
so it wasn't all bad touching grass I suppose
<geist>
cheeburger cheeburger cheeburger pepsi
<mjg_>
scrooge mcduck over here
<mjg_>
the way i see it, the teenager may need it more than you
<mjg_>
and if they are willing to work for it...
<zid`>
I need it more than the teenager dw
<zid`>
He's saving up for a nice zen4 for me
<mjg_>
i don't think geist will fly you to mow his lawn
<mjg_>
or is it that pricey
<geist>
teenagers sk a lot now. but really mowing is easy it's having a full yard guy that does the full yard thing
<geist>
that's what most folks do. that tends to run north of $200/mo
<mjg_>
seriously though, if there is one thing good about is that you can mentally check out while you do it
<geist>
but i'll probably eventually need that
<mjg_>
esp. if it is not that noisy
<zid`>
You can get grassroombas
<geist>
mowing is the easy manual thing, it's the trimming of stuff, dealing with weeding, removing yard waste, etc
<geist>
mowing you just put on your headphones and push a thing around for 30 minutes
<geist>
and it's kinda ASMR pleasing sort of
<mjg_>
(:
<mjg_>
my parents had a lawnmower which was super loud and vibrated a lot
<mjg_>
your hands were going into a weird state after a while
<geist>
yah i was borrowing my parents which was like that until i decided to get the electric one. this new gen of electric yard tools with interchangable batteries are great
<geist>
dunno if tey'll last a long time, but really dig not having to deal with the gas stuff
<mjg_>
i'm confident this was not healrthy for shit either
<geist>
yep. i get that with trimmers. your hands are strange afterwards
<mjg_>
the one benefit in growing up in a rural area is that it is supposed to be healthier
<mjg_>
but no thanks to crap like the above
<geist>
was reading about that. reallly really long term usage of vibrating things like that can apparently induce bubbles in your bloodstream or whatot
<geist>
but i think it's more like a life of manual labor using that stuff every day
<geist>
but i had an old string trimmer that was unbalanced and it'd absolutely do that to you in like 10 minutes. your hands would be tingly and shaky for an hour afterwards
<geist>
i stopped using it for that reason
<mjg_>
ouch
<geist>
i used to have shaky hands for a few minutes after riding my motorcycle for too long, but it was a generally vibraty bike anyway. if i gripped the grips too hard it was like that
<mjg_>
it is kind of interesting how the "physically active people" doing blue collar work keep ending up with horrific problems
<mjg_>
part of is is their fault for having bad form or whatever
<mjg_>
but other than that you are just dealt a shitty hand in the poker of life and good luck with it
<mjg_>
in my experience the blue collar tooling tries to make you suffer
<geist>
what i do miss is a riding lawn mower, but my yard isn't big enough for it and it'd use up too much space in the garage even if i just bought one
<geist>
i'd be done in like 10 minutes, maybe 15 times a yeard. not worth the space
<mjg_>
oh don't do that
<geist>
but still, i used to mow the lawn when i was little and it was fun
<geist>
used to race the lawn mower up and down the road, etc
<mjg_>
at least you can get some walking while you do it
<mjg_>
so it's not a total loss
<mjg_>
definitely negated if you sit through it :-P
<geist>
there is a new gen of electric ones, but they're pricey, maybe in a few years
<mjg_>
by that time the lawnmover will be running linux
<mjg_>
i would not sit on that
<geist>
well very possible mine already does, though that'd be overkill for the microcontroller like behavior it already has
<kof123>
when i mow i always spiral, do the edges/difficult parts first and circle in, no having to turn around lol
<mrvn>
but then you always turn in the same direction and get dizzy.
frkazoid333 has joined #osdev
kof123 has quit [Ping timeout: 265 seconds]
jafarlihi has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
jafarlihi has quit [Ping timeout: 276 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
noeontheend has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]