<whitequark>
pie__: you can also use `udevadm trigger` instead of replugging
<lain>
(because my init system needs its own dns server, right? RIGHT!?!?!?!?)
<rqou>
WTFWTF?!
* pie__
mumbles about eufi
<rqou>
it has that too?
<pie__>
*uefi
<rqou>
WHY?!
<lain>
systemd is borg, etc
<pie__>
rqou, wait you only now fond out about the dns server
<rqou>
it must not be enabled on my system
<rqou>
i use dnsmasq
<lain>
I was told the reasong for systemd-resolved is "pre-boot ssh", but I wasn unable to get further explanation
<pie__>
idki just read about it
<rqou>
which for the most part "just works" and does the correct thing
<rqou>
hmm, pre-boot ssh would be nice, but WHY ISN'T IT JUST A STANDALONE PROGRAM?!
<lain>
the only reason I even know about systemd-resolved is it kept incorrectly overriding my resolve.conf settings, and I was unable to find documentation on how to make it do what I want
<rqou>
hmm, doesn't happen for me
<rqou>
that part must not be enabled either
<lain>
yeah I probably did something wrong tbh
<lain>
but it's still kind of infuriating :P
<rqou>
why can't you just use a reasonably-sane combination of dnsmasq+dropbear ffs
<lain>
I also don't know why you'd even need dns for preboot ssh
<rqou>
dhcp?
<pie__>
awsome, my internet of shit for beginners device is up and running :D
<lain>
pie__: lol
<rqou>
i guess you don't need dns
<pie__>
soon (or not so soon): blink an led because wifi
<lain>
but you /can/ use resolved without networkd, or something
<pie__>
but the systemd ecosystem wide forcepush was still fukken weerd
<pie__>
n-e-way
<lain>
pie__: in general I'm just annoyed by what seems like a serious case of "not invented here" syndrome, but it's possible I'm missing something
<rqou>
and yet nobody has written the "routerd" that i would actually find useful (dhcpd+radvd+avahi+split-brain-dns)
<lain>
my only major practical complaint about systemd, other than the "everything you know is wrong" effect, is at least on one of my systems, journald doesn't seem to be crash-consistent
<lain>
e.g. if a machine crashes, I lose logs leading up to the crash. this isn't a thing that I've had occur with plain text file logging
<lain>
but it's also possible I have misconfigured it, see also: everything I know is wrong
<pie__>
maybe it has to do with the underlying file system
<pie__>
fuck if i know.
<rqou>
meanwhile i seem to be running an unusual-enough configuration (or at least arrived via an unusual-enough upgrade path) that none of these things are enabled
<lain>
(the lack of centralized documentation or detailed manpages is pretty jarring, coming from freebsd)
<lain>
docs and mangpages in linuxland seem to love treating the source code as documentation
<lain>
which it ain't.
<lain>
but I'll stop ranting now
<pie__>
im just going to wait for nixos to be ported to openbsd sometime in the next decades (yeah right)
<lain>
I wish GNU/kFreeBSD didn't die :P
<pie__>
man it would be so much more portable probably if they didnt go more or less all in on systemd at one point
<lain>
the only reason I'm not 100% freebsd is software and hardware compat
<pie__>
im just complaining
<lain>
that and freebsd seems to be dying
<lain>
that could be a cyclic thing though
<pie__>
also openbsd doesnt support some linux kernel features that probably ar eneede dfor nix to work as it does
<lain>
yeah even freebsd's linuxulator (linux kernel ABI presented to linux-branded binaries) just isn't up to snuff for most things I've found
<lain>
at least for desktop use
<rqou>
yeah, linux has a ton of weird random syscalls
<rqou>
like the whole cgroups/namespaces stuff
<rqou>
also the clusterf*ck that is sysfs
<pie__>
yeah openbsd ripped out the linux layer relatively recently
<lain>
I was trying to run 010 Editor (Linux) on freebsd, and it worked all except for.. I couldn't type into it at all
<lain>
keyboard input just didn't work
<rqou>
what
<lain>
mouse interaction worked, the program was otherwise fine
<pie__>
because of lack of maintainence
<rqou>
isn't that supposed to be handled by X?
<lain>
rqou: I thought so, but I honestly have no idea
<lain>
I wound up just starting to re-learn linux at that point
<rqou>
the whole desktop ecosystem is such a mess
<lain>
I used to be all windows on desktops, freebsd on servers... but win10 is a sudden and impressive attempt to make windows as unreliable as possible
<lain>
though it seems like everyone I talk to has just had awful experiences with windows, it's always been rock solid for me, up until win10 started doing what feels like perpetual beta
<rqou>
i would have added these features to dnsmasq though
<rqou>
(or written a completely new implementation using a memory safe language)
<rqou>
wait lain you use windoze, right? :P what the heck is all of the random group policy crap that that novelty SwiftOnSecurity account is always complaining about?
<lain>
I don't follow the twitters, but group policy is sorta like sysctl for windows, in a way
<whitequark>
rqou: group policy is basically a way to change behavior of the system components that's more elegant than "edit random registry entries"
<lain>
^
<whitequark>
and you can do a lot of really sweet stuff using it
<lain>
and behind the scenes it's generally just editing regkeys
<whitequark>
locking down your system, turning off features you don't need or want, etc
<whitequark>
win+r gpedit.msc enter
<lain>
pro tip (which I found the hard way): don't edit group policy from safe mode. or, if you must, be sure to run gpupdate when you boot back into normal mode.
<lain>
gpedit changes don't actually apply in safe mode, and they won't auto-update when you boot back to normal mode
<lain>
(no errors or warnings will be given about this)
<lain>
hmm what was the one other major issue I ran into when locking down my new laptop on win10... iirc we chased it down to a driver bug, but it was only triggered because of a group policy setting
<lain>
oh, right, no. it was an OS bug.
<whitequark>
huh
<lain>
I set the GPO for not enumerating new devices unless someone is logged in to approve them (to prevent DMA attacks when unattended)
<lain>
and iirc fall creators update introduces a bug where certain things, in my case I think it was the AMD GPU, would actually fail to come up pretty regularly
<whitequark>
hm
<whitequark>
if you have PCIe exposed, does it matter that the device is not enumerated?
<whitequark>
sure it won't have its PCI config space written, but does that prevent it from submitting TLVs?
<lain>
that was frustrating, I lost like a week debugging that. when I finally tracked it down after much kernel dump diving and IDAing, I googled and it turns out I'm not the only one. the MS forums are full of complaints that company policy requires that GP for obvious reasons, but they can't use their machines with it enabled, it prettymuch makes them unbootable
<lain>
hm
<lain>
I think it's mostly for thunderbolt, which iirc won't actually give the device PCIe until it enumerates? I may be wrong, I haven't read the spec
<whitequark>
oh yeah it won't
<lain>
luckily this laptop has no DMA-able interfaces so I just disabled that GPO and left it at that
<whitequark>
not with that attitude it doesn't
<lain>
I had only set it because I always do. it was the last thing I expected to cause an unbootable laptop :|
<lain>
haha
<lain>
ok there's probably a USB 3.0 Type-C attack
<lain>
I'd like to look into those some day when I have more time
<lain>
there's probably a pile of attacks just waiting to be found :3
<whitequark>
wait I was thinking of USB-C
<whitequark>
I have Thunderbolt multiplexed over USB-C
<lain>
USB-C doesn't have DMA per se
<whitequark>
and *that* needs OS control for enabling PCIe
<pie__>
(does it matter if i use electrolytic or tantalum? tantalum is what the small tan ones are right?)
<lain>
pie__: yes, it is a decoupling cap between vcc and gnd, it should be as close to the chip as possible and ideally ceramic
<lain>
tantalums are usually yellow
<pie__>
i dont think i have any ceramics
<pie__>
im doing this on a breadboard anyway
<lain>
ah
<pie__>
yeah i meant yellow
<lain>
tantalum is better than electrolytic then
<lain>
(ideally you want low ESR, and usually MLCC/ceramic is lowest, then tantalum, then electrolytic)
Lord_Nightmare has quit [Ping timeout: 240 seconds]
<pie__>
is 100uF 101 or 102? because i also have 10 >_>
<lain>
it calls for 100nF
<pie__>
yeah
<lain>
but, I dunno
<pie__>
i mean the notation is 10En where n is 10^n
<pie__>
just dropping the e
<pie__>
(afaict/afaik)
<lain>
yeah, I have no idea what it is in that notation, I'm used to surface-mount where there are no labels on caps
* pie__
goes and asks ##electronics
Lord_Nightmare has joined ##openfpga
<pie__>
lain, yeah you play hard mode ;P
<pie__>
lain, turns out what i thought is tantalum is actually multilayer ceramic
<rqou>
pie__: those caps you have are probably labeled in picofarads if you have the same ones i'm thinking of
<rqou>
they're indeed ceramic caps, and ime they're quite common in kits but i've never seen or used them anywhere else
Lord_Nightmare has quit [Ping timeout: 276 seconds]
Lord_Nightmare has joined ##openfpga
mumptai has joined ##openfpga
<azonenberg>
yeah i have no idea how to read cap labels
<azonenberg>
i look at the label on the reel
<azonenberg>
and i hope it's right :p
<whitequark>
ceramic cap labels are XXY and they mean X.X*10^Y pF
<whitequark>
atleast the ones I've dealt with
<azonenberg>
whitequark: what i meant is, when you work mostly with tiny SMT stuff
<azonenberg>
there's no labels to read :p
<whitequark>
oh, yeah
<whitequark>
I have an RCL meter
<whitequark>
just in case
<azonenberg>
Hence knowing how to read the labels on a PTH cap is of little value
<rqou>
er, i'm pretty sure it's XX*10^Y?
<azonenberg>
The only PTH caps i have used in a design in the past.... 10 years
<azonenberg>
were 4700 uF electrolytics
<azonenberg>
i think 25 or 50V rated
<rqou>
> ime they're quite common in kits but i've never seen or used them anywhere else
<azonenberg>
You're not getting that in ceramic
<azonenberg>
And probably not in a SMT electrolytic either
<whitequark>
azonenberg: not with that attitude you don't
<azonenberg>
they were bigger than my thumb
<rqou>
heh, wtf
<rqou>
the win7 meltdown fix accidentally mapped pml4 into userspace
<rqou>
azonenberg: ZoidbergKernel wen :P
<azonenberg>
rqou: yeah i heard about that
<rqou>
also no aslr for the pml4 mapping (there is in win10)
<rqou>
azonenberg: how familiar are you with modern kernels? does windows or macos have a "traditional unix style" direct map of physical memory in the kernel virtual address space?
<azonenberg>
rqou: I have very limited familiarity with the fine points of modern kernel stuff
<azonenberg>
I primarily work with bare metal embedded stuff that runs either a minimal RTOS with no scheduling, or no OS at all (just interrupts and a loop or something)
<azonenberg>
(at work)
<azonenberg>
then i do a lot of embedded linux userspace
<azonenberg>
i did a tiny bit of windows kernel driver RE for a gig a while ago but that was basically just a "does it do what it claims to do?" type thing
<rqou>
interestingly, the berkeley operating systems course just assumes that a direct mapping of physical memory is just a normal thing that anybody does
<azonenberg>
does linux even do that?
<rqou>
they don't even mention *) this is a unix-ism *) this doesn't work with the clusterf*ck that is large-memory 32-bit systems especially with PAE
<rqou>
linux still does it, but it has aslr
<azonenberg>
So it doesnt
<azonenberg>
i assumed that they still used virtual memory in the kernel everywhere
<rqou>
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
<azonenberg>
so whats the point of kaslr then? just to hide kernel code?
<rqou>
i think the base address of this is still shifted by kaslr
<azonenberg>
oh, ok then thats not TOO bad
<azonenberg>
Still, i cant imagine what use i'd have for that
<azonenberg>
compared to just mmap'ing pages on demand as i need them
<rqou>
hrm, now i forget why exactly we used it for our class
<rqou>
iirc the memory manager itself would use that window to poke page tables
<rqou>
instead of using a page table self-mapping
<azonenberg>
...
<rqou>
i think linux uses it for dma buffers too
<rqou>
but this is why i wasn't super impressed that our operating systems course assumed that this mapping would exist
<rqou>
afaik "traditional unix kernels" in general used this mapping as a performance optimization
<azonenberg>
i mean in supervisor mode on lower end (no-mmu) pic32 or stm32 parts
<rqou>
(pre-meltdown/spectre of course)
<rqou>
heh, post-meltdown/spectre operating systems and comp arch courses are going to be _fun_
<azonenberg>
your memory mapping is basically 1:1 with physical memory
<azonenberg>
Lol
<azonenberg>
well once cpus get patched
<azonenberg>
it shouldnt be as big a deal
<azonenberg>
i.e. dont speculate an address you dont have permissions to
<azonenberg>
then we can roll back all these OS patches in the new silicon
<azonenberg>
right?
<rqou>
but how do you know you don't have permissions to it?
<azonenberg>
and keep it as a bug shim for older stuff
<rqou>
what if it's not in the TLB?
<rqou>
there was an earlier pre-meltdown/spectre presentation that asked this question and observed that you could break kaslr this way
<azonenberg>
Hmm, you're concerned about timing side channel defeats by using the TLB lookup?
<azonenberg>
One option is to not allow speculation of anything not in the TLB
<rqou>
but that's slow
<azonenberg>
honestly, i dont like the way we use virtual memory for security in general
<azonenberg>
vs doing it at the physical address level
<azonenberg>
and if you had proper tagging of processes (which i think ASIDs help to some degree)
<azonenberg>
you'd be limited to the special case of
<azonenberg>
I have code execution in process X
<azonenberg>
i want to read memory from X
<rqou>
heh, the berkeley teaching kernel doesn't support using ASIDs
<azonenberg>
but I'm sandboxed
<azonenberg>
i.e. basically web browser exploits
<azonenberg>
the "read kernel data" side would be totally mitigated
thallia has quit [Ping timeout: 264 seconds]
<azonenberg>
Since it's not your memory the speculation would be blocked
<azonenberg>
That's how antikernel will do it, at least
<azonenberg>
Antikernel does not attempt to shield a node from itself
<azonenberg>
So there'd be no protections against e.g. speculative execution (if i had that in a future CPU) leaking state from a process to itself
<azonenberg>
However you'd be fully isolated from touching anything else
<azonenberg>
and JIT is explicitly disallowed by design :p
Lord_Nightmare2 has joined ##openfpga
<rqou>
heh, recently i saw somebody link to some code in some JIT that was "compliant with the letter of R^X"
thallia has joined ##openfpga
<rqou>
it set up some signal handlers for illegal accesses
Lord_Nightmare has quit [Ping timeout: 264 seconds]
<rqou>
and if the code tried to execute from a RW page it would change the perms to R^X
<rqou>
and if it tried to write to a R^X page it would change the perms to RW
<rqou>
automagically
<rqou>
brilliant
<rqou>
10/10
<azonenberg>
rqou: see, the way antikernel handles this is simple
Lord_Nightmare2 is now known as Lord_Nightmare
<azonenberg>
The bus from the CPU management system to the TLB is only two bits wide, X is hard-wired to zero
<azonenberg>
You can only set/clear R/W
<azonenberg>
The only thing that can set +x is the ELF loader, which is a separate state machine that can't actually modify data
<azonenberg>
And it never sets +x on a +w page
<azonenberg>
Oh, and the elf loader checks a signature on the elf before doing so
<azonenberg>
So basically it's impossible for any page not in a signed elf to ever get +x set on it
<azonenberg>
and if you ever modify any of that data you become -x forever
<rqou>
except this is only usable for special-purpose devices
<azonenberg>
well you know me,
<azonenberg>
i think that clientside active content in browsers is a fundamentally awful idea
<azonenberg>
a browser should take a single piece of markup and render it
<azonenberg>
then sleep until you click a link
<rqou>
but but azonenberg, i _want_ to be able to hax0r a power plant/gas pipeline/isotope enrichment centrifuge :P :P :P
<azonenberg>
:p
* rqou
is definitely on a list now
* azonenberg
had better be on a couple of Lists
<azonenberg>
otherwise some analyst at $AGENCY needs to get fired
<azonenberg>
(yes, you - hope you're enjoying that government-issued coffee)
<rqou>
just remember to add the TLA "golden key" to the elf loader :P :P
<azonenberg>
lol
<rqou>
make sure you have enough efuse bits to store one key for the NSA, one for GRU, and one for china's PSB
<rqou>
"but but azonenberg, what happens if antikernel gets used by _terrorists_ or attempts to build an arab nuclear reactor? you mean we have to actually use traditional intelligence techniques?!"
<azonenberg>
rqou: you know what they say
<azonenberg>
If Mossad wants you, doesn't matter how good your defenses and tradecraft are
<azonenberg>
You're gonna get Mossad'd
<rqou>
lol
thallia has quit [Ping timeout: 248 seconds]
<rqou>
good point though, I don't hear mossad demanding "golden keys"
<whitequark>
what about CIA
<rqou>
they already have them :P
<whitequark>
no i mean
<whitequark>
they don't say "you're gonna get CIA'd" and there's been a hell of a lot ineptitude coming from there
<azonenberg>
whitequark: honestly my guess is mossad is just like a lot of other TLAs, they have some really good people and a lot of idiots
<azonenberg>
but they're better at keeping a lid on the idiots
<azonenberg>
post Snowden my reaction wasn't "oh wow how could they do that" or "we're way ahead of everyone else"
<azonenberg>
it was more "oh, i guess it was our turn to get caught"
<azonenberg>
give it a few more years, there'll be a massive leaker in some other agency
<azonenberg>
i cant predict which country or agency, but it will happen
<whitequark>
isn't mossad technically a five letter agency
<whitequark>
הַמוֹסָד
<rqou>
lol
<azonenberg>
i dont know how long the Hebrew name is, but i lump them in along with the TLAs :p
<azonenberg>
along with MI5 who isn't technically three *letters*
<rqou>
counting letters is a bit weird in semitic languages though
Lord_Nightmare2 has joined ##openfpga
<azonenberg>
That too
<azonenberg>
implied vowels woo
<whitequark>
"In contrast to the government and military, the goals, structure and powers of the Mossad are exempt from the Basic Laws of Israel." huh
<whitequark>
that's. pretty bold.
<whitequark>
I mean not the fact that the intelligence agency is de-facto exempt from actually following the constitution but stating it openly
Lord_Nightmare has quit [Ping timeout: 248 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
<rqou>
does GRU not officially say that?
<whitequark>
ЭСотрудники ГУ в своей деятельности руководствуются Конституцией Российской Федерации, законами Российской Федерации и другими нормативно-правовыми актами, включая, судебные решения военных судов в системе
<whitequark>
Верховного Суда Российской Федерации.
<whitequark>
so no
<rqou>
huh
<rqou>
also, how does orthography work in russian? why are there a whole bunch of capitalized letters?
<whitequark>
huh?
<whitequark>
the same way it works in english
* azonenberg
guesses it's similar to German where all nouns are capitalized
<whitequark>
no
<azonenberg>
oh, those are just proper nouns?
<whitequark>
yes
<whitequark>
russian bureaucracy just *loves* extremely verbose institution names
<rqou>
hmm, i see that now upon more careful observation
<whitequark>
i mean not just bureaucracy, russian is overly verbose in general
<azonenberg>
whitequark: have you studied German? :p
<whitequark>
but the rest is now just plain out borrowed from english
<whitequark>
english: "hard drive" russian: "накопитель на жестких магнитных дисках"
<whitequark>
shortened to НЖМД which is absolutely unpronounceable
<azonenberg>
in German there's one word for almost anything
<whitequark>
that's because it's an agglutinative language
<azonenberg>
It's just going to be a concatenation of ten smaller words :p
<azonenberg>
Helps me a lot, as a non-native speaker
<azonenberg>
If i can make out some bits of a word i can often figure out the missing bits from context
<whitequark>
i did study german
<whitequark>
for a very little while
<azonenberg>
(then they start *abbreviating* the long words, and any advantage I had is gone...)
<azonenberg>
Hauptbahnhof -> Hbf
<whitequark>
GmbH
<azonenberg>
and that
<whitequark>
how do you even pronounce that
<whitequark>
"Gesellschaft mit beschränkter Haftung" jesus
<whitequark>
my problem with german is that i find the language extremely aesthetically pleasing
<whitequark>
so like i can watch Bundestag meeting minutes the way some people watch porn
<rqou>
and then you can watch HK LegCo meetings and have it sound like people are all yelling at each other :P
<whitequark>
"a derivate form called Unternehmergesellschaft (haftungsbeschränkt)"
<whitequark>
rqou: how many legs does LegCo have
<rqou>
140 :P
<rqou>
oh wait, 136 actually
<rqou>
thanks to the oath-taking drama back in 2016
<pie__>
so hard trying to organize all this junk in a way that i actually have space
<pie__>
x'D
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<rqou>
ugh, i wonder how difficult it would be to just reimplement the core of ABC
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh_work has joined ##openfpga
bitd has joined ##openfpga
sgstair has quit [Ping timeout: 264 seconds]
Bike has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 256 seconds]
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 264 seconds]
Bike is now known as Bicyclidine
rohitksingh_work has quit [Read error: Connection reset by peer]
<eduardo__>
rqou: any news on decap of ice40 ?
Bike has joined ##openfpga
<qu1j0t3>
azonenberg | points for things like "coolest design in a greenpak" // def here for this
<qu1j0t3>
pointfree1: done anything with Anadigm yet?
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
finsternis has quit [Ping timeout: 246 seconds]
finsternis has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
azonenberg_work has joined ##openfpga
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.2/20180316222652]]
finsternis has quit [Remote host closed the connection]
finsternis has joined ##openfpga
noobineer has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
<mithro>
azonenberg: I think separating out into different contest categories or "bonus categories" -- IE $XYZ for most creative use of hard block IP (independent of any other prize)
noobineer has quit [Ping timeout: 260 seconds]
m_w has joined ##openfpga
<awygle>
the docker guy is leaving docker
rohitksingh has quit [Quit: Leaving.]
soylentyellow has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Read error: Connection reset by peer]
<mithro>
Micro8 started of as a minimal set 4 instruction computer By Tim Boscke designed to fit in a 32 Macrocell CPLD. -- http://www.tu-harburg.de/~setb0209/cpu/
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
Bike has quit [Ping timeout: 260 seconds]
<rqou>
there's also the classic (non-free but source available) picoblaze
<rqou>
complete with 16 bit dos mode assembler
<awygle>
azonenberg: i did some math and now i want to make an sgmii torture board
sgstair has joined ##openfpga
digshadow has joined ##openfpga
<rqou>
hmm, rust-on-microcontroller is really really bad for opsec if you leave unwinding enabled (which is unusual but not unthinkable)
<rqou>
this is probably enough to pin down a time range when the binary was compiled
<awygle>
azonenberg: I predict you could double the backplane size and still meet the requirements
<awygle>
without buffers
<rqou>
hmm, in general afaict compiled rust code is very very distinctive even without those asserts and unwinding info
azonenberg_work has joined ##openfpga
<rqou>
so if you're going to hax0r something major, you probably don't want to use rust :P
<rqou>
you don't want to become another paras jha :P :P
<awygle>
did you see that thing about deanonymizing programmers based on their programming style?
<rqou>
oh yeah, that too
<rqou>
but iirc paras jha got ID'd by brian krebs based solely on the particular programming languages used
<awygle>
i don't actually know who paras jha is. i barely know who brian krebs is
<rqou>
paras jha = the guy behind the mirai botnet
<awygle>
ohai azonenberg_work
<azonenberg_work>
o/
<awygle>
rqou: ah. i am aware of the mirai "don't say nikki" botnot
<rqou>
apparently the exact combination of "C#, Java, Golang, C, C++, PHP, x86 ASM, Javascript, HTML/CSS" is somewhat distinctive
<awygle>
azonenberg_work: reiterating what i said to your alter ego above, i think you can run sgmii for 20" over 4 connectors unbuffered without issue as long as you're reasonably careful
<azonenberg_work>
awygle: buuut
<azonenberg_work>
With what receiver?
<awygle>
that analysis is for SGMII qa SGMII
<azonenberg_work>
The xilinx sgmii rx needs 0.625 UI of open eye
<azonenberg_work>
if you oversample vs using a GTP
<awygle>
yeah, no problem. a UI is 800 ps for sgmii
<awygle>
it's possible that bad receivers exist but that was for the sgmii spec as written
<azonenberg_work>
Can you paste the whole analysis to pm?
<awygle>
anyway it makes me want to do an SGMII torture board
<azonenberg_work>
(here)
<azonenberg_work>
(sorry i had to reboot and didnt get a chance to restart irc)
<awygle>
uh yes but not right this second, i am nominally at work lol
<rqou>
azonenberg_work: did you see me mentioning "rust is bad for opsec"?
<rqou>
i wonder how you feel about that
<azonenberg_work>
rqou: how is it bad at opsec?
<azonenberg_work>
metadata?
<azonenberg_work>
at compile time?
<rqou>
unwind info
<balrog>
rqou: how much extra binary size overhead does leaving unwinding on add?
<azonenberg_work>
you really should be doing that in C + asm
<azonenberg_work>
that's very low level stuff
<azonenberg_work>
you should also run strings on the binary
RaivisR has quit [Read error: Connection reset by peer]
<azonenberg_work>
and hexdump and go through
<azonenberg_work>
to look for anything funky
<rqou>
balrog: my blinky that also has a heap, semihosting, and unwinding is 16K
<balrog>
that's... large
<balrog>
:P
<rqou>
in release mode, 38K in debug mode
RaivisR has joined ##openfpga
<rqou>
yeah, but it also has the equivalent of printf, and a heap
<rqou>
so it's not unreasonable
<rqou>
iirc newlib will be that big too
<awygle>
cr1901_modern (ping) was looking at absolute smolness for msp430 rust awhile back, iirc
<rqou>
my experiments (unreleased for now) with musl libc with malloc+printf are 42K
<rqou>
so rust is actually smaller
<rqou>
the rust ELFs are ludicrously big though
<rqou>
the debug ELF is 4MB
<rqou>
azonenberg_work: yeah, but how many people are that careful? several major botnets/malwares have leaked .pdb paths before
mumptai_ has quit [Quit: Verlassend]
<balrog>
rqou: how's avr support?
<rqou>
afaik no llvm backend
<rqou>
oh wait there is now
<awygle>
rqou: false
<awygle>
yep
<rqou>
it got written since i last looked
<awygle>
is avr in mainline rustc yet tho?
<rqou>
no
<rqou>
you probably have to mess with "target files" or whatever
<rqou>
i don't really understand how to do this part
<awygle>
hm, considering how pathetic support was when we got msp430 in i'm surprised lol
<awygle>
it's like four files to patch to just "turn it on", so i'm sure there's some more complicated stuff specific to AVR
<rqou>
i thought it would be a "trivial" matter to add powerpc-linux-musl (which isn't even an enbedded target) and even failed horribly at that
<rqou>
so idk how adding avr would go
<awygle>
also: gotta love a one-line patch that just adds parenthesis... somebody had a bad day for that one
<rqou>
my favorite patches are ones that simply rename Foo.c into foo.c
<rqou>
this is maximum fun when your developers use a "diverse" set of dev environments :P
<awygle>
my "favorite" patches are always the ones that are like "made significant functional change and also changed formatting of 1000 irrelevant lines"
<rqou>
also the guy who created the "nul" crate and actually caused the rust team to break their usual "we don't really moderate" stance
<rqou>
(meanwhile i have the "kik" crate and haven't been sued yet :P)
<rqou>
(it depends on the left-pad crate of course)
<awygle>
a "nul" crate is like a ";-->drop tables" crate
<awygle>
some flexibility on moderation stance is warranted
<rqou>
except ";-->drop tables" isn't actually a valid crate name :P
* awygle
definitely messed up that fake sql injection but you get the idea
<rqou>
btw awygle azonenberg_work you both do embedded stuff. have either of you ever run into a project that had a "con.c" (to handle the console, of course) leading to "fun" support issues?
<awygle>
argh why does rebase show "HEAD" instead of the names of the branches you're rebasing/rebasing onto
<awygle>
rqou: i never really worked on projects that had support until very recently, so no
<rqou>
i can totally imagine devs who came from a unixy environment doing that
<rqou>
and then trying to do handoff to "the new team" that uses windows
bitd has quit [Quit: Leaving]
<rqou>
hmm, apparently rust+avr has some issues
<rqou>
some of which are because of " AVR being the very first in-tree LLVM backend for a Harvard architecture"
<rqou>
azonenberg_work: llvm-pic18 trololololo?
<rqou>
i bet if a bunch of us wrote a pic18 c compiler from scratch it would be no less buggy than the actual shipping mplab one
<rqou>
*no more buggy
user10032 has joined ##openfpga
user10032 has quit [Client Quit]
<azonenberg_work>
rqou: but why would i want to encourage use of that awful isa?
<rqou>
good question lol
<rqou>
it's also a bit weird to me that pic/avr are actually from the "proprietary debug" era of microprocessors
<rqou>
fortunately they're newer than the "proprietary programming" era
<lain>
these days there is hardly a point in using 8bit mcus, except as IP in a silicon or fpga design where a state machine would be too annoying :P
mumptai has quit [Quit: Verlassend]
<awygle>
that's pretty true of 16-bit as well, despite my affection for msp430s
<lain>
yeah
<lain>
32bit arm is pretty dominant
<awygle>
and there was never a very good reason to use 20-bit :P
<lain>
and cost competitive
noobineer has joined ##openfpga
<rqou>
are we rv32 yet? :P
<awygle>
rqou: "cost competitive" :P
<azonenberg_work>
rqou: i havent loked at 81/6 bit pic debug
<azonenberg_work>
pic32 debug is well documented, mips ejtag
<rqou>
some 8 bit pics still require special "bondout" versions
<azonenberg_work>
maybe really old ones
<azonenberg_work>
i dont think any of the current gen ones
<azonenberg_work>
(keep in mind you can still buy the pic12c's with uv eprom in them if you ask)
<rqou>
er, iirc some of the current gen pic10s still do that
<cr1901_modern>
the pic10s I have on hand don't :P
<cr1901_modern>
awygle: I got my Rust firmware to fit into 2kb without much trouble so I'm happy. I'll continue to use msp430 when possible
<rqou>
what's with all the msp430 love here? i've never used an msp430 before
<cr1901_modern>
It's what I'm used to and I resent ARM as a company
<cr1901_modern>
so it's more I want to use ~ARM
<cr1901_modern>
where "~" is the wrong negation operator ._.
<lain>
cr1901_modern: out of curiosity why resent arm?
<rqou>
azonenberg_work: ok, i found one
<rqou>
PIC12F752 still requires a special bondout version for debugging
<rqou>
so PIC12F675 does require a bondout processor
<cr1901_modern>
lain: It's a combination of: They are very protective of their IP (to the point that if you try to make your own impl, they will sue you), and they are quickly becoming the only feasible choice of arch in the embedded world.
<cr1901_modern>
I resent being tethered to the whims of a single company. I don't like it w/ Intel and laptops/desktops either, but that's been an issue for 30+ years and not going away.
<cr1901_modern>
Even 5-8 years ago, I could choose from plenty of archs for a microcontroller project (I've used PIC, AVR, msp430 for different use case) without getting funny stares
<cr1901_modern>
Now it's ARM and (hopefully!) RISC-V. Ppl apparently love those 24/16 extra bits on their data bus.
<balrog>
cr1901_modern: isn't that why Western Digital is throwing lots of support behind risc-v?
<balrog>
(and why 8051 is still so popular)
<cr1901_modern>
balrog: I'm pretty sure WD just doesn't feel like paying ARM royalties anymore, but it's still a good thing :P
<cr1901_modern>
balrog: Yes, 8051 is still extremely popular in some areas, but I doubt anyone _I_ personally talk to is a fan. So I'd get the weird stares still if I tried shoehorning it into a project
<balrog>
no one's a fan
<cr1901_modern>
I mean, I don't think it's that bad. It's a horrible fit for anything besides asm, but I managed last time I used it (2012 ._.)
<azonenberg_work>
rqou: pic12f 350n are still in production
<azonenberg_work>
350nm*
<azonenberg_work>
doesnt mean they're modern
<azonenberg_work>
cr1901_modern: what about mips
<rqou>
it now has interlocked pipeline stages :P
<azonenberg_work>
:P
<azonenberg_work>
lain / cr1901_modern: if you make an ARMv1 implementation i think you are safe re patents
<azonenberg_work>
as long as you dont call it arm
<rqou>
it's also a yellow rabbit that runs away from you :P :P
<azonenberg_work>
(which would be a trademark issue)
<cr1901_modern>
azonenberg_work: Yes, this is what the AMBER core does
<cr1901_modern>
there's just one tiny problem
<rqou>
nobody supports ARMv1
<cr1901_modern>
gcc got rid of armv2 support
<rqou>
imho the "baseline" for a "usable" ARM is ARM7TDMI
<azonenberg_work>
cr1901_modern: lol
<azonenberg_work>
gcc still supports mips1
<cr1901_modern>
Basically, if you put the flags register in the top 6 bits of PC, and remove all the frame handling regs except lr, you get armv2
<azonenberg_work>
which is patent-free and safe as long as youdont use the trademark
<rqou>
yeah, well mips didn't take a detour through 26-bit addresses
<lain>
clearly we should all be using OpenSPARC
<rqou>
if you can get that shit to compile :P
<lain>
haha
<rqou>
iirc you need a solaris machine
<lain>
I wouldn't actually want to use SPARC anyway
<lain>
it seems too goofy
<rqou>
(we are talking about the same thing, right? the T1/T2 code dump?"
<rqou>
)
<cr1901_modern>
azonenberg_work: Well, I've started to like mips a bit over the years. But the world has decided its not relevant (save for pic32)
<cr1901_modern>
For instance, afaik there's no pic32 Rust support. I would've expected it by now if ppl cared
<cr1901_modern>
balrog: I think there's been a _small_ amount of activity w/ pic32. But nobody who'd be able to port it quickly (i.e. has already done a port) wants to do it. And well, everyone else has a nice learning curve.
<cr1901_modern>
So progress is slow
* awygle
feels guilty about not finishing his MC work on msp430
<cr1901_modern>
MC?
<awygle>
the llvm machine code layer
<awygle>
i was trying to get llvm for msp430 to emit binaries instead of assembly
<cr1901_modern>
Oh I don't give a shit about that lol
<awygle>
so as to remove the binutils dependency
<awygle>
well i do :p
<awygle>
i also wanted to do LLD stuff just because it's new and shiny
<awygle>
but i got a job
<cr1901_modern>
It's a lot of extra work for relatively little gain. But I acknowledge that Rust devs like to assume an external assembler isn't called.
<rqou>
somehow the clang/llvm ecosystem just always feels perpetually undocumented
<rqou>
unlike gcc which actually does have somewhat-unbitrotten-and-working "how to write a new backend" tutorials
<awygle>
i will admit i was furious when the msp430 backend wasn't working because lowering one opcode just... wasn't implemented
<awygle>
(i may have used the wrong words there, it's been a while)
<cr1901_modern>
awygle: So you implemented that last opcode lowering?
<awygle>
i felt like llvm was _somewhat_ less of a culture of general assholery than gcc
<awygle>
cr1901_modern: yep
<azonenberg_work>
well gcc is intentionally spaghettified
<azonenberg_work>
They *want* it to be hard to marshal data in and out to external passes
<azonenberg_work>
Because then you can't do a proprietary optimizer/architecture backend on top of gcc
<cr1901_modern>
Isn't there a clause about that in GPL to not deliberately obfuscate?
<balrog>
it's not obfuscation
<balrog>
cr1901_modern: you can't do what nvidia did with the nv driver
<balrog>
rename variables to have meaningless names and whatnot
<balrog>
in the source release
<cr1901_modern>
Oh I didn't know nvidia was "kind" enough to release source
<balrog>
this was the old driver for really old cards
<balrog>
2d only
<awygle>
oh that's right, it was in LegalizeDAG, where it decides to emit libcalls. ISD::MUL was just missing from a case statement. anyway.
<cr1901_modern>
binutils is actually pretty bad too. Don't remember the specifics, but I ultimately found the C identifier I was looking for as part of a sed call in a Makefile.in. Meaning autogenerated headers that aren't documented.
<cr1901_modern>
balrog: Ahhh
<cr1901_modern>
awygle: Well thank you for making Rust on msp430 possible. Even if no one else cares, I do :D
<awygle>
cr1901_modern: lol no problem :D tell your friends
<rqou>
meanwhile i've found the "llvm ecosystem equivalents" for binutils just outright don't work/have missing features
<rqou>
but then apparently i use some really weird features
<rqou>
a big one i remember is using objcopy to turn a binary file into a .o
<rqou>
although if this were a rust project i wouldn't even need to do that
<rqou>
thanks include_bytes!
digshadow has quit [Ping timeout: 245 seconds]
<awygle>
TIL about cargo workspaces
<rqou>
wait, are you using rust at work?!
<awygle>
no, i just checked /r/rust while compiling something lol
<rqou>
didn't feel like swordfighting?
<awygle>
working from home. cats don't know how to hold swords (yet)
digshadow has joined ##openfpga
m_w_ has joined ##openfpga
<rqou>
hrm, the more i dig into the RTFM framework, the more i find that rust is a really really unique programming language
<rqou>
afaik it's the only serious systems language with a "real" type system
<awygle>
i mean... yeah.
<rqou>
and this is all compile-time overhead
<rqou>
so the generated code is just as fast as it would have been otherwise without any of the checking
* awygle
thought that was the point
<awygle>
something i wish was easier to do in rust is make a new type that is, fundamentally a (string, byte array, etc) but with some extra restrictions