dd3dcceb23
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 |
||
|---|---|---|
| .github | ||
| doc | ||
| lib | ||
| maintainers/scripts | ||
| nixos | ||
| pkgs | ||
| .editorconfig | ||
| .gitignore | ||
| .mention-bot | ||
| .travis.yml | ||
| .version | ||
| COPYING | ||
| default.nix | ||
| README.md | ||
Nixpkgs is a collection of packages for the Nix package manager. It is periodically built and tested by the hydra build daemon as so-called channels. To get channel information via git, add nixpkgs-channels as a remote:
% git remote add channels git://github.com/NixOS/nixpkgs-channels.git
For stability and maximum binary package support, it is recommended to maintain
custom changes on top of one of the channels, e.g. nixos-17.03 for the latest
release and nixos-unstable for the latest successful build of master:
% git remote update channels
% git rebase channels/nixos-17.03
For pull-requests, please rebase onto nixpkgs master.
NixOS linux distribution source code is located inside
nixos/ folder.
- NixOS installation instructions
- Documentation (Nix Expression Language chapter)
- Manual (How to write packages for Nix)
- Manual (NixOS)
- Nix Wiki (deprecated, see milestone "Move the Wiki!")
- Continuous package builds for unstable/master
- Continuous package builds for 17.03 release
- Tests for unstable/master
- Tests for 17.03 release
Communication: