<bslsk05>
github.com: century-os/TimerEoi.cc at master · eryjus/century-os · GitHub
<eryjus>
i was wrong
<eryjus>
looks like i needed to rewrite the countdown value and ensure the timer was enabled
heat has quit [Ping timeout: 268 seconds]
<radens>
eryjus: I think I'm doing the same thing but the interrupt handler for the timer just keeps firing?
<radens>
1. I enable the physical counter interrupt source in the local section at 0x40...40 bit 2, I enable the i bit in the daif msr, I write a large tval to cntp_tval_el0, and I set the enable bit in cntp_ctl_el0 and it just keeps firing?
<eryjus>
still digging in my code. it's been a while for arm
<bslsk05>
github.com: century-os/PicInit.cc at master · eryjus/century-os · GitHub
<eryjus>
i know I explicitly disable all IRQs until I re-enable the timer
<eryjus>
radens: any progress? thought I would check before I called it a night
<eryjus>
ahhh... I think i see it. you are writing a 33-bit value into a 32-bit register -- effectively setting TVAL to 0. When TVAL is 0, the interrupt fires.
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<radens>
that might do it
<radens>
thanks
dormito has joined #osdev
freakazoid343 has quit [Read error: Connection reset by peer]
flx has quit [Quit: Leaving]
flx has joined #osdev
Burgundy has joined #osdev
ElectronApps has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052_ has quit [Max SendQ exceeded]
the_lanetly_052_ has joined #osdev
the_lanetly_052_ has quit [Max SendQ exceeded]
the_lanetly_052_ has joined #osdev
[itchyjunk] has quit [Ping timeout: 240 seconds]
[itchyjunk] has joined #osdev
ravan has joined #osdev
wand has quit [Remote host closed the connection]
ravan has quit [Client Quit]
ravan has joined #osdev
wand has joined #osdev
arahael has joined #osdev
diamondbond has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 252 seconds]
elastic_1 has quit [Ping timeout: 240 seconds]
jjuran has quit [Read error: Connection reset by peer]
jjuran has joined #osdev
xenos1984 has quit [Quit: Leaving.]
jjuran has quit [Remote host closed the connection]
jjuran has joined #osdev
elastic_1 has joined #osdev
wand has quit [Ping timeout: 276 seconds]
GeDaMo has joined #osdev
xenos1984 has joined #osdev
diamondbond has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
the_lanetly_052 has quit [Ping timeout: 256 seconds]
Oshawott has joined #osdev
gog has joined #osdev
archenoth has quit [Ping timeout: 252 seconds]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
wille has quit [Ping timeout: 268 seconds]
<gog>
wtf do i do with .data.rel.local sections
<junon>
They're just moving to the inner city, leave them alone
<gog>
:<
<junon>
:D
<gog>
i wonder if there's relocs i'm not pulling in
<gog>
ok the object file has .rela.data.rel.local
<gog>
:|
<gog>
hm
wille has joined #osdev
<gog>
yeah it gives me this section without any relocations so idk what the deal is
heat has joined #osdev
dormito has joined #osdev
<zid>
well it's data
<zid>
and it's rel, and it's also local
<zid>
happy to help
<zid>
Are you doing weird ARM things or some other platform with short immediates
<gog>
no, i have a static initialization with PIC. if i initialize it instead in the entry function it works fine so i think i understand what's happening
<gog>
what i'm confused about is that the final object doesn't have any .rela sections
<gog>
with the static init
<zid>
because they got relasolved?
<Matt|home>
extraordinarily stupid question (im exhausted and the screen is blurry): you can create a malloc() equiv in c without using any c lib functions?
<zid>
Yes.
<Matt|home>
thank you
<zid>
malloc makes more sense as a concept if you consider it just as a function that turns a large array into many smaller arrays
<zid>
all of which is just normal C
<zid>
the large array comes from the OS
<zid>
(sys_mmap or such)
<GeDaMo>
mmap or equivalent
<heat>
BRK TIME
<Matt|home>
just thinking how to include memory constraints.. linux has a really annoying "feature" or lack of safety which i personally hate.. where you can use so much ram that it'll just slow the computer to an unusable state even with swap space
<Matt|home>
i don't like that, i think it's bad design
<river>
i hate when that happens, and when you run out of disk space too
<GeDaMo>
What do you want to happen?
scoobydoo has quit [Read error: Connection timed out]
<heat>
Matt|home, linux has cgroups
<zid>
world's most simple malloc: static uinptr_t base = blah; void *malloc(size_t len) { uintptr_t new = base; base += len; return new; }
<Matt|home>
older versions of windows had it happen too
<zid>
It has trouble with 'free' though
<heat>
you can also completely turn off overcommit, which is always helpful
<zid>
not having memory overcommit makes things dog slow btw Matt|home
<Matt|home>
GeDaMo : my opinion would be setting a hard ram limit per process before you hit swap space that can only be exceeded by performing a very specific set of instructions. that might be a bad idea though
<GeDaMo>
Didn't old MacOS have that?
<heat>
Matt|home, you can also do that
<Matt|home>
idk i only used mac when i was in like..... middle school i think
<heat>
see setrlimit(2)
<heat>
only root can increase its process' limits
the_lanetly_052 has joined #osdev
scoobydoo has joined #osdev
<Matt|home>
yeah precisely that.. except apparently linux never uses it
<heat>
make it
<Matt|home>
anyway, i'll try to write malloc myself later.. a pointless exercise but maybe it'll be fun
<river>
malloc is rather interesting
<heat>
note that process limits have nothing to do with malloc
<heat>
its the kernel that enforces them
<Matt|home>
this isn't really osdev related.. but one of my projects is an objdump clone/editor thingy im working on.. and i had a passing notion of trying to write it without malloc, i have no idea if that'll make a lick of difference tho
<Matt|home>
ja
<Matt|home>
also had a fun idea for breaking a system pretty easily.. edit every executable file you have write access to and make it do something process intensive, like scan for every other writeable executable and make changes. im willing to bet that would slow the boot time to like an hour
<bslsk05>
www.gnu.org: Obstacks (The GNU C Library)
<kingoffrance>
i mean, you are damned either way: overcommit or lots of little tiny allocations as needed
<kingoffrance>
i think the modern assumption for userland at least, is malloc will never fail, or if it does, there are more serious problems
<kingoffrance>
anyways, it seems to be a "feature" that even programs will "overcommit"
<kingoffrance>
because the alternative, can be slow
<kingoffrance>
s/overcommit/request space they might not need right away/
<kingoffrance>
IMO it roughly correlates to inlining perhaps versus many function calls. overhead there too
<kingoffrance>
it is perhaps more a concern for languages/frameworks/etc. trying to make sensible defaults
<kingoffrance>
or for daemons/servers, versus other userland programs
<heat>
no overcommit != lots of allocations
<heat>
the allocation pattern can be the same, you're just aware of how much memory is being used
<kingoffrance>
well i mean there is "waht the kernel actually does" and then programs might try to "manage" their illusions as well
ElectronApps has joined #osdev
<heat>
the only programs that can break with overcommit off are what, programs that do like 2TB worth of allocations?
<kingoffrance>
https://poolp.org/posts/2019-06-02/may-2019-report/ In OpenBSD, the multiple security mechanisms in place to detect memory corruption and invalid access were bypassed by the use of the OpenSSL custom allocator, and the first steps taken by LibreSSL were to ensure that functions such as OpenSSL_malloc and OpenSSL_free where REALLY calling malloc and free, and not something else trying to be “smart”.
<bslsk05>
poolp.org: May 2019 report | poolp.org
<kingoffrance>
that is what i mean...."smart" programs who piggyback
<kingoffrance>
as above, some ppl are against that
<heat>
i'm not seeing your point
<kingoffrance>
theres "what the kernel does" and theres "what userland programs might try to within their own little illusion"
<kingoffrance>
*try to do
<heat>
and what does malloc have to do with it?
<kingoffrance>
should userland programs use malloc directly, or insert another layer between <program> -> <???> -> <malloc>
<kingoffrance>
should they trust malloc, or try to do more stuff themselves
<heat>
that's not about trust
<heat>
malloc is a very important function that can be overridable, like most
<kingoffrance>
its about when free() actually gets called
<kingoffrance>
and do you grab large buffers ahead of time or not
ahalaney has joined #osdev
<heat>
the differences in performance between the different mallocs are definitely not really about that
<heat>
it's mostly a "how does your malloc handle thread contention" game
<heat>
mallocs are actually pretty conservative when it comes to asking for chunks of memory
<kingoffrance>
same thing happens on program shutdown. should you free things ASAP, or just "who cares, when process dies it will all be solved"
<kingoffrance>
same decision there: to free right away, or let things slide
<heat>
its a hard choice because most times you don't have a choice
<heat>
unless you specifically override free() when shutting down
<heat>
which is a great idea now that I think of it
<kingoffrance>
i just mean userland. does the program free as soon as it knows something not needed, or does it wait
<heat>
define something. a page, an object?
<kingoffrance>
anything it malloc()ed.
<gog>
aha! i got it
<gog>
-pic --no-dynamic-linnker
<zid>
or 'how does your malloc deal with specific load x'
<heat>
that depends, do you need to cache it?
<heat>
should you cache it?
<zid>
but for 'specific load x' you just write your own allocator imo
<heat>
don't forget used memory is wasted memory
<heat>
un*
<zid>
No unforgetting
<gog>
no the more unused memory you have the faster your system will be
<gog>
duh
<heat>
WHY IS LINUX EATING ALL MY RAM
<kingoffrance>
you can of course say the same thing about any other resource, file descriptors, whatever else
<heat>
yes
<heat>
if you need the fd later on (and reasonably frequently) keep it open
<gog>
you should never use more than the minimum number of resources necessary and hoard all the rest for when you might need them
<gog>
and never predict when you might need them because you might be wrong
<heat>
you're probably not wrong
<zid>
gog: ikr, imagine if I wanted to suddenly allocate 22GB of RAM and somehow access it all more quickly than it'd take to free what was already there
<gog>
exactly
<zid>
then where would I be!?
<heat>
in jail because you allocated 22GB of ram
<zid>
Best to keep it as empty as possible, and make sure to set all your buffer sizes for kernel structures as small as possible
<zid>
dmesg? 14 lines or bust.
<heat>
amen
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
<zid>
Imagine going camping without emergency water, that's the way I explain it
<kingoffrance>
i think its more daemons, languages, servers, toolchains...
<zid>
And also 180 gallons of empty jugs.
<zid>
When you fall off the mountain you're hiking up, you'll be glad they act like crumple zones
<kingoffrance>
i think old gcc binutils used that obstack stuff (macros) ...no idea modern. i know that because different compilers would need some casting else it wouldnt compile
<heat>
if you want to be fast, most of the time you want to avoid going to the kernel
<GeDaMo>
In that case, just do away with the kernel altogether! :P
<heat>
good multi-threaded malloc just keeps lists of objects per-cpu
<gog>
society has evolved beyond the needs for kernels
<heat>
bad multi-threaded malloc has big locks or lots of calls to sbrk/mmap(which are protected by a huge mutex)
<gog>
also yesterday would have been terry davis' birthday
<heat>
may he glow in the dark forever [*]
<heat>
also
<heat>
WHY DO YOU KNOW THAT
<gog>
some weirdo in another channel said so this morning
<gog>
she's got some obsession with him
<heat>
it's diane
dennis95 has joined #osdev
<heat>
and yes I'm deep into terry a davis lore
<zid>
We're getting to the point where you could reasonably do that in a non-silly way GeDaMo, 128 cores? I think you mean 128 uniprocessors running a kernelspace program each.
<zid>
(with a very thin hypervisor to stop it being mean to other cores)
<gog>
she also likes the unabomber and i relate
<zid>
women love all that though
<GeDaMo>
Communicating sequential processes, each on their own prcoessor
<zid>
They should rename the crime category on netflix to Women's Studies
<heat>
thats how modern computing works
<heat>
see: virtual machines
<gog>
i will confess to true crime stories being a guilty pleasure
<gog>
JCS criminal psychology is a solid youtube channel
<zid>
It's a bit like touching yourself, everybody knows you do it, but nobody admits it in public very often
<zid>
gog: The fact you have favourites at all is the funny part
<zid>
"I'll trade you 3 ted bundy for a unabomber"
<gog>
call it a morbid fascination
<kingoffrance>
i worked at a place the sample database ...customer list was taken from serial killers
<zid>
all those guys get flooded with marriage proposals while they're on death row
<gog>
ugh why
<zid>
it has a clinical name other than "women like a bad boy lol" but I forget it
<gog>
i don't have a sexual interest in them
<zid>
But think, you could drive off into the sunset in an open top convertible
<zid>
then get shot to shit by machinegun fire
<kingoffrance>
stockholm syndrome?
<zid>
HOW ROMANTIC
<gog>
no, that's what my wife and i are going to do when we finally rob a bank
<gog>
i'm gonna stop now because we're way in the weeds of OT
<gog>
lmao
* gog
tries to concentrate on coding
<heat>
i dont understand if r/TempleOS_Official is really good bait or batshit crazy
<heat>
maybe both
<heat>
so i have until monday to make a really important probably life-changing decision
<heat>
no pressure haha
<j`ey>
:o
<j`ey>
job offer?
<GeDaMo>
Marriage proposal? :|
<heat>
j`ey: yup, 2 internship offers
pretty_dumm_guy has joined #osdev
<j`ey>
gl with the choice!
<heat>
one's big and "impossible to refuse", the other one is smaller but way more comfy
cooligans has joined #osdev
<heat>
danke
* cooligans
slaps brenns10 around a bit with a large osmerus mordax
* cooligans
slaps wereii around a bit with a large hypomesus olidus
<cooligans>
xD
cooligans has quit [Remote host closed the connection]
cooligans has joined #osdev
<heat>
GeDaMo, btw i'm pretty sure you can't just "oh yeah I'll have an answer on monday" a marriage proposal :P
<klange>
"I have a number of competing offers."
<gog>
sure you can, it's just not likely to go over well
<GeDaMo>
I don't see why not, it's a big decision, you should be able to think about it
cooligans has quit [Client Quit]
<kingoffrance>
this is another overcommit problem; should you apply places when you really only want one
elastic_1 has quit [Ping timeout: 240 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
the_lanetly_052 has quit [Remote host closed the connection]
cooligans has joined #osdev
cooligans has quit [Client Quit]
dude12312414 has joined #osdev
eryjus has quit [Remote host closed the connection]
<kingoffrance>
(from gcc paper linked above) quote Lazy initializers prepare resources on demand, avoiding the initialization of variables that will not be needed in a particular execution <-- seems like same question for libraries at program startup
<heat>
kingoffrance, you have to touch all the pages you can and see what doesn't get swapped out ;)
srjek_ has joined #osdev
the_lanetly_052 has joined #osdev
<kingoffrance>
eh, we can move on to another topic, it seems more userland
<kingoffrance>
stuff like db servers, tweaking buffer sizes
<kingoffrance>
you can call it the quaqmire allocation scheme ;)
Vercas5 has joined #osdev
<kingoffrance>
*quagmire
<heat>
man 3 giggity
Vercas has quit [Ping timeout: 276 seconds]
Vercas5 is now known as Vercas
<zid>
If you're getting offers you can't refuse my personal recommedation is rubberized bedding
<zid>
helps with the laundry
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
elastic_dog has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
lanodan has joined #osdev
<junon>
I had an interview today and I feel like I bombed it, just wasn't mentally prepared for it and gave weird, airy answers to philosophical questions they had.
<zid>
sounds normal with a bad interviewer
<zid>
too busy asking philosophical questions to actually find out anything
<zid>
If they're asking weird philosophical questions they probably just googled how to give shitty interviews 10 minutes beforehand :P
<junon>
They were okay questions, I suppose pertinent to a degree. I'm just bad at answering them after being trained never to talk about philosophy when I lived in SF since, if you don't follow the agreed upon lore of the world there, you're effectively an outsider.
<junon>
So I've just kind of learned not to talk about them and I resort to kind of side-stepping a real answer.
<heat>
junon, what kind of interview, technical?
<junon>
It was with two technical people, early stage startup, very nice individuals. Today's talk was closer to a "culture" talk, less technical.
<junon>
But was more about whether or not we'd work well together, not a typical "culture" interview.
<junon>
Which is fine, my brain just didn't have a succinct way of explaining my views on certain things.
<junon>
Wasn't expecting some of the questions they asked, and I'm not used to talking about them anyway.
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #osdev
<heat>
woohoo i've ported python
<zid>
to the bin?
<junon>
woah that's huge
<junon>
nice
<heat>
zid: no, /usr/bin ;)
<zid>
symlink /usr/bin/python to rm
<zid>
then python blah.py does the correct action.
<bslsk05>
googleprojectzero.blogspot.com: Project Zero: A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution
Oli has joined #osdev
<river>
yes very fun
<river>
it's like a bonkers remix of ROP and zip bombs
<river>
with a little polymorphic file formats to get going
<river>
who thought human rights violations could be so exciting?
<junon>
Damn NSO is a nasty group isn't it.
<kazinsal>
mossad gonna mossad
<kingoffrance>
eh, a remember a few months ago seeing defensive claims that such things will never affect anyone not xyz (on a list) ...not that that is anything new, but that was a quick turnaround to see something real in the wild
<kingoffrance>
*i remember ; i dont follow these things it was kind of a "these types of things will always be obscure" argument
<kingoffrance>
actually no, someone will find it
<kingoffrance>
not suggesting anything either way, just "genie out of the bottle"
<geist>
i'm mostly amazed at the 'use a turing complete gadget to build a virtual machine'
<junon>
Holy this this exploit is insane
<junon>
holy shit*
<river>
it's pretty swag yeah
<river>
check out geometry of flesh on the bone for more like that
heat__ has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
<junon>
they made a register VM out of an image decoder. that's metal.
<geist>
yeah totally
<j`ey>
i wonder how long this took
srjek_ has quit [Ping timeout: 240 seconds]
<graphitemaster>
You know some nation states probably got a whole bunch of these and a multi-targeting compiler already.
<Bitweasil>
geist, yeah, that's some impressive magic in the exploit.
<junon>
graphitemaster: Israel in particular had this one.
<junon>
So definitely yes.
<Bitweasil>
Anyway, this is what we're up against! Let's make sure that our phones can parse some weird-ass old format because... uh...
<Bitweasil>
I mean, *I* send Xerox scanned images to people, like, almost every... oh, wait, never.
<clever>
i think i had issues with a delphi library under wine, because it tried to initialize the gif and jpeg handlers at startup
<Bitweasil>
I would so love a way to tell my phone, "Dumb messages only, no Memoji, no emoji, no combining diacritical inverse polyphasic watch heartbeat taps, just, like, parse text, and try not to overflow the buffers, k?"
<clever>
and if either failed, it would be a fatal error, even if the app never used them
<clever>
and wine didnt have one of those
<kingoffrance>
thats a vote for "Lazy initializers" surely
* kingoffrance
checks box on clipboard
<clever>
kingoffrance: i just commented out support entirely, and then it ran fine
<geist>
Bitweasil: trouble is dumb mode would still need to recognize and skip over things
<geist>
also a pure dumb phone at this point is almost worse. friend of mine had a flip phone she was carrying around pretty recently
<geist>
and though it was dumb, you could so easily crash it by sending it almost anything that wasn't plain sms
<Bitweasil>
I know, I have one too. KaiOS. Probably not very secure. But has no access to much of anything.
<Bitweasil>
I don't know a good answer anymore.
<Bitweasil>
Pixel and Calyx/Graphene, maybe?
<Bitweasil>
"I no longer can be reached by phone" seems abnormally harsh for other people.
<geist>
dont social i guess. but then you just get labelled a hermit and/or crazy cat lady
<Bitweasil>
Yeah.
<geist>
i think the trick there is just own the label
<geist>
get out the typewriter and start on the manifesto
<junon>
I'm crazy bird dude now. I've come to terms with it.
<junon>
"You never get out of the house man, you should meet up with friends."
GeDaMo has quit [Remote host closed the connection]
* junon
looks around for said friends
<junon>
It's also a pandemic idk what people want from me. It's the first time my hermit-ness is actually the socially acceptable thing to do.
<Bitweasil>
There is that, yes...
<Bitweasil>
Welcome to the new normal. I feel really bad for people in HS/college now...
<Bitweasil>
I'm working on getting a lot back to paper.
<Bitweasil>
Or chalk or something.
<Bitweasil>
Need to get a church calendar going on chalk... we used to have some, don't know what happened to them.
<geist>
a few years back i picked up fountain pens and i found that it really actually makes it enjoyable to write again
<geist>
not that i do it a lot, but it at least nudges it from meh to a fairly okay experience
<junon>
geist: look up vianaic. super fun on fountain pens.
<junon>
I know the guy that made it
<geist>
oh interesting
<Bitweasil>
Ball point pens suck, I know that. :)
<Bitweasil>
I use some felt tip for most of my work.
heat__ has quit [Remote host closed the connection]
heat__ has joined #osdev
<geist>
well, its less so that ball points suck its that i found it a more pleasant experience writing with a good fountain pen
mahmutov has quit [Ping timeout: 268 seconds]
<Bitweasil>
Yeah, I've considered it.
<Bitweasil>
woo. :) I have a new toy for winter break.
<Bitweasil>
Got Qubes hacked into running on some old hardware I have.
<sahibatko>
Hi, I would welcome some hint. Qemu, x86_84, memory map - I get the "Cannot access memory" for the "monitor" command x /1g. It works on one page, not on one other. Can the problem be somewhere else than in the page tables?
<sahibatko>
Now I don't expect a "the problem is at line XY", but perhaps some hints on how to find the cause :)
dormito has quit [Quit: WeeChat 3.3]
<Bitweasil>
On... what, your OS, Linux, ?
<sahibatko>
my OS - to be, (not the host of course, that is Win)
<sahibatko>
geist: qemu does not know the 'info mmu', bt I will check the TLB
<j`ey>
Bitweasil: that looks good
<Bitweasil>
Yeah, I've got a N2+, that's... like that, but more.
<Bitweasil>
With hopefully enough RAM to not be painful.
<bauen1>
Bitweasil: i've been looking at way too many similiar datasheets trying to figure out if there's an affordable (like sub 200 usd) arm sbc that has some sort of secure boot that isn't completely broken. Turns out I'm expecting too much
<Bitweasil>
Pi4: Slow CPUs and 8GB of RAM. N2+: Twice the CPU performance, painful on RAM.
<Bitweasil>
The Pis are broken, they don't implement the secure RAM capabilities they advertise.
<clever>
bauen1: the pi4 and cm4 has some secureboot logic, but no secure ram
<Bitweasil>
I don't know if ODroid has the ARM trusted firmware properly working for secure mode and such, but I don't think there's a way to root of trust them.
<Bitweasil>
And I don't know if they implement secure RAM either. :(
<bauen1>
clever: the pi4 has secureboot ? i though raspberry pi had virtually nothing in terms of static root of trust
<clever>
bauen1: the soc has always had a trust root, and starting with the pi4 the firmware now allows using it
<samis>
doesn't the pi also re-use the trust thing as an checksum, but in a broken way or something?
<clever>
for the pi0-pi3 lineup, it was an hmac-sha1 signature on bootcode.bin, with half of the key in the OTP
<bauen1>
the closest to what i want so far has been https://www.96boards.org/product/avenger96/ ; from experience with STs microcontrollers they seem to actually implement their hardware properly ...
<clever>
for the pi4 b1t and c01, there is proper RSA signature checks
<clever>
c0t*
<clever>
samis: the original bcm2711b0t soc also had just hmac, and was basically abusing it as a checksum
<clever>
bauen1: when the secureboot is fully enabled, youll have an rsa signature (broadcoms keypair) over the bootcode.bin, then a second rsa signature over the config and boot.img (a keypair of your own creation), boot.img then contains a fat32 disk image with the /boot contents
<clever>
and then its up to whatever kernel.img you put in there, to maintain the chain of trust
<Bitweasil>
This is the NDA'd CM4 bits, IIRC?
<bauen1>
clever: interesting, i'll take another look ; i had originally discarded all raspberry pis because they required quite a few blobs for actually booting and the open-source reverese engineering effort stopped
<Bitweasil>
clever is busy reverse engineering and re-implementing those blobs.
<clever>
Bitweasil: the docs have been on the usbboot repo for several months, forum moderators still claim you need to sign the NDA, lol
<bslsk05>
raspberrypi/usbboot - Raspberry Pi USB booting code, moved from tools repository (131 forks/490 stargazers/Apache-2.0)
<clever>
bauen1: for the secureboot to work, you currently rely on those blobs, and because the trustroot is broadcoms rsa keypair, you cant use rsa as your trustroot
<Bitweasil>
thx
<clever>
rsa is disabled by default, so you could use the write-protect pin as your trustroot
<bauen1>
clever: what do you mean by write-protect pin ?
sdfgsdfg has joined #osdev
<clever>
bauen1: the boot firmware is held on an SPI flash chip, if you tie its write-protect pin, then you dont need to validate its contents
<Bitweasil>
(a physical pin on the chip)
mavhq has joined #osdev
<bauen1>
clever: my goal is to have a root of trust inside the SoC, so not just protected from software attacks but also basic physical attacks (as in: exchange microsd card, plug in some cables, add a jumper cable, maybe resolder some chips)
<Bitweasil>
Uh.
<clever>
bauen1: ah, then your only option is to rely on the closed source bootcode.bin and trust broadcom's rsa keypair
<Bitweasil>
Not gonna happen.
<corecode>
can't you circumvent the pulled down pin?
<Bitweasil>
No offense, if your attack model includes "resolder some chips," there is no such thing as secure boot.
<clever>
Bitweasil: the secureboot is handled inside the soc
<Bitweasil>
A sufficiently skilled attacker with physical access is going to get access one way or another.
<Bitweasil>
IMO.
<clever>
once enabled, the soc will only run code signed by a keypair of your own creation
<clever>
no resoldering of chips can work around that
<clever>
other then replacing the soc itself
<Bitweasil>
It's an OTP, yes?
<clever>
yes
<Bitweasil>
You familiar with FIBs? ;)
<clever>
thats beyond just resoldering chips :P
<corecode>
some people do probing through the bulk silicon
<bauen1>
Bitweasil: yes, i've figured out quickly that it's mission impossible if you don't have a budget >10k usd
<corecode>
but it is very costly
<Bitweasil>
It's the same class of attack, IMO. Physical access.
<Bitweasil>
But, yes, it does require a bit more hardware.
<Bitweasil>
(sorry, focused ion beam, it literally lets you edit chips and re-close fused OTPs)
<corecode>
5 orders of magnitude?
<clever>
bauen1: when you turn the soc on, it will begin running code from an internal mask rom
<corecode>
of financial commitment
<bauen1>
Bitweasil: yeah, i'm just trying to see how "secure" i can make it against physical access, granted if you know how to resolder, have some fpga and electrical knowledge then you can probably try to power glitch the bootrom to bypass the bootloader verification
<clever>
bauen1: from the factory, a bcm2711 is configured to only check the next stage with an hmac-sha1 key, which i have cracked, so that doesnt offer much security
<corecode>
and maybe 3 orders of magnitude in time investment
<clever>
bauen1: but the secureboot docs in the usbboot repo above, describe how to turn on the broadcom rsa key, and disable jtag
<clever>
at that point, only a recovery.bin or bootcode.bin signed by broadcom can boot, and nothing else
<clever>
the official bootcode.bin will expect to find a pubkey.bin in the SPI flash, and a hash of that pubkey in OTP
<corecode>
clever: how did you crack that hmac key?
<clever>
and everything else must be signed by that user-created RSA key
<clever>
corecode: i dumped the boot rom, its just an xor of a constant in the rom and a semi-constant in OTP
<corecode>
oh
<corecode>
you extracted it :)
<clever>
yeah
<clever>
while the rom supports per-device keys, RPF isnt using that
<clever>
so every single pi4, cm4, and pi400, is using the identical key
<Bitweasil>
Anyway, I agree, what's being proposed here *radically* increases the difficulty to attack.
<Bitweasil>
I don't know how much you can pot a CM4, but that would make life harder too.
<Bitweasil>
(I assume you can pot most of not-the-heatsink-area, though it may impact performance as the thing uses the board to cool)
<bauen1>
clever: i think that would be a nice middle way, i'm just not very keen on blobs from manufactures, they tend to contain (security) bugs and usually not few.
<clever>
bauen1: the bcm2835 (pi0/pi1) did have a timing exploit in its hmac-sha1 code, a non-constant-time memcmp
<clever>
so you can just iterate over all 256 possible values for the first byte of the signature, and know which guess was right
<clever>
then repeat on the next byte
<bauen1>
clever: that's not very surprising
<clever>
it was fixed in the pi2 bootrom
<Bitweasil>
ARMv8 adds a DIT bit - data independent timing, so even things like multiples or SHA/etc will be constant time if they could otherwise be optimized.
<clever>
assuming the broadcom rsa pubkey is burned into the rom, there is basically no way to do secureboot with fully open source firmware
<clever>
i would need to either crack the rsa key, or settle for the already cracked hmac-sha1
<clever>
and at that point, its not secure
<clever>
you would be relying on the spiflash chip to not be replaced
<bauen1>
clever: i reverse engineered parts of the allwinner h6 and a64, they implemented an rsa signature of the bootloader, with the pubkey hash in otp, but the secure bootrom has more bugs than things that work correctly, so it's literally trivial to bypass
<clever>
ive not dumped the rsa bootrom yet
<bauen1>
apart from that it would have allowed for a fully open source (ignoring bootrom) secure boot setup
<clever>
bauen1: i have got fully open firmware working on the pi2 and pi3
<clever>
but it relies on the existing hmac-sha1 trustroot
<clever>
which is disabled by default
<mxshift>
Re: SPI flash write protect pins. Those often don't do what you expect.
<clever>
mxshift: it only protects the memory protection register, not the flash itself
<mxshift>
Micron MT25Q parts basically ignore it unless turned on in a config register. Even then, there are multiple layers of config for which sections of the flash are protected
<clever>
so you need to configure the memory protection first
<mxshift>
In a few devices, there is a password-based unlock that, if you don't provision, leaves you open to DoS attacks
<clever>
for the spi shipped with the rpi4 line, its just a simple memory split
<clever>
the top half is protected, the bottom half isnt, and a config register defines where the split is
<clever>
and the pin only protects that config register
<mxshift>
As usual, define your threat model before trying to mitigate attacks
<zid>
mxshift: really big hammer
<clever>
mxshift: but also, the bootrom only cares about the first ~128kb of the flash, so you always need to protect the entire flash
<clever>
basically, the rom will spit out a standard spi flash read (03h was it?) command, then an infinite stream of 00h's (the first few become the addr to read from)
<clever>
it will then expect a magic# (and ignore up to 4 or 5 bytes of nulls before the magic), a 32bit length, and then $length bytes of payload
<clever>
the variable number of nulls being ignored before the magic#, enables a variable byte-width for the SPI addr
<clever>
so the rom can read from any sized SPI chip
<mxshift>
That's clever and annoying
<clever>
the payload itself, is the raw bootcode.bin/recovery.bin format
<clever>
the binary gets loaded into the L2 cache, and the signature gets validated
<clever>
and if valid, it jumps to 0x8000_0200
<mxshift>
What does it do if I give a size larger than the l2 cache?
<clever>
id have to review the code, but i think it will error out
<mxshift>
It should but it's also one of those things firmware engineers rarely think about
<clever>
the boot.img (for secureboot stuff) did have a rather small size limit
<clever>
that caused it to just silently truncate the file
<clever>
and then the buffer doesnt match the signature, so the boot fails
<clever>
mxshift: for the whole pi0-pi3 lineup, the rom supported booting from 8 different sources!
<bslsk05>
github.com: rpi-open-firmware/rom.txt at master · librerpi/rpi-open-firmware · GitHub
<clever>
3 of them are SD cards in different modes, nand flash, spi flash, usb (host or device, depending on model), i2c-slave, and something called mphi
<clever>
OTP configures which modes are enabled, and what pins to use them on
<bauen1>
arm SoCs are wild, they can boot from basically anything ; i guess it keeps the BOM down if you don't need to add an SPI Flash to your board just to get linux running
<clever>
all of the above happens before the arm core is even turned on
<clever>
the bcm2711 cut back massively
<clever>
it only supports one SD mode, spi flash, and usb-device, nothing else