This is the master branch of nixpkgs, initially pulled from commit 8debf2f9a63d54ae4f28994290437ba54c681c7b The intent of this repo is to be merged onto nixpkgs master. This will also be of help for https://git.suyu.dev/BoomMicrophone/suyu-nix-test which I will need in order for development (it will also be helpful to know what to do for setting up the environment for the master server. Currently I am focusing on this so I can actually see what is still missing) This repo will be removed once the PR to the nixpkgs github goes through
Find a file
Michał Pałka dd3dcceb23 xen: patch for XSAs: 206, 211, 212, 213, 214 and 215
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
2017-06-09 13:09:01 +00:00
.github github issue template: add sandboxing info 2017-05-01 15:38:11 +03:00
doc Merge pull request #26269 from obsidiansystems/libSystem 2017-05-31 00:49:58 -04:00
lib pkgs.python.astropy: init at 1.3.3 2017-06-08 17:50:22 +02:00
maintainers/scripts Python: improve update script 2017-06-06 17:20:32 +02:00
nixos NixOS VM tests: Don't create a setgid group in vde_switch 2017-06-07 11:57:36 +02:00
pkgs xen: patch for XSAs: 206, 211, 212, 213, 214 and 215 2017-06-09 13:09:01 +00:00
.editorconfig Do not trim trailing whitespace in patch files 2017-01-12 23:44:26 +01:00
.gitignore
.mention-bot Remove bbenoist from maintainers 2017-03-23 03:03:04 +01:00
.travis.yml Actually disable travis emails 2017-06-03 12:13:29 -04:00
.version version: it's 17.09 not 17.10 2017-02-27 20:46:35 +01:00
COPYING
default.nix default.nix: Provide correct instructions how to upgrade Nix 2017-03-18 21:04:07 +02:00
README.md docs: 16.09 -> 17.03 2017-03-30 17:36:44 +02:00

logo

Build Status Code Triagers Badge

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.

Communication: