<muurkha>
well, all FPGAs have some special-purpose logic: typically things like carry chains, clock generators, BRAMs, multipliers, more sophisticated DSP blocks, SERDES, and so on
<muurkha>
adding a microcontroller to that hardly seems unreasonable?
<muurkha>
the smallest Lattice part is something like 1280 4-LUTs, and a LUT is on the order of 100 transistors, plus 64 kibibits of BRAM (say, 6T), so it's on the order of 500k transistors. plausibly an extra 4000 transistors for a small microcontroller like the Intersil 6100, for example, would increase its size by only about 1%
<muurkha>
(though I don't know if RISC-V can scale down that far; if we take cousteau`'s estimate above of 4 transistors per gate and 5 gates per LUT, the 398 CLB LUTs of the Minimax would be 2000 gates or 8000 transistors, plus of course memory
<muurkha>
)
<muurkha>
if we figure a dual-ported register-file bit is about two gates, the register file would be another 8192 transistors, but cutting it down to the 16-register RV32E architecture would be easy and get us down to about 12000 transistors total
<muurkha>
which is maybe a fourth the size of a Cortex-M0
<sorear>
the context was "Microchip makes a SoC FPGA with hard RISC-V cores", which has a near-copy of the hifive unleashed. 5x single-issue in order cores but not normally considered a microcontroller
<muurkha>
that... seems like a totally different thing than what I was thinking
<muurkha>
thanks for the correction
Pokey has joined #riscv
sakman has joined #riscv
FL4SHK has quit [Server closed connection]
FL4SHK has joined #riscv
m5zs7k has quit [Server closed connection]
m5zs7k has joined #riscv
zapb_ has quit [Server closed connection]
zapb_ has joined #riscv
<sorear>
plan "make hwprobe return the actual per-process enabled state of extensions" is not really working because there's only one vvar page (per timens anyway) and __vdso_getpid only ever existed in my imagination
<sorear>
which brings us back to "syscall" and "getauxval" as the only reasonable ways to get per-process data
<sorear>
what kernels actually support Z-extensions in userspace? linux's interfaces are making me cry and freebsd still seems to be at the "AT_HWCAP is a bitmask of single letter extensions" stage
<sorear>
(and V isn't even one of them)
vagrantc has quit [Quit: leaving]
JanC has quit [Ping timeout: 240 seconds]
<dh`>
I have no idea what we have in netbsd, probably nothing
<dh`>
our code is aeons behind because of an internal messup that led to nothing at all being done for multiple years
<muurkha>
> Raw gate density (number of :cell:`sky130_fd_sc_hdll__nand2_1` gates able to fit in 1mm2) for :lib:`sky130_fd_sc_hd` is 266kGates/mm2 and 200kGates/mm2 for :lib:`sky130_fd_sc_hdll`.
<muurkha>
> - Routed Gate Density is 120 kGates/mm^2
<muurkha>
so apparently even if "a gate is 4 transistors" is unreasonably sloppy to a gurki it is good enough for Cypress/Skywater
<courmisch>
sorear: what do you mean? Zb* does not need any special kernel support to work in userspace.
<courmisch>
been using Zba and Zbb on VF2 for a while, though that's *without* checking hwprobe for now
<sorear>
if the user knows for a fact that Zb* is supported then userspace can use Zb* without asking the kernel
<courmisch>
just waiting to get 6.4 or later booting on VF2
<courmisch>
then I can add hwprobe
<muurkha>
:)
<courmisch>
I already wrote the FFmpeg patch, just not submitted because not tested
<courmisch>
also still not sure what about glibc
<sorear>
detecting Zb* at runtime requires kernel support ( signal(SIGILL, not_supported) is an extremely bad idea since risc-v hardware is allowed to implement draft specs or otherwise give nonstandard meaning to instructions that aren't implemented )
<courmisch>
I don't disagree
<courmisch>
I currently just told the compiler that it could use them
<sorear>
and the architecture conformance tests do not check undefined instructions at all, deliberately
<courmisch>
still, IMO, it's a bug in the spec that undefined instructions are not forbidden from bypassing MMU or accessing privilege CSRs
<courmisch>
if you take that literally, it means that you cannot run untrusted code on RISC-V at all
<muurkha>
well, the spec doesn't guarantee that implementations will be secure
<muurkha>
but after all it intentionally supports implementations with only M mode
<courmisch>
that is not really an excuse for having constrained unpredictable in the S and H specs
<courmisch>
+not
<muurkha>
it would be nice to document what an implementation would have to do to be secure against a given threat model
<muurkha>
but there can be several different relevant threat models, and newly discovered attacks over time may show that something previously believed safe is vulnerable to something like Spectre or Rowhammer
<courmisch>
it's not even that hard to write. Essentially just state that any unspecified instruction at a given privilege level can only do something that an arbitrarily complex sequence of specified instructions can do
<courmisch>
at least if the mode is less privileged than second highest privileged mode
<muurkha>
that would seem to forbid, for example, extending the instruction set to support watchpoints or ROM breakpoints, or providing additional performance counters, or providing additional I/O devices
<muurkha>
since none of those are things that an arbitrarily complex sequence of specified instructions can do
<sorear>
what does "specified" mean in a world that has vendor extensions?
<courmisch>
it doesn't forbid watchpoints if they trap to a higher level, there is no contradiction, and if they trap to the same level, you can do the same with existing instructions
<muurkha>
you can't do a watchpoint with existing instructions
<muurkha>
unless you mean that you can run a RISC-V emulator on RISC-V
<courmisch>
no but you can jump to an arbitrary trap handler address with arbitrary register values
<muurkha>
sure, you can do that, if you know when
<courmisch>
that's within the boundary of my definition
<muurkha>
what the watchpoint or ROM breakpoint gives you is knowing when
<courmisch>
if you really want to be explicit, you can say that the instruction need not be reproducible
<muurkha>
if that's within the boundary of your definition, would it still be if U-mode code can set a watchpoint, with a U-mode trap handler, that will be triggered by S-mode code?
<muurkha>
with the memory address and value being written or read in a couple of registers
<courmisch>
branching, modifying registers and memory is all stuff that U can do
<courmisch>
it is not within my definition if the memory is modified in a way that would bypass the MMU
<muurkha>
because, after all, that's just jumping to an arbitrary trap handler address with arbitrary register values, but in this case the register values are data that S-mode wanted to keep secret from U-mode
<courmisch>
muurkha: that's something you can do with a custom system call already.
<sorear>
if you're using bbl to emulate floating point, a "fadd.s" modifies memory not otherwise accessible to U-mode
<muurkha>
if the S-mode code permits it, courmisch
<courmisch>
you can argue all you want against a definition, but when somebody's ISA selection process has explicit security requirements, then no RISC-V
<courmisch>
muurkha: I would argue that your debug extension should not be able to bypass S mode without cooperation from the S mode software, so that's intended
<muurkha>
but this proposed buggy watchpoint facility would allow U-mode code to trace the execution of the kernel and exfiltrate private information
<muurkha>
but it would seem to satisfy your proposed definition (if any U-mode-accessible watchpoint facility would)
frkzoid has quit [Ping timeout: 240 seconds]
frkazoid333 has joined #riscv
<muurkha>
I think defining security in the spec in a way that permits that kind of thing would be useless, but probably actually worse than useless, like most things done in the name of security
<courmisch>
I don't think maintaining process isolation and kernel/user isolation is useless
<muurkha>
I don't either
<courmisch>
and IMO it's untenable not to have a definition for H mode
<muurkha>
I think attempting to reduce security to "any unspecified instruction at a given privilege level can only do something that an arbitrarily complex sequence of specified instructions can do" is useless
<courmisch>
how are you going to explain to VM tenants that, well, isolation maybe works
<muurkha>
you'd better have a better answer than that
<courmisch>
I never attempted to reduce security to that
<muurkha>
I think it's possible to do security right, but it requires a lot more epistemic humility and clarity about threat models than that
<courmisch>
that citation is just me paraphrasing my recollection of Armv8; I don't have any vanity claim about it
<muurkha>
too bad it doesn't include Rocket, and SeRV coming out on top means they didn't take into account instructions per clock
<sorear>
isolation can be easily demonstrated for any given complete ISA
<sorear>
the problem here is with abstraction and quantification
<muurkha>
well, but also threat models
<muurkha>
earlier I mentioned Spectre and Rowhammer
<muurkha>
could also mention cache timing attacks against AES through a hypervisor
<muurkha>
subliminal signaling through a hypervisor via wallbanging
<muurkha>
and power glitching attacks
<muurkha>
so you need to be super clear about what kind of isolation you're talking about, against what kind of attacker
<muurkha>
and the right answer to those quuestions is context-dependent
<courmisch>
strawman. I never said anything to the contrary
<muurkha>
I don't understand what yoou think the straw man is.
<muurkha>
*you
<courmisch>
all I said is that if instructions don't cause an illegal instruction trap, they should not be able to break process or VM isolation any more than specified instructions can
<courmisch>
you can carry Spectre or Rowhammer attacks with specified instructions, so that's outside my argument entirely.
<sorear>
if you expose a page of memory with permissions -W-V, then no RV64GC instruction will be able to read or write from that page, but shadow stack instructions will
<muurkha>
oh, that sounds a lot more reasonable, courmisch
<sorear>
if you define "specified instructions" as "any RISC-V Intl spec implemented by this processor" you can get around this at the cost of making the first self-referential extension
<muurkha>
probably if you sharpen it a bit more you'll have a viable proposal
<sorear>
I think the best you can do is define a "constrained behavior for reserved encodings 2023" extension, enumerate a bunch of cases of allowed behavior, and then just accept we'll have to revise it to accomodate a new standard extension in 202x
<muurkha>
previously you had just said "do something" instead of "break process or VM isolation", which I hope you'll agree is not equivalently clear :)
<sorear>
if you can come up with anything that even remotely looks like a viable proposal I'll help, but I've been trying to solve this off and on for years
<courmisch>
sorear: if the S mode operates without shadow stack, the U mode should not be able to make shadow stack instruction write memory. There's no contradiction with my defs
<courmisch>
AFAIK, shadow stack must be opted-in by S mode to be used by U mode
<sorear>
courmisch: I'm saying that if you write the rules before shadow stacks are specified, then "specified instructions" cannot write shadow stacks
<sorear>
so the rules need to change to account for new behavior allowed by new specified instructions
<courmisch>
sorear: I was implicitly assuming that S mode was not making use of reserved features, but okay
<sorear>
in a way that doesn't allow vendors to do whatever as long as they document it
<muurkha>
sorear: but writing to shadow stacks doesn't break process or VM isolation, right? we just have to be clear enough about what that entails
<sorear>
it permits accessing memory in a way that would otherwise result in a guaranteed page fault. if that isn't "VM isolation" then there needs to be a precise definition
<courmisch>
to be fair, I think Arm did clarify that if an EL uses unspecified stuff, then there are no guarantees about lower ELs at all
<courmisch>
point being, if kernel does not touch the reserved bits that CFI has yet to specify, user should not be able to trigger shadow stack writes
<sorear>
I'm going to call your proposed behavioral requirement a new extension, because that's what behavioral requirements are
<sorear>
does the meaning of your proposed extension change immediately when CFI is ratified or does the extension have to be revised?
drewfustini has quit [Server closed connection]
drewfustini has joined #riscv
<courmisch>
I think it can go either way; that's more of a preference or administrative question.
<courmisch>
not like I could participate in the drafting of this. In the end, my point is that I suspect it'll be a formal problem for some use cases
<courmisch>
meaning some potential RISC-V users won't be able to use it without a clarification in this area
<sorear>
your (?) proposal "as long as S-mode only uses instructions ratified in Jun 2023, all U-mode encodings have behavior explainable in terms of instructions ratified in Jun 2023" is a well-defined extension, although I'd prefer something that doesn't exclude S-mode use of vendor extensions given that we still don't have a ratified instruction for "flush the L1"
<sorear>
why couldn't you participate in drafting?
<courmisch>
because it doesn't fit in my day job
<sorear>
understood
<courmisch>
but at the same time, it's a little too close to my day job for comfort, lets say
<muurkha>
that's too bad :(
<sorear>
actually. let's go with this.
<sorear>
"For any set E of specified extensions implemented by the current hart, if S-mode uses only instructions defined by E and does not invoke reserved or undefined behavior, then the behavior of all possible execution in U-mode is explainable by a sequence of defined instructions from E executed in U-mode, to the extent that is observable using instructions from E executed in S-mode"
<sorear>
extensions are allowed to define joint conformance requirements with other extensions, like all of the C & Zicfiss, H & Zicfiss stuff, so quantifying over all possible sets of extensions means something
<sorear>
the impredicativity _might_ be a problem but the worst it can cause is a logical paradox :)
<courmisch>
should have same text with S->H & U->S
<sorear>
need to think about this in the morning, see if it's incompatible with any defined instructions in a way I can't easily deal with
<sorear>
yes
<courmisch>
and in consideration of muurkha's hypothetical debug extension , should probably clarify that the choice of the "possible execution" may be undeterministic or something
<sorear>
NaN-boxing is an issue, "li a0, 1; fcvt.d.w fa0, a0" (using D extension instructions) creates a state where "fsw fa0, (addr)" stores 0 but "fadd.s fa0, fa0, fa0; fsw fa0, (addr)" stores 0x7FC0_0000 which is not a state reachable using only F extension instructions
<courmisch>
if you take F and D separately, there's an issue, I guess?
<sorear>
yes, this is strictly a matter of state reachability (which unfortunately means that we can only provide strong integrity, not confidentiality, but we already burned that bridge with spectre)
<courmisch>
by that same logic, there's presumably a problem with Q on RV128 ;)
<sorear>
problem exists with Q, XLEN doesn't matter
<courmisch>
ah yes in that direction; I was thinking of the opposite direction
<courmisch>
nvmd
pbsds has quit [Server closed connection]
pbsds has joined #riscv
<sorear>
incidentally, the Zkt extension is null and void because it doesn't protect values loaded from and stored to memory, so the only values that are protected are those that are born and die in registers
<courmisch>
well, here's another reason why I won't be drafting this: you're clearly more knowledgeable at existing and ongoing RISC-V std activities than I am
<courmisch>
as I understand it, this is totally orthogonal to Zkt. CONSTRAINED UNPREDICTABLE makes no requirements on execution time (and Zkt makes no requirements on undefined instructions).
<sorear>
mentioning Zkt because it's the closest thing we have to a specification of allowed nondeterminism
deflated8837 has quit [Server closed connection]
deflated8837 has joined #riscv
<courmisch>
mps: would you know where I can clone the original 40 commits there?
<muurkha>
sorear: that wording would seem to prohibit things like user-level watchpoint or breakpoint facilities, new performance counters, and user-level I/O devices; is that really what you want? or am I misunderstanding in some way?
<muurkha>
maybe it would help to clarify the limitation to internal state transitions
<courmisch>
I don't see how it prevents perf counters? if it's reading some values into some registers?
<muurkha>
new perf counters permit the program to observe things it couldn't observe before
<courmisch>
you can observe it with 2^64 different variants of LLI with a nondeterministic determination of which one of them is used in any given run
<muurkha>
they just don't permit it to reach states it couldn't reach before
<courmisch>
admittedly, this means info leakage cannot be banned, but that's water under the bridge as sorear noted
<muurkha>
an observation contains information; a random number is not an observation in that sense
<muurkha>
what if someone adds a new system call facility? Like, maybe they don't like ecall because the kernel has to waste time saving user-mode registers before it can do useful work
<muurkha>
so they add shadow registers and a new SVC instruction which is like ECALL but invokes a different handler and switches to the shadow registers
<muurkha>
would this proposal prohibit that?
<muurkha>
supposing S-mode doesn't need too use any new instructions to set that up
<courmisch>
if somebody adds a new syscall method, then this spec implies that they would have to define at least one new bit of state for S mode to enable use of that new syscall method
<courmisch>
if (and only if) they don't add an opt-in mechanism for S mode does this spec forbid the new method. IMO that's very much intended behaviour
<muurkha>
they could set that new bit of state with an instruction defined by E
<courmisch>
and that would only be allowed if done by S mode
JanC has quit [Read error: Connection reset by peer]
<mps>
ah, didn't noticed this (and I didn't looked much). thought that vendor and debian are same image
pecastro has joined #riscv
JanC has joined #riscv
junaid_ has quit [Ping timeout: 245 seconds]
<Tenkawa>
courmisch: there is a 6.3 kernel that has been built against mainline vendor + ml sources
<Tenkawa>
even 6.4
<courmisch>
Tenkawa: I know that vendor tree has an upstream branch derived from (now) 6.4 but I am not aware of any vendor release with anything but 5.10 (VF1) and 5.15 (VF2)
<Tenkawa>
I didn't say vendor did I?
<Tenkawa>
that they released it
<Tenkawa>
It is a work of the linux/debian/mainline community
<courmisch>
if you're referring to aurel32's forward-port, it was already mentioned a few hours ago
<Tenkawa>
Yes... and it works quite well l (and btw be sure to give Esmil credit as well if it wasn't)
<courmisch>
seems PCIe is not working very well there though :( I need a better power supply
<Tenkawa>
What are you using for power?
<courmisch>
the USB QC3 adapter that StarFive gave me with the VF1
<courmisch>
but it's only 12V/1.5A
<mps>
I use one which I got with olimex board, 5V/2.5A and I connected it via gpio header and not via usb-c
<mps>
this which come with VF2 is 1.2A max
<Tenkawa>
connecting via gpio will never give you enough current to use stable
<mps>
hm, I didn't had any problem and used it for full year on VF1, and now about one month on VF2
<Tenkawa>
vf1 is a much lower spec unit
<courmisch>
I'd like to keep the board in a box except when fixing the boot, so GPIO header is not really a viable option...
<Tenkawa>
courmisch: I recommend a minimum of of 5V 2.5S
<Tenkawa>
er 2.5a
<Tenkawa>
(I use nvme though heavily)
<Tenkawa>
and usb3 802.11ac wifi
<courmisch>
Tenkawa: that charger is 5V/3V ... 12V/1.5V. Still causing timeouts, especially on non-5.15 kernel
junaid_ has joined #riscv
<mps>
wonder why starfive sent PS with 1.2A max
<Tenkawa>
charger or powersupply?
<Tenkawa>
do "not" use a charger
<Tenkawa>
chargers are very bad
<courmisch>
I can see that
<Tenkawa>
I have 3 bench power supplies I use
<courmisch>
lab supply? way too large and expensive
<Tenkawa>
nah only 35 US a piece
<Tenkawa>
(when I ought them)
<Tenkawa>
er bought
<Tenkawa>
er USD
<courmisch>
I'm not sure how you even draw the line between a charger and a power supply. Eveb USB-IF thinks those are one and the same thing
<sorear>
there isn’t an easy way to search all riscv.org lists at once that I’ve missed is there?
<courmisch>
by which I mean that they're all supposed to implement PD
<sorear>
new performance counters are handled by leveraging implementation-defined behavior; a performance counter is allowed to count anything, so unconstrained U-mode code can make it do anything except count backwards
<sorear>
U-mode access to I/O devices is fine as long as it’s explainable in terms of I instructions. i.e. on RV32GC you cannot have devices with state transitions that are only possible with fsd or AMOs. Might need to carve out an exception here for PCIe
<Tenkawa>
courmisch: chargers do not supply consistent voltage and current output.... they are not designed for the endpoint hardware to care what is being received... only to get current.... that's why they are different
<Tenkawa>
electricl circuits do not like having their power started and stopped constantly
<courmisch>
sure, but that seems more like a problem of cheap crappy hardware vs expensive quality hardware, than charger vs power supply. At least so far I have not found a formal distinction between charger and power supply as far as USB is concerned
<Tenkawa>
no
<Tenkawa>
it is a fundamental known
<Tenkawa>
has been the case especially since sbc's have been around
<Tenkawa>
Broadcom really showed how big of a problem it could be
junaid_ has quit [Remote host closed the connection]
<Tenkawa>
cheers all.. gotta run .... time for today's fun debugging
Tenkawa has quit [Quit: Was I really ever here?]
<courmisch>
meaning I should buy an rPI PSU?
<aurel32>
for me NVME doesn't work well with an rPI PSU
<aurel32>
i have the impression that the problem is not the current it can provide, but the voltage which ends-up being too low for the M2 dc/dc converter
<aurel32>
for me it works well with an old phone charger doing QC, the negotiation ends up at 9V IIRC
<aurel32>
but it switches back to 5V during reboot, so i have to power cycle the board instead of rebooting it for NVME to work properly
<courmisch>
that's kind of what I used for a while, but then u-boot it wouldn't even find NVMe disk
<courmisch>
anybody tried a laptop power supply?
Xark has joined #riscv
<aurel32>
i haven't tried u-boot yet. Does it means that the voltage/power negotiation happens after the u-boot stage?
Xark_ has quit [Ping timeout: 246 seconds]
<courmisch>
more likely it's what you said: I rebooted instead of power-cycled
<aurel32>
i have tried a laptop PSU, it worked well, but i needed it for my laptop, and I found that the old phone charger was working equally well (without u-boot)
<courmisch>
well it's still timing out every so often, making it almost unusable
<aurel32>
i am not using any specific kernel parameters, i still see timeouts, but only a few per day
peepsalot has joined #riscv
<aurel32>
i have the impression that the best PSU for the VF2 would be a dangerous non standard non compliant 9V or 12V PSU with a USB-C connector
<mps>
I don't have yet nvme but I'm using external usb ssd with 5V/2.5A over gpio header and don't have any problem
<courmisch>
who cares about CE labelling
<aurel32>
you can get some of those with low cost cordless power tools, but those are quite dangerous, i would not kept one like that at home
<mps>
on both, VF1 and VF2
<courmisch>
aurel32: is it me or the audio DAC driver is not included in your forward ported kernel?
wigyori has quit [Ping timeout: 250 seconds]
wigyori has joined #riscv
<aurel32>
courmisch: that's correct, so far my goal was mostly to get a working headless setup
<jrtc27>
sorear: the idea in my head for freebsd is to have the kernel export a (sorted?) list of (extension string, version) pairs for which I can then implement the __riscv_get_extension : const char * -> unsigned API that I wished Linux went with
<jrtc27>
ie the thing most people writing code want and care about
<jrtc27>
none of this magic linux-defined constant nonsense
<jrtc27>
and none of this overengineered cpuset-based syscall stuff that is a pain to use for most software that just wants to know "should I use this extension?"
junaid_ has quit [Remote host closed the connection]
<jrtc27>
I mean just look at all the boilerplate linux has to go through to expose a single measly Zbfoo extension
junaid_ has joined #riscv
junaid_ has quit [Client Quit]
junaid_ has joined #riscv
joev has quit [Ping timeout: 245 seconds]
rvalles has quit [Ping timeout: 252 seconds]
joev has joined #riscv
<sorear>
so sparkling hwcap with a nice API?
<sorear>
would you be interested in possibly collaborating on a riscv-c-api-doc for __riscv_get_extension and a compiler-rt/libgcc implementation for linux at some future point? (not committing to availability, and not committing to a usable FSF copyright assignment)
rvalles has joined #riscv
<mps>
aurel32: do you know is there RTC driver for visionfive V2 somewhere (would be nice for headless)
<mps>
I tried to forward port one from vendor github repo and got it load but it doesn't work (loads/unloads quietly) and I don't have idea where to look forward
<jrtc27>
sorear: potentially
<jrtc27>
given it's beneficial for freebsd to not be a weirdo OS that people need to port their code to
___nick___ has joined #riscv
jacklsw has quit [Ping timeout: 252 seconds]
junaid_ has quit [Remote host closed the connection]
<aurel32>
mps: no idea. IIRC there is no connector for the battery, so even if that works dunno if it is useful
<aurel32>
if it loads/unloads fine, but nothing appears it could just be a device tree issue
<aurel32>
i am personnaly using a micro hat with RTC, serial port and few others things
<mps>
aurel32: I thought, so have to look at dts
<mps>
yes, I looked schematic and couldn't find separate line for battery. though maybe use one of 3.3V pin on gpio header