Date: Thu, 15 Jan 2026 20:53:08 +0000 From: Minsoo Choo <minsoochoo0122@proton.me> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: HMP scheduling on FreeBSD Message-ID: <Gl_DSGenjaAOJstxp66xqty6CDV0da--tFlDBbB-R_qWR54_VfM3IqKU3keXunl_c_C-8jFxLaiuOg1p7voUMq1gq_t4n2eGuovfX8FGXbk=@proton.me> In-Reply-To: <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n>
index | next in thread | previous in thread | raw e-mail
On Thursday, January 15th, 2026 at 2:22 PM, Shawn Webb <shawn.webb@hardenedbsd.org> wrote: Hi Shawn, > > Thank you very much for working on this! I've merged the patch locally > on one of my systems running HardenedBSD. I can confirm compilation > succeeds (and boots). > Great to hear. Since the cpucap patch doesn't do anything functional on runtime, it shouldn't have any impact on the system. > > One question I have regarding the security posture of heterogeneous > cores is whether constant-time cryptographic/string/math/etc > operations take between cores. Would it be possible for an attacker to > do <something> by virtue of the different types of cores? > ISA on different cores for a same chip is identical. For example, an Arm heterogeneous chip should provide same Arm ISA version (e.g. v9.3) rather than different ISA for different cores. The scheduler has no idea on the ISA version of a specific binary. However, as David noted, different cores can execute same ISA differently. An example given by David was cpu cycle that takes to access L1 cache, but this can apply for cryptographic instructions as well. > > For example, when installing FreeBSD with a geli-backed root > filesystem, geli determines how quickly cryptographic operations take > and will adjust the number of rounds accordingly. If that operation > takes place on an efficiency core, would that result in fewer > encryption rounds with geli? > > Can some sort of timing oracle exist by virtue of the different cores? > How are speculative execution vulnerabilities manifest? > First of all, knowing the performance difference between cores in absolute scale is impossible because my proposed change (and Linux kernel) normalizes capacity to 0-1024. A relative performance difference, which is normalized to 0-1024 from different sources (e.g. device tree have cpu-capacity that is measured in DMIPS/MHz) can be accessed through sysctl (still being worked on). This sysctl will expose CPU's capacity (static) and dynamic scores (dynamic by cpu throttling, temperature, etc). I will set CTLFLAG_CAPRD for these sysctls so we can add a layer of protection for these information. The measurement (or benchmark) done by GELI on boot is inaccurate on heterogeneous platforms. This is not about pre versus post HMT scheduler support, but if FreeBSD runs on existing devices like Intel Alder lake, GELI encryption and decryption are already done on cores with different performance. In other words, the best method for disc encryption is to have something like Apple's T2 or Secure Enclave. Exploiting the scheduler to run a task (like disc encryption) on a specific core is hard. Attackers can spawn many tasks concurrently and run benchmarks to identify the core's performance, but this information is very unreliable because the task could be moved to other core by load balancer or its interactivity score (however, note that ULE scheduler is by design very harsh on moving tasks between different cores). To speculative execution, they need to retrieve relative performance scale on all cores (thus retrieving relative length of each run queue) and "guess" a task's interactivity score which is very hard and almost impossible, and make there task run in a certain way by faking scheduler to put the job into performance or efficient core. But because a process has no idea on what other processes are doing, guessing interactivity score will be very hard. Side note: ULE scheduler is vulnerable to starvation compared to fairness schedulers like CFS/EEVDF so theoretically a malicious process can intentionally trigger starvation under certain circumstance. However, I haven't heard any use cases of this method. > I'm not expecting an answer to any of these questions. I'm just > writing down some thoughts. But, if anyone can answer those questions, > all the better. :-) > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.aschome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Gl_DSGenjaAOJstxp66xqty6CDV0da--tFlDBbB-R_qWR54_VfM3IqKU3keXunl_c_C-8jFxLaiuOg1p7voUMq1gq_t4n2eGuovfX8FGXbk=>