2024-08-07 20:38:15 <mps> if you didn't read https://ghostwriteattack.com/
2024-08-07 20:52:20 <mio> thanks for the link  ... seems the Scaleway Elastic Metal RV bare-metal cloud instances were affected as well
2024-08-07 20:56:45 <mps> yes
2024-08-07 23:39:14 <iggy> that means someone could theoretically send a MR that ran that instruction to do bad stuff on the builders that are running on the scaleway boxes?
2024-08-07 23:43:47 <iggy> might be interesting to test their fuzzer against the pioneer box. I didn't see any mention of the sophon or the spacemit cpu's in there
2024-08-07 23:50:15 <sorear> the pioneer is t-head c920 or c910 depending on who you ask, sophon doesn't have an own core
2024-08-08 00:01:52 <iggy> ahh, yeah, I see it now. And it says RVV 0.7.1 the same as the ones listed in the paper... so... probably vulnerable?
2024-08-08 00:02:23 <iggy> I feel like I remember talk of the vector extensions causing problems already
2024-08-08 07:38:05 <ncopa> how do we disable the vector extensions?
2024-08-08 07:45:35 <ncopa> looks like its done in the kernel. I think we maybe already do so
2024-08-08 07:54:18 <ikke> > GhostWrite renders the CPU’s security features ineffective and cannot be fixed without disabling around half of the CPU’s functionality
2024-08-08 07:54:33 <ikke> Painful 
2024-08-08 08:01:20 <ncopa> they mean RVV extensions
2024-08-08 08:01:27 <ncopa> which I think we already have disabled
2024-08-08 08:20:35 <ikke> ncopa: are they also disabled on the scaleway servers? Last time i checked i believe it was wasn't 
2024-08-08 08:22:03 <ncopa> i dont think they are
2024-08-08 08:22:56 <ncopa> maybe I power them off for now?
2024-08-08 08:44:24 <mps> looks like disabling vector ext. is enough (for now at least)
2024-08-08 08:45:44 <mps> this will impact performance but imo security and stability are 'first'
2024-08-08 09:22:12 <clandmeter> would be nice to know if hide_v0p7_ext is a real fix
2024-08-08 09:22:48 <clandmeter> can an attacker still access the extensions even if they are not advertised?
2024-08-08 09:25:04 <ikke> I suppose the CPU would still execute those instructions if supported?
2024-08-08 09:25:56 <mps> ikke: also I think so but not sure 100%
2024-08-08 09:26:02 <clandmeter> i guess so
2024-08-08 09:27:25 <mps> in my understanding this CPU could be used only in restricted and controlled environment
2024-08-08 09:27:50 <mps> or very isolated
2024-08-08 09:29:09 <clandmeter> yes probably in its current state, until we find out how to disable the extensions in sw. 
2024-08-08 09:29:22 <clandmeter> there is no infromation about this part from what i can read.
2024-08-08 09:35:04 <clandmeter> https://tpaste.us/yY1g
2024-08-08 09:35:21 <ikke> > Luckily, the vulnerable instructions lie in the vector extension, which can be disabled by the operating system
2024-08-08 09:35:54 <clandmeter> https://github.com/cispa/ghostwrite
2024-08-08 09:36:48 <ikke> So not affected/mitigated?
2024-08-08 09:36:59 <clandmeter> im still not sure
2024-08-08 09:37:18 <clandmeter> its how showing a Phyiscal address
2024-08-08 09:37:27 <clandmeter> not*
2024-08-08 09:38:42 <ikke> > If the values stay the same, i.e., you see "caaa" twice, or the application crashes, the CPU is not affected.
2024-08-08 09:39:53 <clandmeter> https://tpaste.us/YY8w
2024-08-08 09:39:58 <clandmeter> looks like affected
2024-08-08 09:40:21 <ikke> Oh
2024-08-08 09:40:37 <clandmeter> i was running it in a lxc container
2024-08-08 09:40:45 <clandmeter> so i guess it was restricted 
2024-08-08 09:40:55 <clandmeter> outside the container this works
2024-08-08 09:41:04 <clandmeter> or does not work, its how you look at it :)
2024-08-08 09:41:31 <clandmeter> so the question is, is it safe to keep the builder running in the container
2024-08-08 09:43:44 <ikke> Hmm, their page says containerization would not mitigate it
2024-08-08 09:47:10 <clandmeter> i dont see a kernel param to disable vector completely
2024-08-08 09:47:57 <mps> it is build time set options to not use vector ext
2024-08-08 09:49:26 <mps> I didn't read does this change depend in which mode (S or M) cpu is running
2024-08-08 10:17:45 <ikke> so it means we would need to rebuild the kernel?
2024-08-08 10:22:16 <mps> do 'we' have bare metal machine on scaleway?
2024-08-08 10:22:38 <mps> for pioneer vector ext. should be disabled
2024-08-08 10:23:31 <mps> or better to use term RVV but it looks somewhat 'cumbersome'
2024-08-08 14:28:17 <clandmeter> mps: can you let me know which part needs to be disabled?
2024-08-08 14:28:29 <clandmeter> then i build a new kernel for the pioneers
2024-08-08 14:39:33 <mps> it should be CONFIG_RISCV_ISA_V=n
2024-08-08 14:40:41 <mps> clandmeter: ^
2024-08-08 14:45:03 <mps> also interesting to read: "CONFIG_RISCV_ISA_V_DEFAULT_ENABLE ->  Say Y here if you want to enable Vector in userspace by default. Otherwise, userspace has to make explicit prctl() call to enable Vector, or enable it via the sysctl interface."
2024-08-08 14:45:31 <clandmeter> Thx
2024-08-08 14:46:04 <mps> so maybe is enough to disable second option but I'm not sure, just wild guess
2024-08-08 14:46:52 <ikke> mps: can non-root programs use prctl to enable the extensions again?
2024-08-08 14:47:45 <mps> ikke: hm, good question. they shouldn't be allowed but I'm far from expert on this
2024-08-08 14:50:17 <ikke> 1https://www.kernel.org/doc/html/v6.11-rc1/arch/riscv/vector.html
2024-08-08 14:50:37 <ikke> Doesn't specify what permissions are required
2024-08-08 14:52:21 <ikke> Cannot be disabled again once enabled for a specific thread, but nothing else
2024-08-08 14:53:48 <ikke> /proc/sys/abi/riscv_v_default_allow just sets the default 
2024-08-08 14:54:01 <mps> yes, and there is knob under /sys
2024-08-08 14:54:27 <mps> ah, you give file name (you are still fast)
2024-08-08 14:55:37 <mps> and it is under /proc and not /sys, sorry
2024-08-08 15:29:41 <sorear> the prctl/sysctl causes vector instructions to SIGILL but doesn't hide the vector extension from hwprobe(), it's a uABI nightmare
2024-08-08 15:30:30 <ikke> sorear: but is it possible for a process to enable them again?
2024-08-08 15:30:36 <ikke> That's the question
2024-08-08 15:30:49 <sorear> prctl yes, sysctl requires root
2024-08-08 15:31:10 <ikke> What sysctl setting?
2024-08-08 15:31:18 <ikke> the one I pasted?
2024-08-08 15:34:57 <sorear> looks like yes
2024-08-08 15:36:08 <ikke> From what I understand, setting that to 0 does not prevent the process calling prtcl with PR_RISCV_V_VSTATE_CTRL_ON, is my understanding correct?
2024-08-08 15:36:26 <sorear> maybe?
2024-08-08 15:36:42 <ikke> The documentation mentions it only sets the default value
2024-08-08 15:36:44 <sorear> i thought there was a sysctl that overrides it but the only one I can find is the one you mentioned
2024-08-08 15:36:49 <ikke> nod
2024-08-08 15:37:04 <ikke> let me check on a rv64 box
2024-08-08 15:37:18 <sorear> moreover we're talking about the upstream RVV 1.0 support, but this is most likely a forked kernel with very different features
2024-08-08 15:38:01 <ikke> right, /proc/sys/abi does not even exist
2024-08-08 15:40:42 <sorear> how much influence does scaleway give you over the kernel / command line / boot process?
2024-08-08 15:41:05 <ikke> I don't know, it didn't seem to use a bootloader from the VM itself
2024-08-08 15:42:02 <ikke> note that our builders are milk-v pioneer boards (still affected)
2024-08-08 15:42:43 <ikke> We have 2 sacelway servers providing CI
2024-08-08 18:07:14 <iggy> scaleway hasn't emailed anyone on the account yet?
2024-08-08 18:10:10 <ikke> It's ncopa's account so he would have received an e-mail if any
2024-08-08 18:10:58 <iggy> gotcha, well, hopefully it's just a reboot or something when they sort it out
2024-08-08 21:22:24 <ncopa> i havent gotten any emails
2024-08-09 10:54:46 <mps> nmeum: in git commit 924f4dd0c8d9712b4de32c0f08c03b63601d23b6 for opensbi you wrote that u-boot needs to be rebuilt
2024-08-09 10:55:51 <mps> I'm not sure that the comment in opensbi is correct "# XXX: Updates require rebuilds of main/u-boot."
2024-08-09 10:56:29 <nmeum> back in the day it embedded the openbsi fw_dynamic.bin payload
2024-08-09 10:56:49 <nmeum> I believe that's still the case or did that change?
2024-08-09 10:57:01 <mps> in my bad inglish 'requires' is misleading, 'should' would be ok imo
2024-08-09 10:57:50 <mps> nmeum: nothing is changed, but word 'require' sounds 'strange' to me
2024-08-09 10:57:50 <nmeum> 'requires' in the sense that opensbi updates wont propagate to uboot unless you rebuild it
2024-08-09 10:58:11 <mps> yes, that's true
2024-08-09 10:59:29 <mps> (I told few times that I don't like to write long commit messages just because I had problem to find correct wording)
2024-08-09 11:00:03 <mps> nmeum: ok, I will leave it is as it is. thanks
2024-08-09 11:00:30 <mps> (huh, again bad wording)
2024-08-09 11:01:33 <mps> anyway, looks like t-head bug could be mitigated by opensbi. "wait and see"
2024-08-09 11:02:09 <mps> Heinrich on #riscv mentioned this
2024-08-09 11:19:39 <mps> nice, sophgo (sg2042) is added to opensbi release 
2024-08-20 00:59:03 <celie> Mentioning this here to make more people aware of it: the "celeste" in #alpine-linux/devel is a different person, not the one from gitlab.alpinelinux.org (that would be me)
2024-08-20 01:02:01 <celie> "celeste" was already registered when i joined OFTC, so instead i registered other nicknames with NickServ, it seems someone has managed to get "celeste" de-registered recently, and is now using that
2024-08-20 06:35:08 <ncopa> ouch, thanks for the heads-up
2024-08-20 18:40:00 <mps> anyone have BPI-F3 ?
2024-08-22 16:45:32 <mps> BPI-F3 which I have is with 2GB RAM and it cannot boot from mmc. software to fix this is available only in binary for windows and x86_64 linux/glibc
2024-08-22 16:46:33 <mps> I don't have windows and on their guide they wrote linux version will not work
2024-08-22 16:47:17 <mps> and software is in Chinese lang only so I don't understand how to work with it
2024-08-22 16:47:59 <mps> so, all in all, I can't get this board working with alpine, for now at least
2024-08-22 17:19:08 <mps> I upgraded linux-starfive kernel to 6.10.6 and testing it locally. for now I don't see problems
2024-08-22 17:19:42 <mps> when riscv64 builder finish with testing it will in repository
2024-08-22 17:23:09 <iggy> thank you
2024-08-22 17:28:36 <mps> np
2024-08-22 17:28:55 <mps> as says, pleasure is mine
2024-08-24 14:59:52 <mps> I upgraded kernel for visionfive V1 board to 6.10.6 and tested it for one day. works fine for now
2024-08-24 15:00:18 <mps> APKBUILD is nearly same as for linux-starfive
2024-08-24 15:00:49 <mps> I can upload it to dev.a.o if anyone wants to test it
2024-08-25 04:01:39 <cely> It seems GCC build times for riscv64 increased from around 6 hours to 8.5 hours when going from GCC 13 to 14
2024-08-25 04:05:46 <cely> When working on GCC 14 at the beginning of this month, i decided to also try a GCC 15 snapshot in CI, and with that, riscv64 build times reached 11 hours 55 minutes :/
2024-08-25 04:08:43 <cely> The CI runner was nbBrusBKa, which i believe is one of the Pioneer boards, so it wasn't the slower Scaleway CI runners (for comparison, other archs (besides loongarch64, which i didn't try) finished within an hour)
2024-08-26 12:06:39 <clandmeter> seems are kernel is pretty safe for the vector bug
2024-08-26 12:07:02 <mps> because it is ancient ;-)
2024-08-26 12:07:41 <clandmeter> just need to watch out when upgrading
2024-08-26 12:08:22 <clandmeter> I still wonder why we were bumping into the issue
2024-08-26 12:08:52 <mps> which one?
2024-08-26 12:09:25 <clandmeter> where packages would think we have vector but our cpu does not support it
2024-08-26 12:09:57 <clandmeter> at least the correct vector version
2024-08-26 12:10:01 <clandmeter> i htink we have 0.7
2024-08-26 12:10:13 <clandmeter> but packages would think we have 1.0 or similar
2024-08-26 12:10:17 <mps> probably
2024-08-26 12:10:28 <clandmeter> so the build crashes with some weird error
2024-08-26 12:11:01 <mps> libc issue maybe?
2024-08-26 12:13:33 <mps> dmesg on pioneer '0.000000] Hide vector 0.7 extension'
2024-08-26 12:16:11 <clandmeter> yes
2024-08-26 12:16:25 <clandmeter> but i guess you need a kernel that can support it?
2024-08-26 12:19:18 <mps> could 6.11 boot on pioneer?
2024-08-26 12:24:53 <mps> this is what cpufetch show on pioneer https://tpaste.us/ggNl
2024-08-26 12:44:04 <clandmeter> i dont really understand this
2024-08-26 12:44:16 <clandmeter> upstream had added this: https://github.com/sophgo/linux-riscv/commit/7f2e2521b04fbc1b11de0ef01d02dddeab5f668e
2024-08-26 12:44:47 <clandmeter> this is simply to remove the vector char from cpu caps
2024-08-26 12:45:10 <clandmeter> but why would it matter if the kernel does not support vector at all?
2024-08-26 14:11:04 <mps> clandmeter: hmm, yes. I don't understand why it is needed at all
2024-08-26 14:17:05 <mps> maybe you would ask on #risvc channel