Re: Side-channel attacks (Meltdown, Spectre)
On Fri, 5 Jan 2018 22:38:39 +0100 Alexander Boettcher (AB) wrote: > > I am not following the recent development of all those kernels, so I > > think it's best to directly consult the individual developers/teams for > > statements (like the one from Stefan above). > > > > For my part, I can tell you that the NOVA microhypervisor (at least the > > official version) does not map physical RAM into the kernel virtual address > > space, other than the RAM in which microhypervisor itself resides. NOVA maps > > certain devices (like APIC, IOMMU), but those can't be speculatively > > accessed anyway. I cannot comment on modified NOVA versions. > > I for my part, can confirm that the slightly, cough, modified NOVA > version [1], as used by Genode, kept the original behavior of the > official NOVA version [0] in that regard. An addition after looking at the old code some more: Note that Pd::kern, i.e. the kernel PD, actually has all physical memory mapped 1:1, simply to have an elegant (non-special-case) way to establish the root of the mapping hierarchy. However, no user thread ever runs in Pd::kern, so those mappings cannot be speculatively abused. In PDs, where user threads do run, physical memory is not mapped in the page tables. Cheers, Udo pgpJAAXDYT8Ng.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Side-channel attacks (Meltdown, Spectre)
> I am not following the recent development of all those kernels, so I > think it's best to directly consult the individual developers/teams for > statements (like the one from Stefan above). > > For my part, I can tell you that the NOVA microhypervisor (at least the > official version) does not map physical RAM into the kernel virtual address > space, other than the RAM in which microhypervisor itself resides. NOVA maps > certain devices (like APIC, IOMMU), but those can't be speculatively > accessed anyway. I cannot comment on modified NOVA versions. I for my part, can confirm that the slightly, cough, modified NOVA version [1], as used by Genode, kept the original behavior of the official NOVA version [0] in that regard. > Some commercial kernels and L4/Fiasco certainly used to map as much physical > memory as can fit into the kernel address space. Not sure if Fiasco.OC > retains that behavior. Check for Physmem in class Mem_layout. > > Also any kernel that performs certain things like long IPC via a lazily > flushed IPC window may have transient mappings of memory belonging > to other user processes. Thanks for the insights, Alex. [0] https://github.com/udosteinberg/NOVA [1] https://github.com/alex-ab/NOVA/tree/r9 -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Side-channel attacks (Meltdown, Spectre)
On Sat, 6 Jan 2018 04:20:25 +0100 Stefan Kalkowski (SK) wrote: > On Fri, Jan 05, 2018 at 08:24:19PM +0100, Alexander Boettcher wrote: > > > > On 05.01.2018 17:36, Udo Steinberg wrote: > > > Norman Feske (NF) wrote: > > > > > > NF> In contrast to monolithic kernels, a microkernel like base-hw, NOVA, > > > NF> or seL4 does not deal with any user-level content like cryptographic > > > NF> secrets, or the content of files. There is hardly any credential to > > > NF> leak to begin with. User content stays outside the microkernel. > > > > > > While it is true that a microkernel stores significantly fewer secrets > > > than > > > a monolithic kernel, like Linux, most microkernels actually have a full > > > mapping of the entire physical memory in the kernel portion of each > > > address > > > space, which allows an attacker to peek anywhere into physical memory. > > > > before starting to dig/read through all our supported kernels (I'm not > > all familiar with the internals) - can you please elaborate a bit about > > which microkernels, according to your knowledge, have all physical > > memory mapped in the kernel ? > > > > The currently supported microkernels for Genode are Pistachio, OKL4, > > L4/Fiasco, Fiasco.OC, Nova, seL4 and our own hw kernel. > > I can warrant that the hw kernel, which is actually Genode's core > component combined with a bit of architectural dependent > data-structures (e.g. page-tables) and routines, does not contain > physical memory mappings used by user-level components. Hi, I am not following the recent development of all those kernels, so I think it's best to directly consult the individual developers/teams for statements (like the one from Stefan above). For my part, I can tell you that the NOVA microhypervisor (at least the official version) does not map physical RAM into the kernel virtual address space, other than the RAM in which microhypervisor itself resides. NOVA maps certain devices (like APIC, IOMMU), but those can't be speculatively accessed anyway. I cannot comment on modified NOVA versions. Some commercial kernels and L4/Fiasco certainly used to map as much physical memory as can fit into the kernel address space. Not sure if Fiasco.OC retains that behavior. Check for Physmem in class Mem_layout. Also any kernel that performs certain things like long IPC via a lazily flushed IPC window may have transient mappings of memory belonging to other user processes. Cheers, Udo pgp396jAy1i9W.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Side-channel attacks (Meltdown, Spectre)
Hi, On Fri, Jan 05, 2018 at 08:24:19PM +0100, Alexander Boettcher wrote: > Hi Udo, > > On 05.01.2018 17:36, Udo Steinberg wrote: > > Norman Feske (NF) wrote: > > > > NF> In contrast to monolithic kernels, a microkernel like base-hw, NOVA, > > NF> or seL4 does not deal with any user-level content like cryptographic > > NF> secrets, or the content of files. There is hardly any credential to > > NF> leak to begin with. User content stays outside the microkernel. > > > > While it is true that a microkernel stores significantly fewer secrets than > > a monolithic kernel, like Linux, most microkernels actually have a full > > mapping of the entire physical memory in the kernel portion of each address > > space, which allows an attacker to peek anywhere into physical memory. > > before starting to dig/read through all our supported kernels (I'm not > all familiar with the internals) - can you please elaborate a bit about > which microkernels, according to your knowledge, have all physical > memory mapped in the kernel ? > > The currently supported microkernels for Genode are Pistachio, OKL4, > L4/Fiasco, Fiasco.OC, Nova, seL4 and our own hw kernel. A partial response related to the last mentioned kernel. I can warrant that the hw kernel, which is actually Genode's core component combined with a bit of architectural dependent data-structures (e.g. page-tables) and routines, does not contain physical memory mappings used by user-level components. The only exception are the UTCBs already mentioned by Norman. Only before memory is handed over to a user-level component, it gets temporarily faded into the kernel/core to fill it with zeroes. Afterwards it gets detached before it is used by other components. I would wonder if okl4 or sel4 have all physical memory mapped to the kernel area in each address space, because they do not use L4-like memory propagation via synchronous IPC (aka mapping data-base) as far as I know, or do they? Best regards Stefan > > Thanks, > > -- > Alexander Boettcher > Genode Labs > > http://www.genode-labs.com - http://www.genode.org > > Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden > Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main -- Stefan Kalkowski Genode labs https://github.com.skalk | https://genode.org -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Side-channel attacks (Meltdown, Spectre)
Hi Udo, On 05.01.2018 17:36, Udo Steinberg wrote: > Norman Feske (NF) wrote: > > NF> In contrast to monolithic kernels, a microkernel like base-hw, NOVA, > NF> or seL4 does not deal with any user-level content like cryptographic > NF> secrets, or the content of files. There is hardly any credential to > NF> leak to begin with. User content stays outside the microkernel. > > While it is true that a microkernel stores significantly fewer secrets than > a monolithic kernel, like Linux, most microkernels actually have a full > mapping of the entire physical memory in the kernel portion of each address > space, which allows an attacker to peek anywhere into physical memory. before starting to dig/read through all our supported kernels (I'm not all familiar with the internals) - can you please elaborate a bit about which microkernels, according to your knowledge, have all physical memory mapped in the kernel ? The currently supported microkernels for Genode are Pistachio, OKL4, L4/Fiasco, Fiasco.OC, Nova, seL4 and our own hw kernel. Thanks, -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Side-channel attacks (Meltdown, Spectre)
Hi Norman, I would like to comment on a few things... Norman Feske (NF) wrote: NF> In contrast to monolithic kernels, a microkernel like base-hw, NOVA, NF> or seL4 does not deal with any user-level content like cryptographic NF> secrets, or the content of files. There is hardly any credential to NF> leak to begin with. User content stays outside the microkernel. While it is true that a microkernel stores significantly fewer secrets than a monolithic kernel, like Linux, most microkernels actually have a full mapping of the entire physical memory in the kernel portion of each address space, which allows an attacker to peek anywhere into physical memory. This includes peeking at all page tables, followed by reading the memory pages of the desired user process via their physical backing store. NF> There are in-kernel data structures like page tables and thread NF> control blocks. Hence, Meltdown may allow untrusted user code to NF> fingerprint the kernel or gather other information about those NF> in-kernel data structures. E.g., detect the presence of threads and NF> protection domains. It is currently unclear to me, in which ways an NF> attacker may exploit this meta data. If an attacker can read the thread control block of other processes in the kernel, then he gets full access to the register state of preempted threads. The value of the instruction pointer and GPRs can be very valuable, for example when other processes are in the middle of crypto operations. The TCBs may actually be a lot more valuable than other kernel metadata. NF> Considering that a microkernel has a fairly low cache footprint and NF> only cached information can be leaked via Meltdown, it might be NF> interesting to get hold of the actual scope of information. Meltdown can leak any information that is marked as "present" in the page tables of the current process. What's not currently cached can result in speculative cache fills, as long as the page is marked cacheable. So it's not just cached information that can leak, it's more. NF> Even though the Spectre attack affects components on top of Genode NF> that use a JIT-based VM, the microkernel cannot be easily targeted. NF> In contrast to the Linux kernel, which contains a JIT-based VM in NF> the form of the Berkeley Packet Filter, there is no way to NF> deliberately inject certain code patterns into a microkernel. In the NF> worst case, however, the kernel may already contain a code sequence NF> to exploit as a gadget. So it might be sensible to analyze the NF> kernel code in the light of the Spectre attack. Fortunately - in NF> contrast to a monolithic kernel - a microkernel is not a rapidly NF> moving target. Indirect branch restricted speculation (IBRS) is a new x86 architecture extension to mitigate the effects of Spectre. It requires microcode patches that are rolling out right now. Retpolines is another (software-only) approach. Which one to use when gets messy very quickly: https://docs.google.com/document/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub NF> It is far too early to draw definite conclusions. E.g., it is unclear to NF> me if and how Intel's microcode updates [5] address parts of the NF> attacks. Intel ucode adds IBRS. NF> Since implementing mitigation measures will require significant effort, NF> and performance penalties are to be expected, we won't eagerly go NF> forward on our own right now. The scope and time frame of possible NF> mitigations come down to the priorities of Genode's commercial users. IPC will definitely become slower as a result. Since only Intel seems to be affected by Meltdown, the big question will be whether to use different page-table layouts for different vendors or to use the same layout for all. Would you be willing to degrade AMD IPC performance in favor of having one x86 kernel that works the same way everywhere rather than having multiple different implementations or different code paths that need independent testing/verification? Cheers, Udo pgpGiktHwS6DD.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Side-channel attacks (Meltdown, Spectre)
A question that pops up in my mind is: is there a mapping of all physical memory inside the kernels supported by Genode (and for which kernel is this true, besides Linux)? One of the things mentioned in the paper: > We focus on addresses that are mapped within the at- > tacker’s process, i.e., the user-accessible user space ad- > dresses as well as the user-inaccessible kernel space ad- > dresses. Note that attacks targeting code that is executed > within the context (i.e., address space) of another process > are possible [19], but out of scope in this work, since all > physical memory (including the memory of other pro- > cesses) can be read through the kernel address space any- > way. In other words, is it possible for the meltdown attack on genode to leak memory of other user-level components? -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Roadmap 2018
Hi Steven, > While x86 support is good, the embedded landscape is dominated by > ARM, and currently Genode seems to have weaker driver support for > small modern ARM systems. The Wand Quad would be a good platform > to develop in this regard (vs, say, Arndale). Rpi would be > another. (We've had little luck getting Genode running on any > recent model of rpi, but maybe it wouldn't take much to change > this.) I agree that the Freescale i.MX SoC should receive some love from us in 2018. From my perspective, the most interesting features would be the addition of USB and networking support. Are you planning to enable Genode on a more recent Raspberry Pi? This would be a very welcome contribution! ;-) Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Side-channel attacks (Meltdown, Spectre)
Hello, I am sure that most of you have seen the seismic effects of the Meltdown and Spectre attacks [1] that were made public two days ago. Since both attacks target the hardware rather than a particular software vulnerability, all operating systems and hypervisors are affected - more or less. I do not want to repeat the technical details of the attacks here. The security advisories listed on the bottom of the website [1] do an excellent job with explaining the problem (e.g., the issue description of Xen's advisory [2] is concise and easy to understand). The mind-bending technical work behind these attacks is described in detail at Google's Project Zero website [3]. It's truly fascinating! [1] https://meltdownattack.com/ [2] https://xenbits.xen.org/xsa/advisory-254.html [3] https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html The attacks question our universal assumptions about the effectiveness of hardware-based protection mechanisms present in modern CPUs. They leverage CPU caches to leak information between protection boundaries. Since caches are a shared physical resources, it is hardly surprising that they are prone to crosstalk between protection boundaries, e.g., as demonstrated before by covert timing channels that use the 2nd-level cache as communication channel. However, the attacks are spectacular because they trick the CPU's mechanics for speculative execution to deliberately leak protected information into the caches. The Meltdown attack allows user-level code to obtain information that are normally private to the kernel. The Spectre attack allows a sandboxed program running in a JIT-based VM (like Javascript) to obtain information about the sandbox (e.g., the browser that executes the Javascript code). Given the structure of today's commodity operating systems and hypervisors, the implications of the attacks are near to impossible to grasp. E.g., the Linux kernel is entrusted with cryptographic keys and passwords assuming that user-level programs cannot access this information without authorization. This premise is broken by the Meltdown attack. To uphold it, kernel developers are accepting mitigation measures that come with significant performance penalties. The IT industry has to collectively suffer under either the attacks or the mitigations. Impact on Genode It is too early to give a detailed assessment. My initial knee-jerk reaction was that we'd have to follow Linux with completely separating the virtual address spaces of the kernel and the user land. The irony is that our custom base-hw kernel actually used to keep the kernel in a dedicated virtual address space - until three months ago when we reworked the kernel to follow the main stream where the kernel is mapped in each user-level address space as privileged pages. In principle, we could revert this optimization. For NOVA, this change would require more significant effort. According to seL4 mailing list [4], there is work in progress to address the Meltdown attack on seL4. [4] http://sel4.systems/pipermail/devel/2018-January/001809.html Before going forward with implementing costly mitigations, however, we should get a clearer picture of risks of the attacks for Genode. My current thoughts are as follows: * In contrast to monolithic kernels, a microkernel like base-hw, NOVA, or seL4 does not deal with any user-level content like cryptographic secrets, or the content of files. There is hardly any credential to leak to begin with. User content stays outside the microkernel. * The only memory pages accessed by both kernel and user land are the so-called user-level thread-control blocks (UTCB, on seL4 they are called IPC buffer). The Meltdown attack could in principle allow two conspiring user-level components to create a covert timing channel via UTCBs. However, since both components share the 2nd-level cache anyway, they could create a covert timing channel even without Meltdown. Covert timing channels between Genode components are not addressed by any of Genode's underlying kernels so far. * There are in-kernel data structures like page tables and thread control blocks. Hence, Meltdown may allow untrusted user code to fingerprint the kernel or gather other information about those in-kernel data structures. E.g., detect the presence of threads and protection domains. It is currently unclear to me, in which ways an attacker may exploit this meta data. But given the creativity of attackers, we should be pessimistic. To get a better picture, it might be a good idea to execute the Meltdown attack on different kernels to see the actual information that can be leaked. Considering that a microkernel has a fairly low cache footprint and only cached information can be leaked via Meltdown, it might be interesting to get hold of the actual scope of information. * Even though the Spectre attack affects components on top of Genode that
Re: Constrained file descriptors
Hi Norman, > As another principle idea - at least for handing out MMIO mappings for > PCI resources, you may have a look at the pseudo files under > /sys/devices. Here you can find all memory-mapped PCI resources as > files, which could be mapped in user space via 'mmap'. E.g., the > following command lists the available resources (with their file size > corresponding to the information given by 'lspci -v'): > > ls -l `find /sys/devices/pci\:00 -name "resource*"` > > However, this approach has some caveats: > > * Core's IO_MEM service hands out resources based on their physical > address. You would need to search /sys/devices for the matching PCI > resource. > > * A user-level device driver may request just a window of a PCI > resource. So the dataspace handed out by core would need to carry the > information about its offset from the beginning of the underlying > file. We are somehow back at the start of the discussion. :-/ > > * It only works for the (arguably most prominent) case of PCI > resources but not for other mappings. I am in particular thinking > of the mapping of the PCI config space, which we will need to > run the platform driver once the issue "RFC platform_drv/x86: > Switch to ECAM/MMCONF" [1] is closed. I guess that we would need > to have a Linux-specific platform driver then. > > [1] https://github.com/genodelabs/genode/pull/2547 > > That said, in my opinion the tinkering with the files at /sys/ is not > very attractive. If you are prepared to develop a generic kernel module > for solving this problem at a lower level (and allowing us to reuse our > existing platform driver on Linux), this should be the way to go. We also thought about these options and came to the same conclusions. Furthermore sysfs is something we probably want to remove in the future so we don't want to depend on it anyway. Also at the implementation of interrupts we will need a kernel module/patch anyway since we didn't find any way to get them into the userspace (except polling /proc/interrupts which is a really bad hack). About the specific PCI memory spaces, as far as I know PCI is mainly available on X86. Since the use of the Linux kernel is intended for exotic platforms without a supported micro kernel (on X86 we can stay with NOVA) where PCI most probably isn't available we definitely want to create a generic solution to access MMIO space. Thanks for your thoughts and regards, Johannes -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
