qubasa has quit [Remote host closed the connection]
qubasa has joined #osdev
smach has joined #osdev
<heat>
dead channel
<Mutabah>
Well... just saying "hi" doesn't pique much interest it seems
<heat>
how is the development of the systems of operation
<Mutabah>
Well, after making xhci work, I'm moving back to compiler development again
<heat>
had your dose of osdev? :P
<heat>
I'm gathering the courage to add an ext4 write path to my OS
<Mutabah>
For now, yes.
<heat>
I think the extent tree will be a bit tricky but the really tricky part will be journaling - although I'm not sure if it's strictly needed, I don't think so
<Mutabah>
I'll return, I always do
zaquest has quit [Remote host closed the connection]
<heat>
all I want is a stable write path for ext2/3/4
<heat>
it's one of the things I really dont have
zaquest has joined #osdev
<heat>
as a result, the system works semi-great in tmpfs, but has weird crashes, bugs, weird performance on a filesystem on a bdev
<heat>
and worse of all, corruption
<heat>
actually, I'd take any filesystem really
<heat>
I've thought about adding openzfs, or stealing fuchsia's f2fs which seems port-friendly-enough
_saltd is now known as saltd
solenya has joined #osdev
solenya has quit [Ping timeout: 244 seconds]
_xor has joined #osdev
solenya has joined #osdev
kof123 has quit [Ping timeout: 268 seconds]
wxwisiasdf has joined #osdev
<wxwisiasdf>
Hello people of the Operable Operating Developments in the Systems
<wxwisiasdf>
IRC chat the room :-)
* saltd
joined #wxwisiasdf
<wxwisiasdf>
So I have 3 options atm, 1. I write a new memory allocator from scratch, 2. i use my existing allocators i have written and tyr to frankenstein them into my os or 3. use liballoc
<heat>
henlo
<heat>
3 is bad
<wxwisiasdf>
Why?
<heat>
1 or 2 depends on what your existing allocator is
<heat>
isn't liballoc that shady malloc implementation?
<wxwisiasdf>
My existing allocator experience is basically linked list blocks
<wxwisiasdf>
Otherwise I haven't tried anything else
<wxwisiasdf>
so I am here to ask, what's better allocator - I generally would allocate big blocks rather than small units so that in consideration...
<heat>
you could generally do a slab allocator design
<heat>
that's generally a good idea
<wxwisiasdf>
i already do slab
<heat>
ok great
<heat>
malloc on top of slab, dun
<wxwisiasdf>
no?
<heat>
yes? it's a tried and true design
<heat>
works in linux
<wxwisiasdf>
fair
saltd has quit [Remote host closed the connection]
[itchyjunk] has quit [Remote host closed the connection]
<heat>
if not for that, you'd need a fancy ass malloc with lots of percpu shit to even be remotely comparable to a bunch of slabs
<heat>
hell, linux's slabs are even percpu'd to that
<heat>
s c a l a b i l i t y
<wxwisiasdf>
Well I am not aiming to make the next linux competitor lol
<heat>
i genuinely regret not having gone for a slab-centric design
<wxwisiasdf>
why's that?
<heat>
because I stole musl's old malloc, it's horrible and unreadable, the lock is huge, it requires virtual memory
<wxwisiasdf>
fair enough
<wxwisiasdf>
on my OS i try to use static memory as much as possible
<wxwisiasdf>
yes, UI widgets are limited to a constant, so are tasks, talk about scalability
<heat>
sounds excessive
<heat>
is that because you didn't have malloc? :P
<wxwisiasdf>
no because i started writing a new OS 2 days ago and couldn't bother to make an allocator
<wxwisiasdf>
but hell for sure we went all-in in UI
<wxwisiasdf>
i can drag le window, i can switch le task, i can't allocate shit
<wxwisiasdf>
of course, i will need to implement malloc, but those damn viewport widgets are so fancy
saltd has joined #osdev
kof123 has joined #osdev
<heat>
meanwhile onyx's le command line go brrrrrr
<wxwisiasdf>
hehehe
<wxwisiasdf>
where UDI tho, #reviveUDI
<heat>
it's up there, watching out for us
<heat>
together with itanium and mpx
<heat>
and mmx and 3dnow
* heat
sheds a tear
<wxwisiasdf>
i know all of these, but what is mpx?
<heat>
exactly.
<heat>
mpx was an extension to add bounds checking
<wxwisiasdf>
oh okay
<heat>
introduced in skylake, died fairly quickly
<Griwes>
another parser finished, now to actually write a thing that consumes and makes sense out of the ast, and then write another generator, and then I can go back to actually implementing the kernel side of my IPC primitives
<heat>
are you doing this for the compiler or the os
<heat>
be honest
<Griwes>
I wonder how many more auxiliary tools that will need to parse and generate files I'll need to write for this *OS* project
<Griwes>
heat, this is for my IPC definition language (that I'm sure will change its shape fundamentally at least twice in the future)
<heat>
shoulda used protobufs
<Griwes>
I know I'll eventually need it, and I'd hate to waste time writing what it'll be generating by hand just to have it re-written
<heat>
or flatbuffers
<heat>
or capnproto
<heat>
or fidl
<wxwisiasdf>
IPC? oh, I just give all my tasks full access to the system
<Griwes>
none of the first three would generate all the machinery I want to have generated
<Griwes>
and fidl is (a) not invented here and (2) weirdly putting me off for an unspecified reason
<wxwisiasdf>
what about xml
<heat>
+1 for xml
<heat>
everything is better with a nice dose of xml
<Griwes>
eww
<wxwisiasdf>
just don't get into ooxml or microsoft will take your house, your pets, your windows and especially your doors
<Griwes>
also then this task would turn into writing an XML parser of all things instead of this
<Griwes>
and, trust me, I do _not_ want to be writing any XML parsers in my future
solenya has quit [Ping timeout: 268 seconds]
<wxwisiasdf>
don't you want le epic regex HTML parser
<wxwisiasdf>
so you can brag about HTML-powered OS IPC
<Griwes>
eww
<heat>
how about
<heat>
COM
<heat>
sounds good yeah?
<wxwisiasdf>
COM, the executable?
<heat>
COM, the component object model
<wxwisiasdf>
ah i see, active x
<Griwes>
ugh, if I ever get around to a web browser I'll either need to use one of the shitty already existing things or actually write an XML parser
<heat>
if you ever get to a web browser you're not getting out of there alive
<heat>
I guarantee you that
<Griwes>
thankfully, I do not foresee myself getting to gui in the future before the planet catches on fire
<Griwes>
so I'll probably be ok
<wxwisiasdf>
Griwes: your os seems very interesting - do you happen to have a ISO i can download to ~~mindlessly click things~~ try it out?
<Griwes>
you've heard virtually nothing about my OS
<wxwisiasdf>
well
<Griwes>
and also at this point in time it simply arrives at the second userspace process and just hangs in there
<wxwisiasdf>
ah okay
<Griwes>
by hangs there I mean it executes a (very undefined behavior-laced) `for (;;) ;`
<wxwisiasdf>
no gui?
<Griwes>
define gui :V
<wxwisiasdf>
anything remotely gui-like, even tui
<Griwes>
is lines of 8x16 text logs in a linear framebuffer a gui? asking for a friend
<wxwisiasdf>
visopsys had one, when i randomly downloaded random osdev projects
<wxwisiasdf>
heh
<wxwisiasdf>
:P
<Griwes>
I'll be in a very good shape if this project manages to get to the stage where I'm contemplating gui
<heat>
i'm contemplating web browser
<Griwes>
because it will mean that I have a USB stack
<heat>
i kinda want chromium
<wxwisiasdf>
i'm contemplating running actual programs not made by me
<heat>
like really bad
<Griwes>
bad heat
<heat>
firefox stan?
<wxwisiasdf>
run half life 2, like managarm did
<heat>
i use both firefox and chrome
<wxwisiasdf>
"Can it run DOOM?" Yes, but can it run Crysis?
<heat>
wxwisiasdf, my budget linux is budget linux but not that much linux
<Griwes>
yes, but also, I expect that _porting_ a web browser is also an endlessly consuming task
freakazoid333 has quit [Ping timeout: 244 seconds]
<heat>
maybe
<wxwisiasdf>
i will not have a web browser on my OS
<heat>
but my OS is decently evolved, mature network stack, POSIX
<heat>
i'm just missing graphics and audio?
scoobydoo_ has joined #osdev
<heat>
and I could do graphics with that google project thing that does software rendering
<Griwes>
ah yes, two of the things that browsers do
<wxwisiasdf>
heat, I am on the complete polar opposite, I have graphics, audio but otherwise nothing
<wxwisiasdf>
but atleast i can run some programs before the system starts seizuring itself
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo_ is now known as scoobydoo
<wxwisiasdf>
'cuz no malloc
<heat>
wanna dock join forces?
<wxwisiasdf>
:P
<Griwes>
I kinda can't wait to start doing actual device drivers but I don't really want to take dumb shortcuts to get there :| (well, maybe other than leaving TODO assertions all around the branches of the code that I am not executing _yet_)
<Griwes>
other thing is that I want to have choices as to what to do next, which is currently a thing lacking in this project
solenya has joined #osdev
<Griwes>
but hopefully I'm slowly but steadily crawling towards the "do I do USB, SATA, networking, or something completely different now" point, which I reckon must feel nice
<wxwisiasdf>
I have only a few defined goals for my OS: 1. look like windows 9x, 2. run MS-DOS applications, 3. have ffmpeg ported so i can play video
<heat>
at the end of the day, that's how microkernels go right?
<heat>
lots of initial set up
<wxwisiasdf>
microkernels are super cool
<wxwisiasdf>
they take a lot of time to design but then "it all comes together"
<Griwes>
yeah
<Griwes>
I mean, I knew what I was signing for :P
<wxwisiasdf>
this is my 4th iteration on my OS
<wxwisiasdf>
haven't been able to run gcc yet
<wxwisiasdf>
first it was for 8086 pcs in asm, then it was for risc-v with some nice terminal (that crashed), then it was a mainframe os but i kinda missed being able to use a gui, so here i am
<wxwisiasdf>
problem is that on the first 3 iterations i went all NIH, so progress was slow, and i was impatient
<wxwisiasdf>
in this new iteration it's frankesteining the components of my old iterations to speedrun to something with visable results
<heat>
you could try forking something else
<wxwisiasdf>
Yes, but whats the fun in that? :P
<heat>
*bsd people in shambles*
<Griwes>
yeah, reusing code is no fun :P
<Griwes>
(except maybe of an (optimizing) compiler and a build tool or five lol)
<wxwisiasdf>
Griwes: what about writing new code, learning from the mistakes of old ones
<Griwes>
what about writing new code and learning from the mistakes in the new code :V
<wxwisiasdf>
lmao
<wxwisiasdf>
I have seen I have got better writing code in general through, and it feels great, seeing my old code being trash in comparison to what i write now
<Griwes>
oh I don't think that last part ever stops being painfully true
<wxwisiasdf>
true
frkzoid has joined #osdev
heat has quit [Ping timeout: 240 seconds]
solenya has quit [Ping timeout: 252 seconds]
<zid>
when cloudflare goes bankrupt next week, whose blog posts are we going to read? :(
<wxwisiasdf>
what?
solenya has joined #osdev
wxwisiasdf has quit [Quit: Lost terminal]
saltd has quit [Remote host closed the connection]
<kof123>
*bsd people in shambles* hey now, them's fighting words. the term is "beleagured" due to a "crippling bombshell". also accept "dying" as in "apple/bsd/<insert here> is [always] dying"
saltd has quit [Read error: Connection reset by peer]
<froggey>
moon-child: build one yourself!
<moon-child>
be a neat trick
<kof123>
about 10-15 years ago i found a website selling lisp machines (apologies if those are not the same -- dont recall/know all the differences, or if there were any "clones" etc.). just one guy, dont know how he acquired them. he kind of tried to talk ppl out of them.
<kof123>
so...i dont know, it seemingly wasnt impossible 10-15 years ago
<zid>
I can't imagine liking lisp that much
solenya has quit [Ping timeout: 268 seconds]
solenya has joined #osdev
[itchyjunk] has joined #osdev
<CompanionCube>
moon-child: i assume the leaked 'vlm' doesn't count?
<CompanionCube>
there's a newer official version but that's reasonbly unobtanium iirc
<CompanionCube>
also there's the now-opensource interlisp
<moon-child>
CompanionCube: that is not a symbolics machine, only the code for one
<CompanionCube>
is the version on a macintosh expansion card good enough, those can pop up on ebay for $$$
netbsduser has joined #osdev
solenya has quit [Ping timeout: 268 seconds]
Vercas6 has joined #osdev
solenya has joined #osdev
solenya has quit [Ping timeout: 244 seconds]
GeDaMo has joined #osdev
saltd has joined #osdev
saltd has quit [Remote host closed the connection]
saltd has joined #osdev
terminalpusher has joined #osdev
_xor has quit [Quit: WeeChat 3.6]
gog has joined #osdev
_xor has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
solenya has joined #osdev
solenya has quit [Ping timeout: 252 seconds]
saltd has quit [Remote host closed the connection]
terminalpusher has quit [Remote host closed the connection]
solenya has joined #osdev
sham1 has quit [Quit: WeeChat 3.5]
epony has quit [Remote host closed the connection]
sham2 has joined #osdev
gog has quit [Ping timeout: 244 seconds]
sham2 has quit [Client Quit]
solenya has quit [Ping timeout: 252 seconds]
sham1 has joined #osdev
nyah has joined #osdev
sham1 has quit [Quit: WeeChat 3.5]
sham1 has joined #osdev
gog has joined #osdev
saltd has quit [Read error: Connection reset by peer]
carbonfiber has joined #osdev
saltd has joined #osdev
Vercas6 has quit [Remote host closed the connection]
saltd has quit [Read error: Connection reset by peer]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
Vercas6 has joined #osdev
[itchyjunk] has joined #osdev
[_] has joined #osdev
[itchyjunk] has quit [Client Quit]
saltd has joined #osdev
saltd has quit [Read error: Connection reset by peer]
wootehfoot has joined #osdev
[_] is now known as [itchyjunk]
Matt|home has joined #osdev
saltd has joined #osdev
<dzwdz1>
i just finished E1M1 on my os, what a nice feeling
<Mutabah>
Noice
dzwdz1 is now known as dzwdz
mjg_ has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
frkzoid has quit [Ping timeout: 244 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
epony has joined #osdev
d5k has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
saltd has quit [Remote host closed the connection]
d5k has quit [Quit: Lost terminal]
gog has quit [Read error: Connection reset by peer]
gog has joined #osdev
gog has quit [Client Quit]
saltd has joined #osdev
CompanionCube has quit [Ping timeout: 264 seconds]
Stary has quit [Ping timeout: 268 seconds]
gog has joined #osdev
Stary has joined #osdev
CompanionCube has joined #osdev
<rpnx>
for raspberry pi 3, is there anything I could do that would damage it permanently?
<rpnx>
e.g. any io mapped regions that overwrite firmware or change voltage
<rpnx>
Getting a new one will be hard at the moment
wxwisiasdf has joined #osdev
<wxwisiasdf>
Good morning o/, people from the Operable Operation of the Systems in Development
<rpnx>
hello :)
<rpnx>
I had a crazy idea. A virtual machine that runs LLVM in the kernel and all processes are loaded as Java byte code with kernel magic to make it appear like the machine runs java to userspace
dude12312414 has joined #osdev
terminalpusher has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<bslsk05>
en.wikipedia.org: Singularity (operating system) - Wikipedia
<sbalmos>
It's a real PITA to engineera JIT compiler, runtime (usually with GC), etc etc etc into a kernel layer
<zid>
yea we have those
<zid>
they're called web browsers
<sbalmos>
it's called ChromeOS ;)
<rpnx>
I found the page that describes the page table format:https://developer.arm.com/documentation/101811/0102/Controlling-address-translation-Translation-table-format
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<dzwdz>
wasn't there an arm extension for running jvm bytecode natively?
<j`ey>
yes jazelle
saltd has quit [Read error: Connection reset by peer]
saltd has joined #osdev
rpnx_ has joined #osdev
FreeFull has joined #osdev
<rpnx_>
So, the .img file the raspberry pi boots is just a plain binary, with no formatting?
<rpnx_>
like, just the raw machine code?
<clever>
rpnx_: which .img file?, kernel.img?
<rpnx_>
yes
<clever>
yeah, thats just raw arm32 code
<rpnx_>
kernel8.img/kernel7.img
<clever>
kernel8.img is raw aarch64, with optional gzip over it
<rpnx_>
kernel8.img.gz or kernel8.img with gzip?
<clever>
just kernel8.img
<rpnx_>
how does it decide if gzip was used o-O
<clever>
root@pi400:~# file /boot/kernel*img
<clever>
/boot/kernel8.img: gzip compressed data, was "Image", last modified: Wed Dec 1 15:59:53 2021, from Unix, original size 21391872
<clever>
/boot/kernel7.img: Linux kernel ARM boot executable zImage (little-endian)
<clever>
rpnx_: it tries to ungzip it, and if it works, it works!
<rpnx_>
...
<clever>
if it failed, then it gives up, and just runs whatever it found
<clever>
unmodified
<rpnx_>
So basically I need to gzip it to guarantee it will work.
<clever>
gzip has its own headers
<rpnx_>
Does it copy my binary to the start address?
<clever>
to the kernel load address, which can be changed in config.txt
<bslsk05>
github.com: tools/armstubs at master · raspberrypi/tools · GitHub
<clever>
these are the arm stubs, the right one for the current model gets dropped at arm physical 0
<clever>
it sets some basic arm control registers, before jumping to the kernel entry-point
<brynet>
OpenBSD just distributes firmware + dtb and compiles u-boot with EFI application support, that way we could just port our existing EFI bootloader.
<clever>
its also responsible for putting the dtb addr into the right register
<heat>
sbalmos, chromeOS doesn't have chrome in the kernel...
<heat>
chromeOS is literally linux with stuff on top
<sbalmos>
heat: I know. it was a response to the HTML/JS OS comment
<clever>
rpnx_: the red boxes on the graph, are the official/closed firmware, while the green boxes are the open firmware i'm working on
<rpnx_>
ah ok
<rpnx_>
I am not sure if I'd call it firmware
<rpnx_>
if it's on an sdcard
<clever>
for the pi4, its more firmware-ish
<clever>
the bootcode.bin and bootmain.elf stages are held in SPI flash
<rpnx_>
Can the owner overwrite that?
<clever>
yep
<rpnx_>
ok.
<heat>
zid, >cloudflare goes bankrupt next week <-- huh? did something happen?
<clever>
rpnx_: the pi0-pi3 lineup is also capable of booting from SPI, but the official firmware doesnt support it
<clever>
so it may malfunction if you put bootcode.bin on SPI
<clever>
or it will work, but still expect an SD card with start.elf
<heat>
clever, you should write this down into docs
<heat>
it would save you the trouble of repeating yourself :P
<clever>
heh, yeah
<clever>
rpnx_: https://i.imgur.com/PLepKYm.png is how the pi4 can boot, the bootcode.bin and bootmain are held in SPI flash, start4.elf on your desired boot media, and net-install is fetched over https!
<rpnx_>
right... can that key be changed once set?
<clever>
nope
<wxwisiasdf>
heat, using PIC should be fine through.. or i can still run onto problems?
<rpnx_>
never? :o
<clever>
there are 2 levels of secure-boot on the pir
<heat>
wxwisiasdf, what are you trying to do?
<clever>
rpnx_: the 1st level requires an rsa2048 pubkey in the SPI flash, and SIGNED_BOOT=1 set in the spi config file, it then expects a boot.img + boot.sig on the SD card, signed by that key
<wxwisiasdf>
heat: segmented kernel & giving some use to the GDT aside from just storing tss'es and ldt's
<clever>
rpnx_: boot.img contains a fat32 fs, with all of the normal files you would have had bare on the SD
<heat>
wxwisiasdf, segmentation doesn't work in x86_64, so don't use that
<clever>
that 1st level, can be turned off at any time, by just re-flashing the SPI
<wxwisiasdf>
heat, i am in i386
<heat>
1) don't
<heat>
2) 32-bit PIC has horrible codegen
<clever>
rpnx_: the 2nd level, burns the sha256 of your pubkey into the OTP, and locks secure-boot on
<clever>
rpnx_: so if anybody attempts to modify or remove the pubkey, it just wont boot, until thec correct key is put back into place
<heat>
gcc really isn't segmentation aware. if just blindly setting the segments and letting it run works? i don't know, maybe?
<rpnx_>
oh interesting, I didn't know you could secure a raspberry pi for your own use.
<clever>
rpnx_: the 1st level can be partially secured with a jumper on the write-enable pin
<heat>
but then again, segmentation is stupid and weird and bad
<clever>
rpnx_: its only meant to be used on the CM4, but the code does also work on the pi4
<rpnx_>
Does the PI have a TEE that is user programmable?
<rpnx_>
like can I use that to set up dm-verity and user pincode?
<wxwisiasdf>
heat, i have already done paging & x64 stuff so i kinda know i am doing a backwards flip
<clever>
rpnx_: the VPU kinda already is a TEE, but the official firmware doesnt use it in a secure manner
<clever>
rpnx_: there is a mailbox call to just let you run anything you want within the VPU
<rpnx_>
VPU?
<heat>
oh boy
<clever>
the cpu core that the firmware runs on
Burgundy has quit [Ping timeout: 244 seconds]
<heat>
s/cpu/gpu/
<clever>
heat: its only called a gpu because it used to run the opengl and 2d stacks
<clever>
but the arm is just as capable of driving those hw blocks
<clever>
the vpu is more like the intel me
<heat>
no
<clever>
and they just put opengl into it, so you could have DRM protected video frames
<heat>
more like the amd secure processor
<clever>
yeah, that family of things
<heat>
intel me doesn't initialize memory
<clever>
ahh
rpnx_ has quit [Quit: This computer has gone to sleep]
<heat>
which is why you need CAR
<heat>
AMD firmware doesn't
<clever>
the VPU also needs CAR
<heat>
"and they just put opengl into it, so you could have DRM protected video frames" what the fuck
<heat>
broadcom???????? what is wrong with you
<clever>
heat: i think its partially a legacy thing, from before the arm core was even there
<clever>
and when the arm did join the party, they kept the opengl on the vpu, for many reasons
<heat>
the rpi is such a weird platform
<heat>
you just go scare #dri-devel people again
<heat>
it was hilarious
<clever>
lol
<clever>
so basically, the arm core can deal with wifi/https, and download an encrypted h264 stream, and fire it off to the VPU
<clever>
the VPU can then decrypt it with well protected keys, h264 decode it, and then feed those frames into either the 2d or 3d stack
<clever>
and the arm core can direct the whole thing, like rendering polygons around the video
<clever>
but the arm can never actually get even 1 pixel of the protected video stream
<clever>
if implemented right
<clever>
perfect for a streaming media box, like the roku2, which was based on a bcm2835!
<clever>
but the rpi doesnt need any of that security, so they flipped all of the switches off
rpnx_ has joined #osdev
<rpnx_>
ah okay
<clever>
with the proper documentation, you could then re-enable it
<clever>
as for things like arm-trusted-firmware
<clever>
the secure/non-secure signal from the arm core isnt wired up
<clever>
so there is no way to have things EL3 can access, but EL1 cant
<clever>
but, the VPU does have its own secure/non-secure signal, and it is wired up to some peripherals
<clever>
if we knew the rules in hardware, we could design something secure around that
<rpnx_>
hum, so there's no way to have secure memory that can only be read by signed code?
<rpnx_>
as in, memory that cannot be read if you desolder chips from the board
<clever>
you can have secure memory, that the arm can just never access
<rpnx_>
but, is that secured at a chip level?
<clever>
there is a dedicated MMU between the arm and the main system bus
<clever>
and that lets you create holes in arm's view of ram
<clever>
there is also a small chunk of SRAM inside the VPU, that you could use
<clever>
it will never leak to DRAM
<rpnx_>
What I was thinking is e.g. encryption keys in secure storage that can only be read by firmware that checks your pin code before giving you the decryption key
<clever>
yeah, all of the secure places i know of, are volatile
<clever>
so the keys will just go *poof* when you cut power
<rpnx_>
saddage :(
<clever>
but there is one rather extreme option available
<clever>
just dont get the arm core access to ANY MMIO!
<clever>
if the arm can only ever touch an authorized block of ram, and nothing else
<rpnx_>
if I encode a key in the firmware, can I made the firmware unreadable?
<clever>
then the arm cant read any storage media, or otp
<clever>
RPF tried that, i still found the keys :P
<rpnx_>
like, assuming I put a decryption key in the firmware, can I make the firmware unable to be read out the chip
<rpnx_>
rip
<clever>
for unknown reasons, the start.elf file will validate that the (UNUSED!) hmac keys in OTP are correct
<clever>
and to protect the big list of keys, they xor'd them with a constant
<clever>
but once you know where to look, you can just undo that, and print every key
<rpnx_>
In order to have security you need to have some kind of flash that can only be read/written by a signed firmware and doesn't leak the data outside the chip
<clever>
yeah
<rpnx_>
since otherwise you can oscilloscope the traces
<clever>
the only viable option right now, is to have a master key in OTP
<clever>
and then use that to encrypt+sign the data stored in SPI
<clever>
snooping the SPI bus wont help with it encrypted
<clever>
modifying the SPI externally will break the signature
<clever>
so you can only perform rollbacks to previously signed states
<rpnx_>
OTP is user-flashable or would that require desoldering a chip and and putting in a new one?
<clever>
OTP is inside the cpu itself
<rpnx_>
did rpi already flash it?
<rpnx_>
It can be flashed once right?
<clever>
each bit in OTP is write-once, and you can set it at any time
<clever>
there is ~2048 bits in total, ~64 slots of 32bits
solenya has joined #osdev
<rpnx_>
I would need to buy a blank cpu to use it? RPF already flashed it? Or they left it blank and it can be programmed?
<clever>
RPF has left a region blank on purpose, for customer use
<rpnx_>
neat
<clever>
but yes, you still have other problems
<clever>
for the pi0-pi3 lineup, bootcode.bin is validated with an hmac-sha1 signature
<clever>
and RPF pre-burned the hmac keys
<clever>
the same key on every pi in the model
<clever>
so anybody can just run an unauthorized bootcode.bin, and dump the OTP
<bslsk05>
www.raspberrypi.com: Raspberry Pi Documentation - Raspberry Pi Hardware
<rpnx_>
so I would need to write asymmetric signature verification inside otp or force it to load a specific loader?
<rpnx_>
hum
<clever>
but that 1st stage you can modify, is always validated by a symetric signature
<clever>
with an already leaked key
<clever>
so your screwed, until you can buy a blank cpu
<clever>
the pi4 changes things some
<rpnx_>
so desolder and put a blank one in
<rpnx_>
Can the cpu be bought on mouser?
<clever>
but where do you buy a blank bcm2835 from?
<clever>
nope
<rpnx_>
really?
<clever>
broadcom is refusing to sell to individuals
<rpnx_>
How come/
<clever>
probably because they want to keep all of the above secret, knowing the above will comprimise the security of other customer devices using the SoC
<clever>
there is also the software license mess
<rpnx_>
Wait is this a flaw in the silicon or flaw in the programming?
<clever>
the official rpi firmware, has a license on it, stating that you must only run it on official rpi hardware
<rpnx_>
I mean that's probably not enforcable.
<clever>
one company managed to buy a sample batch of bcm2835's, and make their own working board
<clever>
then violated the license by running rpi firmware on it
<clever>
broadcom then just refused to sell them more chips
<clever>
so the product was dead
<rpnx_>
That sounds pretty anticompetitive.
<clever>
rpnx_: as for flaws, the bcm2835 maskrom has a timing exploit in it
<clever>
it computes the hmac-sha1 signature of bootcode.bin, then uses a non-constant-time memcmp to compare the expected and actual signature
<clever>
cycle the first byte thru the whole 0-255 range, one of those values will take slightly longer to fail
<clever>
repeat on all 20 bytes, and youve brute-forced the signature
<clever>
now that your in, you can dump the symetric keys, and can just sign anything
<rpnx_>
yikes
<rpnx_>
that's not a cryptographically secure way to sign something
<rpnx_>
What happened to asymmetric signatures
<clever>
the bcm2835 (pi2) rom fixed that timing exploit, but its still symetric
<rpnx_>
wow
<clever>
the bcm2711B1T added rsa support to the rom
<rpnx_>
ok, I don't think I'm gonna try to do anything secure on that board
<clever>
and that is the basis for the locked secure-boot i explained earlier
<rpnx_>
oh, the reason you can't change it?
<rpnx_>
so it can be secured?
<clever>
there are 4 rsa pubkeys etched into the maskrom
<clever>
and 4 bits in OTP, to permanently disable each key
<clever>
a bootcode.bin file then has a footer on it, containing a key-index, and an rsa signature
<clever>
once rsa validation is enabled, it will only ever run official .bin files, and nothing else
<clever>
(until RPF leaks the private keys, or gets hacked, or the keys are brute-forced)
<clever>
the signed bootcode.bin file, then has its own rules to maintain the chain of trust
<rpnx_>
Did broadcom give them hardware keys?
<rpnx_>
or is the maskrom programmable?
<clever>
either broadcom gave RPF the keys, or this is a special variant of the maskrom, that has the RPF keys in it
<clever>
i assume the rom is part of the transistor fabrication step
<clever>
so its in the masks that are used to project light onto the wafer, and make the chip a chip
<rpnx_>
Refusal to sell chips should be illegal. Hum
<rpnx_>
I wonder if a lawsuit could be brought under sherman or clayton act
<clever>
the official bootcode.bin, will check if rsa signatures are enabled
<clever>
and if they are, it will enforce that the customer pubkey in SPI, matches the hash in OTP
<rpnx_>
Are there any retail chips that can be secured?
<clever>
that bit, allows the user to pick their own keys, but also lock it in and never change it again
solenya has quit [Ping timeout: 268 seconds]
<clever>
ive heard something about how x86 cpu's let you program the pubkey into the OTP at boot time, and the bios must then be signed with this key
<clever>
but it was in the context of some rather nasty firmware :P
<rpnx_>
I'm mostly just curious at this point.
<clever>
lenovo? i think it was, would automatically burn the lenovo keys on bootup
<rpnx_>
oh yeah I heard about that.
<clever>
so if you ever use a cpu in a lenovo motherboard, it is now permanently locked to lenovo firmware
<clever>
and can never be used in any other vendors board
<rpnx_>
If that happened to me I would definitely sue lenovo.
<clever>
that design, means anybody (even coreboot) can take advantage of the feature, and create properly secure firmware
<clever>
but in this case, its kinda being misused
<rpnx_>
Well, assuming they didn't ask for consent first
<rpnx_>
hopefully there is some kind of warning dialog
<clever>
i think the problem is that there was none
<rpnx_>
I can see how that could be useful for security but yeah locking a CPU without consent of the owner is anticompetitive 100%
<clever>
you could also do the exact same thing on the pi4
solenya has joined #osdev
<clever>
in theory, i can craft an SD card that will re-flash the spi with my firmware+keys, and turn on all the security in a single go
<clever>
boot that once, and now your pi4 is my hostage :P
<clever>
the SPI even has enough room for https code, so it could phone-home if your kind enough to connect ethernet for me
<clever>
and now i could ransomware your time on the pi
<clever>
give me 1 BTC for every 100 times you reboot :P
<rpnx_>
lol
<clever>
but without timestamping, you could always use a rollback attack to just rewind that counter
<rpnx_>
I wonder if there are any companies that sell CPUs that don't have such garbage practices
<rpnx_>
risc-v?
<clever>
thats probably the direction they are trying to go in
<clever>
but ive not been paying them much attenion
<rpnx_>
user-programmable secure environments are the holy grail of computing freedom
<rpnx_>
there is a great deal of evil trying to prevent that from happening
<clever>
2022-09-03 15:20:31< clever> the official rpi firmware, has a license on it, stating that you must only run it on official rpi hardware
<clever>
2022-09-03 15:20:47< rpnx_> I mean that's probably not enforcable.
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
terminalpusher has quit [Remote host closed the connection]
biblio has joined #osdev
solenya has quit [Ping timeout: 244 seconds]
<froggey>
is there a big table of when you need to use a barrier after modifying an arm64 system register anywhere?
<froggey>
context: I'm loading vbar_el1, then doing isb, but I'm not totally sure that's enough
<froggey>
I'm also not sure where exactly to look to see what I need, and not confident that my other register accesses have proper barriers either
<clever>
froggey: i think the general rule, is when the register impacts how the cpu behaves in situations vbar for example, if you cause a divide by zero on the very next opcode, will it use the new or old vbar?
<clever>
if you enable irq's on the next opcode, the new or old vbar?
solenya has joined #osdev
<wxwisiasdf>
TIL set variable in gdb, this is going to be funny
solenya has quit [Ping timeout: 244 seconds]
<froggey>
clever: thanks, that helps a bit
<clever>
froggey: isb forces that cpu core to just halt, until the write to vbar has completed and anything after the isb will respect the new vbar
<clever>
i'm not sure how external events like an irq would interact, but you would likely just disable irq's until youve set vbar
<froggey>
yeah, irqs are off at this point
<clever>
other registers like the mmu enable bit, have far more drastic effects
<clever>
and if you want to jump to a virtual addr, you must isb, so that the mmu is actually on when you jump there
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
solenya has joined #osdev
<clever>
froggey: the other barrier opcodes (memory ones) are more about ordering of writes to cache/ram/peripherals
solenya has quit [Ping timeout: 252 seconds]
solenya has joined #osdev
<wxwisiasdf>
I have a small hw switch problem :-)
<wxwisiasdf>
So basically everytime i want to task switch I have to update the relevant entry on the idt
<wxwisiasdf>
which is... i guess what you aren't supposed to do
<wxwisiasdf>
am I using the TSS'es wrong? :D
solenya has quit [Ping timeout: 252 seconds]
solenya has joined #osdev
<zid>
isn't offset 0x60 the ldtr
<zid>
but even if it doesn't, an extra ldt op doesn't sound bad?
<wxwisiasdf>
??
<wxwisiasdf>
are you talking about the tss or it's an arm thing?
<wxwisiasdf>
-from the convo above
<CompanionCube>
clever: can has rpi uart recommendations?
<clever>
CompanionCube: do you need bluetooth or are you going to ignore BT?
<CompanionCube>
i don't care about bluetooth
<CompanionCube>
i just moved my pi3 that's been non-booting ~forever from the tv area to the desk so now the layout for a UART works
<clever>
CompanionCube: enable_uart=1 and dtoverlay=disable-bt in config.txt, and youll be able to use the PL011 uart, it will be routed to gpio 14/15, 3.3v 115200 baud by default
<clever>
you can also just cross-wire the uart on 2 pi's together
<CompanionCube>
(side note: the rainbow screen looks pretty good on my monitor, inb4 it's in native 1440p)
<CompanionCube>
i know it's actually 4 pixels scaled up but still
klys has quit [Quit: Lost terminal]
freakazoid333 has quit [Ping timeout: 244 seconds]
wootehfoot has quit [Ping timeout: 244 seconds]
solenya has joined #osdev
mykernel has joined #osdev
<clever>
CompanionCube: what does the display claim the res is?
<CompanionCube>
doesn't say
<clever>
no status ui?
<CompanionCube>
not one that displays resolution, i think?
<clever>
CompanionCube: are you running linux or something custom?
<CompanionCube>
i had a linux install on their
<clever>
ah
<CompanionCube>
but it's ARMv8 instead of the usual ARMv7
<clever>
then the kms drivers will take over and change res soon after
<CompanionCube>
clever: 'doesn't boot' here means get stuck at rainbow screen lol
<clever>
ah
<clever>
which model?
<CompanionCube>
rpi3
<clever>
do you have a spare SD card? try a fresh raspi-os image?
Celelibi has quit [Remote host closed the connection]
<CompanionCube>
i don't *think* i do
<clever>
CompanionCube: would probably need a 2nd pi or uart adapter to get any more debug then, enless you want to backup/wipe the sd card, and then install raspi-os on it