This is very ugly.
Redmond is not playing nice.
http://linux.slashdot.org/story/12/05/31/190217/red-hat-will-pay-microsoft-to-get-past-uefi-restrictions
Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
Posted by timothy
from the one-low-low-price-but-still dept.
from the one-low-low-price-but-still dept.
ToriaUru writes "Fedora is going to pay Microsoft to let them distribute a PC operating system. Microsoft is about to move from effectively owning the PC hardware platform to literally owning it. Once Windows 8 is released, hardware manufacturers will be forced to ship machines that refuse to run any software that is not explicitly approved by Microsoft — and that includes competing operating systems like Linux. Technically Fedora didn't have to go down this path. But, as this article explains, they are between a rock and a hard place: if they didn't pay Microsoft to let them onto the PC platform, they would have to explain to their potential users how to mess with firmware settings just to install the OS. How long before circumventing the secure boot mechanism is considered a DMCA violation and a felony?" Note that the author says this is likely, but that the entire plan is not yet "set in stone."
The link to the story:
http://mjg59.dreamwidth.org/12368.html
Implementing UEFI Secure Boot in Fedora
May. 30th, 2012 11:11 pm![[personal profile]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vYy8rGGybxKXRhgorgKgS3t9Kvy5cOEzqMlAfrkhdGjQ5gTJYbmulGVawTvAS8-pdOvlzhv8YJeHTHSOr4bqac4rKXS47DpfdWj15YQihVxwAcj39syRw=s0-d){kind=small}
mjg59Edit 16:17EDT 31/5/12: Clarification of who gets the $99
Edit 02:10EDT 01/6/12: Clarification that it's a one-off payment
(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)
Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.
Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].
We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.
We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.
Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.
Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.
But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.
And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.
If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.
A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.
A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. Barring firmware backdoors, it's possible to configure secure boot such that your computer will only run software you trust. Freedom means being allowed to run the software you want to run, but it also means being able to choose the software you don't want to run.
We've been working on this for months. This isn't an attractive solution, but it is a workable one. We came to the conclusion that every other approach was unworkable. The cause of free software isn't furthered by making it difficult or impossible for unskilled users to run Linux, and while this approach does have its downsides it does also avoid us ending up where we were in the 90s. Users will retain the freedom to run modified software and we wouldn't have accepted any solution that made that impossible.
But is this a compromise? Of course. There's already inequalities between Fedora and users - trademarks prevent the distribution of the Fedora artwork with modified distributions, and much of the Fedora infrastructure is licensed such that some people have more power than others. This adds to that inequality. It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be.
Microsoft's certification requirements for ARM machines forbid vendors from offering the ability to disable secure boot or enrol user keys. While we could support secure boot in the same way as we plan to on x86, it would prevent users from running modified software unless they paid money for a signing key. We don't find that acceptable and so have no plans to support it.
Thankfully this shouldn't be anywhere near as much of a problem as it would be in the x86 world. Microsoft have far less influence over the ARM market, and the only machines affected by this will be the ones explicitly designed to support Windows. If you want to run Linux on ARM then there'll be no shortage of hardware available to you.
No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it.
[1] In fact, chances are that everything will carry the Microsoft key. Secure boot requires that UEFI drivers also be signed. The signing format only permits a single signature per binary. For compatibility, approximately all add-on hardware shipped will be signed with Microsoft's key, and that means that all system vendors have to recognise Microsoft's key in order to permit that hardware to run on their systems.
[2] Current source is here. It relies on a port of the UEFI crypto library and OpenSSL that I have building with some handholding, and which I'll upload as soon as possible."
Edit 02:10EDT 01/6/12: Clarification that it's a one-off payment
(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)
Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.
Getting the machine booted
Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].
We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.
Bootloaders
We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Kernel
Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.
Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.
Wait signed what
Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.
But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.
And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.
If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.
Customisation
A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.
But I don't trust Microsoft
A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. Barring firmware backdoors, it's possible to configure secure boot such that your computer will only run software you trust. Freedom means being allowed to run the software you want to run, but it also means being able to choose the software you don't want to run.
You've sold out
We've been working on this for months. This isn't an attractive solution, but it is a workable one. We came to the conclusion that every other approach was unworkable. The cause of free software isn't furthered by making it difficult or impossible for unskilled users to run Linux, and while this approach does have its downsides it does also avoid us ending up where we were in the 90s. Users will retain the freedom to run modified software and we wouldn't have accepted any solution that made that impossible.
But is this a compromise? Of course. There's already inequalities between Fedora and users - trademarks prevent the distribution of the Fedora artwork with modified distributions, and much of the Fedora infrastructure is licensed such that some people have more power than others. This adds to that inequality. It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be.
What about ARM
Microsoft's certification requirements for ARM machines forbid vendors from offering the ability to disable secure boot or enrol user keys. While we could support secure boot in the same way as we plan to on x86, it would prevent users from running modified software unless they paid money for a signing key. We don't find that acceptable and so have no plans to support it.
Thankfully this shouldn't be anywhere near as much of a problem as it would be in the x86 world. Microsoft have far less influence over the ARM market, and the only machines affected by this will be the ones explicitly designed to support Windows. If you want to run Linux on ARM then there'll be no shortage of hardware available to you.
Is this all set in stone?
No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it.
[1] In fact, chances are that everything will carry the Microsoft key. Secure boot requires that UEFI drivers also be signed. The signing format only permits a single signature per binary. For compatibility, approximately all add-on hardware shipped will be signed with Microsoft's key, and that means that all system vendors have to recognise Microsoft's key in order to permit that hardware to run on their systems.
[2] Current source is here. It relies on a port of the UEFI crypto library and OpenSSL that I have building with some handholding, and which I'll upload as soon as possible."
http://en.wikipedia.org/wiki/UEFI
"
Criticism
Numerous digital rights activitists have protested against UEFI. Ronald G. Minnich, a co-author of coreboot, and Cory Doctorow, a digital rights activist, have criticized EFI as an attempt to preserve “intellectual property” by removing the ability of the user to truly control his computer.[45][46] It does not solve any of the BIOS's long standing problems of requiring two different drivers — one for the firmware and one for the operating system — for most hardware.[47]TianoCore,[48] an open-source project which provides the UEFI interfaces, lacks the specialized drivers that initialize chipset functions, which are instead provided by coreboot, of which TianoCore is one of many payload options. The development of Coreboot requires chipset manufactures to cooperate by providing specifications needed to develop initialization drivers.
UEFI reimplements a full networking stack, unlike many BIOSes, and therefore is a target for remote security exploits.[49]
Secure Boot
See also: Windows 8#Secure boot and Hardware restrictions#Windows 8
Red Hat developer Matthew Garrett in his article "UEFI secure booting" raised a concern that UEFI "secure boot" feature may impact Linux (machines with the Windows 8 logo with secure boot enabled that ships with only OEM and Microsoft keys will not boot a generic copy of Linux).[50][51] In response, Microsoft stated that customers may be able to disable the secure boot feature in the UEFI interface.[2][52] Concern remained that some OEMs might omit that capability in their computers. Later it was reported that Microsoft apparently prohibited implementation of disabling of Secure Boot on ARM systems.[53][54]Joshua Gay of the Free Software Foundation (FSF) raised concerns on "secure boot" implementation to UEFI and FSF declared a public statement open for signing which states:
We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems.[55][56]In December 2011, Microsoft released a document about hardware certification of OEM products, Windows Hardware Certification Requirements[57] which confirms that they intend to ban the possibility of installing alternative operating systems on ARM-based devices running Windows 8. The document insists that they will require x86 and x86-64 devices to have the Secure UEFI enabled. They allow for the possibility that a custom secure boot mode could be enabled providing to the user the ability to add signatures. However, they intend that going to custom secure boot mode or disabling secure boot mode on ARM devices will not be compatible with running Windows.[53]"
http://en.wikipedia.org/wiki/ARM_architecture
Look if you need to. Tablets and phones?
http://hat4uk.wordpress.com/2012/06/05/euroblown-spain-facing-disaster-but-the-troika-goes-la-la-la-la-lagarde/
EUROBLOWN: Spain facing disaster, but the Troika goes la-la-la-la-Lagarde
Chrissie Lagarde goes gagagagagaThe U.S. Treasury said in a statement that the G7 discussed ‘progress towards a financial and fiscal union in Europe’, but made no joint statement and took no immediate action.
This is all turning into some kind of sick joke. Brussels is asleep, Berlin is split several ways, and the G7 is on the verge of becoming catatonic. A Brussels source tells me the EFSF is preparing a line of credit for Spain, but the EFSF is a busted flush in terms of money attraction…and the Spaniards are down for one euro in eight of the fund’s capital.
“I’m not a great fan of those target headlines that keep being missed anyway,” Lagarde told Reuters in an impenetrable interview full of dickheaded bromides, adding “We need to agree on a comprehensive set of principles to enforce over time. The master plan that everybody signs up to will be important because it will set a vision, it will set a collective determination.”
Yes yes yes Chrissie Lalalande, but what about Spain right now??
It takes alot to make me sympathise with Hedge Funds, but this profoundly stupid woman is more than up to it."
The Schleifen plan is activated?
http://en.wikipedia.org/wiki/Schleifen_plan
http://www.nytimes.com/2012/06/06/business/global/daily-euro-zone-watch.html
"Spain Warns on Borrowing as G-7 Discusses Crisis
By DAVID JOLLY
Published: June 5, 2012
PARIS — Spain warned Tuesday that the moment was nearing when it would be unable to borrow in the bond market without help from its European partners, as Group of 7 finance and central bank officials held a teleconference to discuss the crisis in Europe.
Multimedia
“The risk premium says Spain doesn’t have the market door open,” Treasury Minister Cristóbal Montoro told Onda Cero radio, Reuters reported. “The risk premium says that as a state we have a problem in accessing markets, when we need to refinance our debt.”
The risk premium describes the extra interest rate that investors demand to hold Spanish debt, compared with German debt, which is considered the safest in the euro zone. Currently, Spain’s 10-year bonds yield about 6.3 percent, compared with Germany’s 1.2 percent; thus, the risk premium stands at about 5.1 percentage points.
Mr. Montoro said Spain needed help from European institutions to recapitalize, though he did not give an indication of how much money was required. Emilio Botín, the chairman of Banco Santander, said Tuesday that about 40 billion euros, or $50 billion, of European funds would be needed to fix Spain’s banking sector, Bloomberg News reported.
While Spain’s overall debt is not considered dangerously high, its economy and banks have been hammered by the collapse of a real estate bubble, and it trying to cut government spending to meet European targets even as the economy contracts, leaving the government little leeway to aid lenders.
Spain is planning a bond auction Thursday that could help to decide whether the country must seek a bailout from the European Union, the International Monetary Fund and the European Central Bank, as Portugal, Greece and Ireland have done.
Group of 7 officials spoke Tuesday morning, Washington time. The Kyodo News agency cited Finance Minister Jun Azumi of Japan as telling reporters that he had agreed with his G-7 counterparts to cooperate in addressing the European crisis. Mr. Azumi also said he expressed Japan’s concerns about the volatility of the yen, which is threatening to wreak havoc with Japan’s export-led economy.
The G-7 did not issue a statement after the emergency talks. Members of the group are Britain, Canada, France, Germany, Italy, Japan and the United States.
The Group of 20, which includes the G-7 as well as important emerging nations including Brazil, Russia, India and China, is scheduled to meet June 18-19 in Mexico. Greece will hold elections just a day earlier, on June 17, in a vote that is seen by some as a referendum on the struggling country’s continuing membership in the euro. Some economists fear that a rejection of pro-bailout parties by Greek voters could lead to chaos in the markets.
The euro zone continues to disappoint already low expectations of economic growth. Retail sales fell in April by 1.0 percent from March, Eurostat, the European Union statistical agency said Tuesday. From a year earlier, April retail sales fell by 2.5 percent in the euro area. That was far below the forecasts of economists polled by Reuters, who had expected a 0.1 percent monthly decline and and 1.1 percent annual decline.
A separate report showed German industrial orders sliding by 1.9 percent in April from March’s revised 3.2 percent increase, the Economy Ministry reported in Berlin. The lion’s share of the decline resulted from shrinking overseas orders. Orders fell 3.8 percent from a year earlier.
In European afternoon trading Tuesday, the Euro Stoxx 50 index, a barometer of euro zone blue chips, rose 0.6 percent. London markets were closed for a second day for Queen Elizabeth II’s diamond jubilee celebration.
The dollar was higher against other major European currencies. The euro fell to $1.2444 from $1.2499 late Monday in New York, while the British pound fell to $1.5358 from $1.5384. The dollar rose to 0.9647 Swiss francs from 0.9609 francs, and to 78.62 yen from 78.34 yen.
Hiroko Tabuchi contributed from Tokyo."
The G-7 issued no report.
European Union Proposes Central Banking Regulator
By JACK EWING and JAMES KANTER
The plan could spread out the cost of bank rescues and show that countries were willing to cede power to centralized institutions to stablize the currency union.
Just as expected an hour ago...
- JAPANESE FINANCE MINISTER AZUMI SAYS G7 WILL NOT ISSUE A JOINT STATEMENT
- AZUMI: G7 DID NOT DISCUSS GREECE LEAVING THE EURO
- AZUMI: G7 AGREED WILL WORK TOGETHER TO DEAL WITH PROBLEMS IN SPAIN, GREECE - RTRS
- AZUMI URGED EUROPE TO EASE CONCERNS OF FINANCIAL MARKETS
- AZUMI: G7 AGREES TO COOPERATE TO RESOLVE SPAIN, GREECE PROBLEMS
- AZUMI TOLD G7 JAPAN IS CONCERNED ABOUT RAPID YEN RISE
http://www.zerohedge.com/news/germany-ruling-cdu-rejects-direct-spanish-bank-aid
"Just when Spain thought that by admitting it is broke, Germany would finally turn a blind eye and let it have whatever money it requested directly at the bank level, instead of boosting its sovereign leverage even more, thus putting it at risk of long, long overdue Moody's and Fitch downgrades, here comes the Germany, adding insult to humiliation. From the FT: "The parliamentary leadership of Germany’s ruling Christian Democrats – the majority party in Angela Merkel’s centre-right coalition government – has flatly rejected the use of eurozone rescue funds to recapitalise Spanish banks directly. Instead they called on the Spanish government on Tuesday to decide urgently whether it will seek money from the €440bn European Financial Stability Facility according to the fund’s normal rules, requiring agreement on a proper rescue programme negotiated with its European partners." In other words Germany has laid out the choice: bail out your banks with our help, and be downgraded, pushing Spanish sovereign yields into the 7%+ range, or do nothing, and prepare to hand out an infinite amount of Spiderman beach towels.
And for those hoping that Germany is acting counterproductively to its own interests, which for those confused, are to have Europe at the edge of chaos, keeping the EUR low, and its Debtor In Possession targets amenable to any terms, three words: nein, nein, nein.
Oddly enough we have yet to see them lining up with, and presenting the ultimate collateral."
And for those hoping that Germany is acting counterproductively to its own interests, which for those confused, are to have Europe at the edge of chaos, keeping the EUR low, and its Debtor In Possession targets amenable to any terms, three words: nein, nein, nein.
At the end of the day, what will make Germany amenable to any plan, is if the PIIGS pledge their thousands of tons of gold to a German "pawn shop" as explained last week.There was no sign in Berlin, however, of more urgent emergency measures being contemplated to prevent contagion in the current crisis spreading from Greece to Spain and beyond. Instead, the timescale for Germany’s proposed reforms would stretch until the spring of 2013.
Wolfgang Schäuble, German finance minister, held out the prospect on Tuesday of medium-term reforms, such as a “banking union” to provide deposit insurance for cross-border financial institutions, and even jointly guaranteed eurozone bonds – but only once a fully fledged “fiscal union” had been agreed for the whole eurozone.
In an interview with Handelsblatt, a business newspaper, he said that it was important to distinguish between immediate measures to resolve the present crisis and longer-term reforms to prevent its recurrence.
Both Greece and Spain, he said, must put their own economies in order.
It was up to Greek voters to decide for themselves whether they would remain members of the eurozone, he said. But he admitted that uncertainty over the outcome of the forthcoming Greek election had caused contagion to spread to Spain.
“The Spanish are doing everything right, and yet they are still facing pressure in the markets because of contagion from Greece. We must deal with that.”
Oddly enough we have yet to see them lining up with, and presenting the ultimate collateral."
This is a negative view.
None of the Europeans believe the bottom is not there.
It is a long way down.
.
No comments:
Post a Comment