Age is of no importance unless you're a cheese -- Billie Burke

Hello! I’m Joel and this my personal website built with Jekyll! I currently work at Google. My interests are scheduler, RCU, tracing, synchronization, memory models and other kernel internals. I also love contributing to the upstream Linux kernel and other open source projects.

Connect with me on Twitter, and LinkedIn. Or, drop me an email at: joel at joelfernandes dot org

Look for my name in the kernel git log to find my upstream kernel patches. Check out my resume for full details of my work experience. I also actively present at conferences, see a list of my past talks, presentations and publications.

Full list of all blog posts on this site:
  • 25 Jun 2023   SVM and vectors for the curious
  • 10 Jun 2023   SELinux Debugging on ChromeOS
  • 28 Apr 2023   Understanding Hazard Pointers
  • 25 Apr 2023   PowerPC stack guard false positives in Linux kernel
  • 24 Feb 2023   Getting YouCompleteMe working for kernel development
  • 29 Jan 2023   Figuring out herd7 memory models
  • 13 Nov 2022   On workings of hrtimer's slack time functionality
  • 25 Oct 2020   C++ rvalue references
  • 06 Mar 2020   SRCU state double scan
  • 18 Oct 2019   Modeling (lack of) store ordering using PlusCal - and a wishlist
  • 02 Sep 2019   Making sense of scheduler deadlocks in RCU
  • 23 Dec 2018   Dumping User and Kernel stacks on Kernel events
  • 15 Jun 2018   RCU and dynticks-idle mode
  • 10 Jun 2018   Single-stepping the kernel's C code
  • 10 May 2018   RCU-preempt: What happens on a context switch
  • 11 Feb 2018   USDT for reliable Userspace event tracing
  • 08 Jan 2018   BPFd- Running BCC tools remotely across systems
  • 01 Jan 2017   ARMv8: flamegraph and NMI support
  • 19 Jun 2016   Ftrace events mechanism
  • 20 Mar 2016   TIF_NEED_RESCHED: why is it needed
  • 25 Dec 2015   Tying 2 voltage sources/signals together
  • 04 Jun 2014   MicroSD card remote switch
  • 08 May 2014   Linux Spinlock Internals
  • 25 Apr 2014   Studying cache-line sharing effects on SMP systems
  • 23 Apr 2014   Design of fork followed by exec in Linux
  • Most Recept Post:

    SELinux Debugging on ChromeOS

    | Comments

    Not being an SELinux expert but having to deal with it from time-to-time, I find it may be productive to write some debugging notes. So this post is about an issue that I fixed just this morning.

    Issue: Runtime labeled pseudo-files are not getting labelled

    On ChromeOS, there are Android-specific policies which are combined with the ChromeOS ones. For someone who tries to stay away from SELinux, this is pretty much voodoo.

    Let me start with the last issue. I had to label a procfs file added by a test kernel patch which I am developed. This procfs would then be toggled by ChromeOS’s experiment system to enable the feature and collect data. The procfs file was called /proc/sys/kernel/timer_highres.

    ChromeOS’s SELinux policies live in a repository at src/platform2/sepolicy as of this writing. In this repo, there is a file namedgenfs_contexts which contains genfscon rules.

    genfscon is used to dynamically generate security contexts for pseudo-filesystems such as procfs. This is documented more in the docs here.

    The main issue here was I was making changes to the wrong genfs_contexts file to begin with. That’s easy to do when there are 2 of them. But here’s how I found out that my changes were not getting through to the device:

    1. Make the change to genfs_contexts file to label the proc node I am interested in.
    2. After building and installing the platform-base/selinux-policy ChromeOS package, inspect the device.
    3. Where to inspect? Read the eBuild file sources which is what builds that package. From this I figured that the genfs_contexts was being compiled into a binary located at /etc/selinux/arc/policy.30. I am still not sure what the numeric suffix means, but it does not matter.
    4. Next, use grep to scan this binary for timer_highres, I found that the grep brought back nothing. Confirming that my change had no effect.
    5. Hmm, what if the string was actually some weird encoding and grep could not find it? After all, I know nothing about that binary file’s format.
      1. So copy policy binary file and confirm with seinfo command on a regular Linux machine:
      2. First scp the policy.30 file from the device.
      3. Then on regular Linux, run: seinfo --genfscon=proc policy.30 | less.
      4. Look for the genfscon line for timer_highres in the output.
    6. Modify the correct genfs_contexts file and repeat.
    7. Use ls -lZ to confirm that the procfs file is now correctly labeled.

    Conclusions and Lessons Learnt

    1. Trial and error approach to debugging is OK, but always make sure your changes are being reflected on what is on the device, otherwise you’ll waste a lot of time.
    2. Once a theory is validated, example: “genfscon rule did not get updated”, then stop with step #1, and focus on digging deeper into the validated theory which we know is de-facto correct.
    3. Read the build source files to get a better understanding of how your code changes result in the artifacts. That’s how I learnt the genfscon rule I was adding was getting compiled into the policy.30 file.
    4. Document the issue like in this blog post, and also in the source file being changed so that others don’t run into the issue in the future.