1. 26 7月, 2010 2 次提交
  2. 25 7月, 2010 12 次提交
  3. 24 7月, 2010 3 次提交
  4. 23 7月, 2010 1 次提交
  5. 22 7月, 2010 13 次提交
  6. 21 7月, 2010 1 次提交
  7. 19 7月, 2010 1 次提交
  8. 17 7月, 2010 1 次提交
  9. 16 7月, 2010 1 次提交
  10. 15 7月, 2010 4 次提交
    • E
      microblaze: Correct signal frame setup. · 187b4e08
      Edgar E. Iglesias 提交于
      Pass the context in r7.
      Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>
      187b4e08
    • A
      Merge remote branch 'origin/master' into staging · c84995c5
      Anthony Liguori 提交于
      c84995c5
    • A
      c7ba56c4
    • A
      Make default invocation of block drivers safer (v3) · 79368c81
      Anthony Liguori 提交于
      CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
      trick the block probing code into accessing arbitrary files in a guest.  To
      mitigate this, we added an explicit format parameter to -drive which disabling
      block probing.
      
      Fast forward to today, and the vast majority of users do not use this parameter.
      libvirt does not use this by default nor does virt-manager.
      
      Most users want block probing so we should try to make it safer.
      
      This patch adds some logic to the raw device which attempts to detect a write
      operation to the beginning of a raw device.  If the first 4 bytes happen to
      match an image file that has a backing file that we support, it scrubs the
      signature to all zeros.  If a user specifies an explicit format parameter, this
      behavior is disabled.
      
      I contend that while a legitimate guest could write such a signature to the
      header, we would behave incorrectly anyway upon the next invocation of QEMU.
      This simply changes the incorrect behavior to not involve a security
      vulnerability.
      
      I've tested this pretty extensively both in the positive and negative case.  I'm
      not 100% confident in the block layer's ability to deal with zero sized writes
      particularly with respect to the aio functions so some additional eyes would be
      appreciated.
      
      Even in the case of a single sector write, we have to make sure to invoked the
      completion from a bottom half so just removing the zero sized write is not an
      option.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      79368c81
  11. 14 7月, 2010 1 次提交