Or else `services.udev.packages = [ bcache-tools ]` cannot be used.
To not break bcache in the initrd I'm modifying this in stage-1.nix:
- --replace /bin/sh ${extraUtils}/bin/sh
+ --replace ${bash}/bin/sh ${extraUtils}/bin/sh
Reasoning behind that change:
* If not modifying the /bin/sh pattern in any way, it will also match
${bash}/bin/sh, creating a broken path like
/nix/store/HASH-bash/nix/store/HASH-bash/bin/sh in the udev rule file.
* The addition of /bin/sh was done in 775f381a9e
("stage-1: add bcache support"). It seems somewhat plausible that
no new users have appeared since then and we can take this opportunity
to back out of this change without much fear of regressions.
If there _are_ regressions, they should be in the form of build time
errors, not runtime (boot), due to how the udev rule output is checked
for invalid path references. So low risk, IMHO.
* An alternative approach could be to copy the /bin/sh substitute rule
over to the non-initrd udev rules implementation in NixOS, but I think
this way is better:
- The rules file comes with a working path out of the box.
- We can use more precise pattern matching when modifying the udev
rules for the initrd.
* hplip: introduce nettools dependency
Some HP printers (notably a HP MFP M477fnw) need to run `hostname` as part of
the printing process. This executable is provided by the "nettools" package.
* hplip: prepend nettools to PATH
Improvement: Use nix-shell for fetch.sh
androidsdk{,_extras}:
- Update to 7.1.1
google_apis_25 is missing after fetch.sh due to an error in addon.xml
(upsteam bug).
Addons:
- Add google_apis_25
- Update google_play_services (v8_rc41 -> v11_rc16)
lxappearance supports both Gtk+-2 and Gtk+-3. The current `lxappearance'
package continues to be for Gtk+-2. Add `lxappearance-gtk3' for Gtk+-3.
A patch is needed in order to look for themes in system data dirs with
Gtk+-3.
By default, `ghcjs` haddocks are precluded from being built. I see no reason to disallow building haddocks on projects built with `ghc` and `ghcjs` (someone can correct me here). `HaLVM` currently does not support `haddock` since it's a Stage 1 `GHC`. https://github.com/GaloisInc/HaLVM/blob/master/src/misc/build.mk.in#L20
Currently, building `haddocks` for `ghcjs` projects requires altering the derivation, which doesn't allow users to take advantage of the cache. This change will relieve that.
XSA-206 Issue Description:
> xenstored supports transactions, such that if writes which would
> invalidate assumptions of a transaction occur, the entire transaction
> fails. Typical response on a failed transaction is to simply retry
> the transaction until it succeeds.
>
> Unprivileged domains may issue writes to xenstore which conflict with
> transactions either of the toolstack or of backends such as the driver
> domain. Depending on the exact timing, repeated writes may cause
> transactions made by these entities to fail indefinitely.
More: https://xenbits.xen.org/xsa/advisory-206.html
XSA-211 Issue Description:
> When a graphics update command gets passed to the VGA emulator, there
> are 3 possible modes that can be used to update the display:
>
> * blank - Clears the display
> * text - Treats the display as showing text
> * graph - Treats the display as showing graphics
>
> After the display geometry gets changed (i.e., after the CIRRUS VGA
> emulation has resized the display), the VGA emulator will resize the
> console during the next update command. However, when a blank mode is
> also selected during an update, this resize doesn't happen. The resize
> will be properly handled during the next time a non-blank mode is
> selected during an update.
>
> However, other console components - such as the VNC emulation - will
> operate as though this resize had happened. When the display is
> resized to be larger than before, this can result in a heap overflow
> as console components will expect the display buffer to be larger than
> it is currently allocated.
More: https://xenbits.xen.org/xsa/advisory-211.html
XSA-212 Issue Description:
> The XSA-29 fix introduced an insufficient check on XENMEM_exchange
> input, allowing the caller to drive hypervisor memory accesses outside
> of the guest provided input/output arrays.
More: https://xenbits.xen.org/xsa/advisory-212.html
XSA-213 Issue Description:
> 64-bit PV guests typically use separate (root) page tables for their
> kernel and user modes. Hypercalls are accessible to guest kernel
> context only, which certain hypercall handlers make assumptions on.
> The IRET hypercall (replacing the identically name CPU instruction)
> is used by guest kernels to transfer control from kernel mode to user
> mode. If such an IRET hypercall is placed in the middle of a multicall
> batch, subsequent operations invoked by the same multicall batch may
> wrongly assume the guest to still be in kernel mode. If one or more of
> these subsequent operations involve operations on page tables, they may
> be using the wrong root page table, confusing internal accounting. As
> a result the guest may gain writable access to some of its page tables.
More: https://xenbits.xen.org/xsa/advisory-213.html
XSA-214 Issue Description:
> The GNTTABOP_transfer operation allows one guest to transfer a page to
> another guest. The internal processing of this, however, does not
> include zapping the previous type of the page being transferred. This
> makes it possible for a PV guest to transfer a page previously used as
> part of a segment descriptor table to another guest while retaining the
> "contains segment descriptors" property.
>
> If the destination guest is a PV one of different bitness, it may gain
> access to segment descriptors it is not normally allowed to have, like
> 64-bit code segments in a 32-bit PV guest.
>
> If the destination guest is a HVM one, that guest may freely alter the
> page contents and then hand the page back to the same or another PV
> guest.
>
> In either case, if the destination PV guest then inserts that page into
> one of its own descriptor tables, the page still having the designated
> type results in validation of its contents being skipped.
More: https://xenbits.xen.org/xsa/advisory-214.html
XSA-215 Issue Description:
> Under certain special conditions Xen reports an exception resulting
> from returning to guest mode not via ordinary exception entry points,
> but via a so call failsafe callback. This callback, unlike exception
> handlers, takes 4 extra arguments on the stack (the saved data
> selectors DS, ES, FS, and GS). Prior to placing exception or failsafe
> callback frames on the guest kernel stack, Xen checks the linear
> address range to not overlap with hypervisor space. The range spanned
> by that check was mistakenly not covering these extra 4 slots.
More: https://xenbits.xen.org/xsa/advisory-215.html
Recent commit #c10af9e744c91dff1ccc07a52a0b57d1e4d339f3 changed the
behaviour of wrapPythonPrograms, which caused pygrub to no longer
being wrapped. This commit fixes this.
