lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
wpwrak has quit [Remote host closed the connection]
wpwrak has joined #milkymist
[florian] has quit [Ping timeout: 245 seconds]
[florian] has joined #milkymist
qi-bot has quit [Ping timeout: 264 seconds]
qi-bot has joined #milkymist
sb0 has joined #milkymist
sb0 has quit [Quit: Leaving]
antgreen has quit [Ping timeout: 246 seconds]
mumptai has joined #milkymist
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
bhamilton has joined #milkymist
mumptai has quit [Read error: Operation timed out]
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
kristianpaul has quit [Ping timeout: 264 seconds]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
* ysionneau
trying to compile gdb 7.6.1 for lm32-elf target
<ysionneau>
FYI a few days ago I got NetBSD kernel to compile and link into a lm32 elf binary
<ysionneau>
Now it's time for debugging and implementation of the few functions I left empty
<ysionneau>
I will be using qemu mostly, with gdb
<ysionneau>
Michael is cleaning up his patches in his mmu branch of qemu
<ysionneau>
wow, awesome, gdb compiled :)
<ysionneau>
great!
<ysionneau>
ok it seems gdb 7.6.1 can connect to qemu-system-lm32 -M milkymist -s -S and do some single stepping
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
bhamilton has quit [Ping timeout: 248 seconds]
sb0 has joined #milkymist
kyak_ has joined #milkymist
kyak_ has joined #milkymist
kyak has quit [Ping timeout: 264 seconds]
kyak_ is now known as kyak
mwalle has joined #milkymist
<mwalle>
hiho
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
<sb0>
hi
<ysionneau>
hi !
<cde>
hi
<ysionneau>
mwalle: about your last e-mail, ok I got it now, I thought that the fact that GDB knows about the CSR id and that qemu knows where to read from when the code is accessing this CSR id would imply that the gdb code inside qemu would also know what to read upon request of this CSR id by gdb client
sb0 has quit [Quit: Leaving]
<ysionneau>
so I guess either gdb client is not requesting info about this CSR id, or either gdb server does not know where to find the value in qemu memory space
<mwalle>
ysionneau: atm it is both
<ysionneau>
ok
<mwalle>
neither the gdb has any support for the new registers nor does qemu
<ysionneau>
well I can see in gdb client source code it has some notions about the new registers
<ysionneau>
at least in its bfd code
<ysionneau>
I guess it's just for desassembling code
<ysionneau>
but it's not enough I imagine
<mwalle>
ok i admit, i haven't actually tried it, i just had a quick look at the source code
<ysionneau>
I guess you're right, it still needs a few tricks to really be aware of those new registers
<mwalle>
and somewhere within the gdb/ directory is a function which returns the number of registrers
<davidc__>
GNUtoo-x60: you still need FPGA vendor tools
<davidc__>
GNUtoo-x60: (though if you're being purist, one could argue the FPGA itself is a non-free dependancy)
<davidc__>
GNUtoo-x60: the FPGA vendor tool situation won't be solved for quite some time (if ever) I imagine
<GNUtoo-x60>
ok
<GNUtoo-x60>
The issue is that we need verifiable hardware...
<davidc__>
GNUtoo-x60: Is this a "wishlist" verifiable, or a "I have a concrete threat model" verifiable
<davidc__>
because one is BS handwaving, the other is something that can be rationally discussed
<GNUtoo-x60>
(it starts becomming hard to really have freedom on common computers...)
<davidc__>
verifiable HW != freedom
<GNUtoo-x60>
Background informations: I already use coreboot on the X60 with only the CPU microcode that is non-free,
<GNUtoo-x60>
(I'll get rid of it if I've the time...)
<davidc__>
Heh, well if you nuke the microcode "patch" there's still the microcode that was originally in it. Whats the difference? Not to mention the stuff in the north bridge; whatevers on your wifi card, probably something on your eth card if its new enough,
mumptai has quit [Quit: Verlassend]
<davidc__>
Not to mention all the micros in common peripherals (keyboard, mouse, usb->sata converter, etc)
<GNUtoo-x60>
if all the remaining stuff is freed( like the NIC firmware, the CPU microcode that is avoided, and so on...), The issue is that I don't know how's the CPU is made:
<davidc__>
Well, you don't know how the FPGA is made either :P
<davidc__>
or the NIC
<GNUtoo-x60>
For instance the RNG isn't probably that good, and using the TPM for RNG wound't solve the problem and randio may be great but it's unproven so far...
<GNUtoo-x60>
I fear more the NIC firmware, because the NIC is on PCI and it has a DMA engine in the NIC...
<davidc__>
hell, if I wanted to backdoor your machine, I'd go after the NIC. 1) directly connected to a routable network, 2) hard to inspect outside of and 3) DMA access
<davidc__>
pfft, who cares about the FW. Do it directly in HW.
<GNUtoo-x60>
for the rest there is no AMT on the X60, too old...
<GNUtoo-x60>
though there is an ec...but it has no network or RAM access etc...
<GNUtoo-x60>
it only could implement a ring-buffer keylogger
<GNUtoo-x60>
anyway I see 2 long-term approaches:
<GNUtoo-x60>
1) free existing hardware: it starts getting problematic:
<GNUtoo-x60>
AMD is not doing so well in buisness...
<GNUtoo-x60>
for Intel it's complicated:
<GNUtoo-x60>
if you take old hardware like the X201, the replacement for the BIOS is fully done(Coreboot, native GPU init etc...)
<GNUtoo-x60>
but the ME is signed
<GNUtoo-x60>
so even if someone succeed to replace its content with something that triggers the watchdog so it doesn't shutdown/reboot after 30min,
<GNUtoo-x60>
I heard that the new hardware doensn't even boot without the right code running on the ME
<GNUtoo-x60>
So a ground-up approach might work better...
<GNUtoo-x60>
Though the FPGA syntetizer issue is a big issuue
<GNUtoo-x60>
My other more practical question was to learn the status of the linux kenrel port on the milkymist one
<GNUtoo-x60>
but I'll probably look for myself
<GNUtoo-x60>
I guess there is no devicetree for that arch...
<GNUtoo-x60>
probably a board file...
<GNUtoo-x60>
and that probably contains every information needed.
<GNUtoo-x60>
ah it does use a dts
kristianpaul has quit [Ping timeout: 245 seconds]
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has joined #milkymist
Gurty has quit [Ping timeout: 245 seconds]
Gurty has joined #milkymist
Gurty has quit [Ping timeout: 245 seconds]
Gurty has joined #milkymist
pablojavier has joined #milkymist
pablojavier has left #milkymist [#milkymist]
<azonenberg>
davidc__: It's going slowly since i have a lot of stuff on my plate
<azonenberg>
i am still interested in doing it
<davidc__>
azonenberg: cool. Yeah, I might be looking at some stuff related to that (looking at generating plasmas for etching / etc)
<davidc__>
I might end up designing a DIY 13.56mhz RF supply + impedance matcher
<azonenberg>
Ooh
<azonenberg>
You want to do RIE or sputtering?
<davidc__>
azonenberg: RIE to complement my SEM
<davidc__>
for RE
<azonenberg>
ooh
<azonenberg>
very nice
<azonenberg>
I'm REing the XC2C32A, not sure if anyone mentioned
<davidc__>
didn't know that - cool
<azonenberg>
i have SEM cross sections and a low-res optical top metal image
<azonenberg>
as well as about 90% of the bitstream figured out
<azonenberg>
working toward a full transistor-level analysis of it
<davidc__>
Nice. Once I get my SEM up and running, reversing FPGA bitstreams seems like a good start... just need to RE one of each type
<davidc__>
(sorry, I meant one CLB/IO/etc of each type)