Re: Meltdown and spectre

I opened a SR about Meltdown and Spectre patches for Oracle Linux and this is the response.

'Oracle has developed fixes addressing the Intel processor design flaws leading to vulnerabilities CVE-2017-5753, CVE-2017-5754, and CVE-2017-5715. Oracle will deliver those fixes, if applicable, in accordance with Oracle’s security update policies"

So I guess they are not available yet.

On Tue, Jan 9, 2018 at 2:52 PM, Jeff Chirco <backseatdba_at_gmail.com> wrote:

> ksplice doesn't see to have that updated kernel. I run uptrack-upgrade but
> there is nothing to be done.
> Effective kernel version is 4.1.12-112.14.2.el7uek
>
> However a yum update listed the following
> Installed:
> kernel-uek.x86_64 0:4.1.12-112.14.10.el7uek
>
> kernel-uek-firmware.noarch 0:4.1.12-112.14.10.el7uek
>
> I am confused, also I am new to Linux environment.
>
> On Tue, Jan 9, 2018 at 1:03 PM, Maris Elsins <elmaris_at_gmail.com> wrote:
>
>> Hi,
>>
>> I didn't red the whole history (so sorry if it was already mentioned),
>> but the UEK fixes for Meltdown (CVE-2017-5754) were released this morning.
>> See https://linux.oracle.com/cve/CVE-2017-5754.html for details.
>>
>> ---
>> Maris Elsins
>> _at_MarisElsins <https://twitter.com/MarisElsins>
>> www.facebook.com/maris.elsins
>>
>>
>>
>> On Tue, Jan 9, 2018 at 8:18 PM, Jeff Chirco <backseatdba_at_gmail.com>
>> wrote:
>>
>>> I am still confused how to tell if the exploit has been patched if I run
>>> yum update or uptrack-upgrade
>>>
>>> On Tue, Jan 9, 2018 at 6:29 AM, Patrice sur GMail <
>>> patrice.boivin_at_gmail.com> wrote:
>>>
>>>> that's the way it goes though.
>>>>
>>>> I remember Token Ring... vs. ethernet. Ethernet's up front costs were
>>>> lower, people used that even though it had packet collision problems.
>>>> token ring belonged to just one vendor, IBM. People probably didn't want
>>>> to rely on just one vendor
>>>>
>>>> On Mon, Jan 8, 2018 at 3:39 PM, Reen, Elizabeth <
>>>> dmarc-noreply_at_freelists.org> wrote:
>>>>
>>>>> The links I was referring to are
>>>>> https://spectreattack.com/spectre.pdf and
>>>>> https://meltdownattack.com/meltdown.pdf. They give an excellent
>>>>> explanation. My masters is in systems engineering. My dissertation was
>>>>> writing an operating system. I wish I have the time to surf the web to
>>>>> read these things, but I have a real job supporting a couple hundred
>>>>> databases. I got my information from the business journals my bosses were
>>>>> reading. What they wrote was dumbed down and lacking the details. Most of
>>>>> the vendor notes were as usual vague.
>>>>>
>>>>>
>>>>>
>>>>> Linus Torvalds answer was just passing the buck. He depended on the
>>>>> hardware to do his work. Did Intel know that he was outsourcing that to
>>>>> them? It is not that hard to check that the process is not going outside
>>>>> its memory. I will give him that he originally designed this as a single
>>>>> user o/s. It has morphed into more but no one went back to look at the
>>>>> design. One thing an o/s must do is protect itself against developers.
>>>>> Leaving this open is like allowing anyone to update the disk map, an
>>>>> invitation for disaster. I also question AWS and Oracle for allowing their
>>>>> users to have the privs to do this. If you can control your own destiny it
>>>>> is better. I understand that a lot of companies cannot afford their own IT
>>>>> department.
>>>>>
>>>>>
>>>>>
>>>>> When you buy a Focus, you don’t expect it to be designed
>>>>> like a Rolls Royce. Why people think that cheaper machines/software will
>>>>> do the same thing as the more expensive versions is beyond me.
>>>>>
>>>>>
>>>>>
>>>>> Liz
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* timseanhall_at_gmail.com [mailto:timseanhall_at_gmail.com] *On
>>>>> Behalf Of *Tim Hall
>>>>> *Sent:* Friday, January 05, 2018 6:18 PM
>>>>> *To:* Reen, Elizabeth [ICG-IT]
>>>>> *Cc:* knecht.stefan_at_gmail.com; rajendra.pande_at_ubs.com; Andrew Kerber;
>>>>> Mark W. Farnham; oracle-l_at_freelists.org; fmhabash_at_gmail.com;
>>>>> niall.litchfield_at_gmail.com
>>>>>
>>>>> *Subject:* Re: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> RE: "This is the first piece that makes sense."
>>>>>
>>>>>
>>>>>
>>>>> This made me lol. Project Zero announced the issue. It was linked or
>>>>> mentioned in pretty much every piece I read on this...
>>>>>
>>>>>
>>>>>
>>>>> RE: "I don’t see any reason why an O/S would allow a process to read
>>>>> outside of its memory."
>>>>>
>>>>>
>>>>>
>>>>> I'm not a CPU engineer or OS/Hypervisor developer so excuse my
>>>>> over-simplistic thoughts and anyone feel free to jump in and correct me...
>>>>> Operating systems and hypervisors will offload as much as possible to the
>>>>> hardware. As an example, back in the day VMware used binary translation for
>>>>> almost all system calls, but that was pretty slow. Once Intel and AMD
>>>>> included their respective virtualization tech onto the chips (2006/2007)
>>>>> guess what everyone they did? They passed some of this responsibility on to
>>>>> the hardware to make the hypervisors leaner and more efficient. They trust
>>>>> the chip to do what it says it will do. Likewise, if the OS or hypervisor
>>>>> developer believes operations are safe because the chip is not going to do
>>>>> something stupid, then they will definitely remove code path to improve
>>>>> performance, since all the belt & braces code takes more processing and
>>>>> slows stuff down. At the kernel level, every click counts, as is evident by
>>>>> some of the performance impacts coming through.
>>>>>
>>>>>
>>>>>
>>>>> https://access.redhat.com/articles/3307751
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_3307751&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wHP6u0BxMbXq5dlG98UAbpA2PaR_fjI1NM3ycJP9Qqs&s=M9waxcL2pdqDXF3Bg105rPVteDdKtTum1KZ13vuDjw8&e=>
>>>>>
>>>>>
>>>>>
>>>>> Linus Torvalds response included,
>>>>>
>>>>>
>>>>>
>>>>> "A *competent* CPU engineer would fix this by making sure speculation
>>>>> doesn't happen across protection domains."
>>>>>
>>>>>
>>>>>
>>>>> I know bugger all about this stuff, but his post reads to me like he
>>>>> thought the CPU was protecting these calls, so the OS kernel didn't need to.
>>>>>
>>>>>
>>>>>
>>>>> The picture from VMware doesn't sound so bad initially.
>>>>>
>>>>>
>>>>>
>>>>> https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.vmware.com_security_2018_01_vmsa-2D2018-2D0002.html&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wHP6u0BxMbXq5dlG98UAbpA2PaR_fjI1NM3ycJP9Qqs&s=VAd2zEL94De6kQO6iC-r3xEaTaMB5a_LOdiAtcaCi7Y&e=>
>>>>>
>>>>>
>>>>>
>>>>> I read some other stuff (can't find the links now) which suggested
>>>>> VMware were being very naive and downplaying the problem. I guess we will
>>>>> see how this one plays out over the coming weeks.
>>>>>
>>>>>
>>>>>
>>>>> I also saw some other stuff, once again can't find the links, that
>>>>> suggested it will need to be a combination of kernel and firmware to
>>>>> mitigate the issues until the chip designs are altered.
>>>>>
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> Tim...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 5, 2018 at 10:19 PM, Reen, Elizabeth <
>>>>> elizabeth.reen_at_citi.com> wrote:
>>>>>
>>>>> Thanks Stefan! This is the first piece that makes sense. There is a
>>>>> possibility that this could be fixed in the firmware, but that is going to
>>>>> take time. I can see why an o/s fix would work. I don’t see any reason
>>>>> why an O/S would allow a process to read outside of its memory. When I
>>>>> played with assemblers, this was not allowed by the O/S.
>>>>>
>>>>>
>>>>>
>>>>> A shared environment such as AWS would be a great risk from this. An
>>>>> environment within a company would be a lesser risk, but odds are they
>>>>> would be hacked in an easier fashion. To give Linux and Windows their due,
>>>>> they did start our as large multi user O/Ses.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Liz
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>> sts.org] *On Behalf Of *Stefan Knecht
>>>>> *Sent:* Friday, January 05, 2018 4:58 PM
>>>>> *To:* dmarc-noreply_at_freelists.org
>>>>> *Cc:* tim_at_oracle-base.com; rajendra.pande_at_ubs.com; Andrew Kerber;
>>>>> Mark W. Farnham; oracle-l_at_freelists.org; fmhabash_at_gmail.com;
>>>>> niall.litchfield_at_gmail.com
>>>>>
>>>>>
>>>>> *Subject:* Re: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> I'm not a CPU engineer - but from my understanding, CPUs try to
>>>>> optimize by "predicting" where they will need to jump to. And apparently
>>>>> that's something that people can abuse.
>>>>>
>>>>> The very first paragraph kind of has it all:
>>>>>
>>>>> https://googleprojectzero.blogspot.com/
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__googleprojectzero.blogspot.com_&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=CABPEKJ53eOCZbVN3rPW3M0UIHnB601cQA0kOVPS6zU&e=>
>>>>>
>>>>> "We have discovered that CPU data cache timing can be abused to
>>>>> efficiently leak information out of mis-speculated execution, leading to
>>>>> (at worst) arbitrary virtual memory read vulnerabilities across local
>>>>> security boundaries in various contexts."
>>>>>
>>>>> The key being "mis-speculated". They apparently thought that it's a
>>>>> good idea to execute something ahead of time, just in case we will need to
>>>>> execute it. How no-one imagined the potential abuse is beyond me.
>>>>>
>>>>> Also interesting to see Linus Torvald's response to all of this:
>>>>> https://lkml.org/lkml/2018/1/3/797
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_1_3_797&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=tq1K8SJrK43F-6O_n2OAUuiPKQYUZPKZF0ik2TcSKWA&e=>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 6, 2018 at 4:34 AM, Reen, Elizabeth <
>>>>> dmarc-noreply_at_freelists.org> wrote:
>>>>>
>>>>> All of that happens in the O/S not on the chip. One does
>>>>> not log into a processor.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Liz
>>>>>
>>>>>
>>>>>
>>>>> Elizabeth Reen
>>>>> CPB Database Group Manager
>>>>> 718.248.9930 <(718)%20248-9930> (Office)
>>>>>
>>>>> Service Now Group: CPB-ORACLE-DB-SUPPORT
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>> sts.org] *On Behalf Of *Tim Hall
>>>>> *Sent:* Friday, January 05, 2018 4:06 PM
>>>>> *To:* rajendra.pande_at_ubs.com
>>>>> *Cc:* Andrew Kerber; Mark W. Farnham; oracle-l_at_freelists.org;
>>>>> dmarc-noreply_at_freelists.org; fmhabash_at_gmail.com;
>>>>> niall.litchfield_at_gmail.com
>>>>>
>>>>>
>>>>> *Subject:* RE: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> According to this the RHEL fixes can be overridden if you need
>>>>> performance.
>>>>>
>>>>>
>>>>>
>>>>> https://access.redhat.com/articles/3307751
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_3307751&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=DefUibHP8mOarbcy_Sqc0vqq2lYmneEXAHlsUQivcb8&s=Ts69z7hsaaCuS9AcmtuVLi-4TXmIiEJGiIY3-U623JU&e=>
>>>>>
>>>>>
>>>>>
>>>>> They say bare-metal and containers have similar overheads, but virtual
>>>>> guests are likely to be hit harder...
>>>>>
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> Tim... (On crappy phone)
>>>>>
>>>>>
>>>>>
>>>>> On 5 Jan 2018 7:04 pm, <rajendra.pande_at_ubs.com> wrote:
>>>>>
>>>>> The answer (ref meltdown) apparently is KAISER that has shown to be
>>>>> effective against Meltdown and hence (I guess) updates to the OS
>>>>>
>>>>>
>>>>>
>>>>> https://www.reuters.com/article/us-cyber-intel-researcher/ho
>>>>> w-a-researcher-hacked-his-own-computer-and-found-worst-chip-
>>>>> flaw-idUSKBN1ET1ZR
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.reuters.com_article_us-2Dcyber-2Dintel-2Dresearcher_how-2Da-2Dresearcher-2Dhacked-2Dhis-2Down-2Dcomputer-2Dand-2Dfound-2Dworst-2Dchip-2Dflaw-2DidUSKBN1ET1ZR&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=DefUibHP8mOarbcy_Sqc0vqq2lYmneEXAHlsUQivcb8&s=5gOzYaSHcG0HE_NGKyIdRbISTO3K7A2PXG2nwkleug0&e=>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>> sts.org] *On Behalf Of *Andrew Kerber
>>>>> *Sent:* Friday, January 05, 2018 1:58 PM
>>>>> *To:* Mark W. Farnham
>>>>> *Cc:* ORACLE-L; dmarc-noreply_at_freelists.org; fmh;
>>>>> niall.litchfield_at_gmail.com; tim_at_oracle-base.com
>>>>> *Subject:* Re: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> According to what i am reading Meltdown affects only Intel, but AMD is
>>>>> affected by Spectre, as is Intel. And spectre may be a more difficult fix
>>>>> in the long run.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 5, 2018 at 11:55 AM Mark W. Farnham <mwf_at_rsiz.com> wrote:
>>>>>
>>>>> re: 2) was my question:
>>>>>
>>>>>
>>>>>
>>>>> “So, will there be an “insecure” patch to skip the overhead and rely
>>>>> on server access control?”
>>>>>
>>>>> Follow-up: For all the millions of single user in fact intel based
>>>>> systems, will there be “insecure” patches?
>>>>>
>>>>> The point being, yes, you will have to do patches outside of lab
>>>>> machines kept for particular vintage reasons.
>>>>>
>>>>> Will you be forced to get the performance penalty?
>>>>>
>>>>>
>>>>>
>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>> sts.org] *On Behalf Of *Tim Hall
>>>>> *Sent:* Friday, January 05, 2018 12:18 PM
>>>>> *To:* dmarc-noreply_at_freelists.org
>>>>> *Cc:* mwf_at_rsiz.com; niall.litchfield_at_gmail.com;
>>>>> andrew.kerber_at_gmail.com; fmh; ORACLE-L
>>>>>
>>>>>
>>>>> *Subject:* Re: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> Does not compute.
>>>>>
>>>>>
>>>>>
>>>>> 1) This is a problem with Intel chips. It's not a problem with Linux.
>>>>> The OS vendors are putting in patches to fix/mitigate issues so you don't
>>>>> have to scrap your Intel servers and replace them with servers with AMD
>>>>> chips.
>>>>>
>>>>>
>>>>>
>>>>> 2) Do I need to patch my servers? So you are never going to patch your
>>>>> kernel again? Ever? If you ever do, you will get these fixes. Good luck
>>>>> with never patching stuff again...
>>>>>
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> Tim...
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 5, 2018 at 5:06 PM, Reen, Elizabeth <
>>>>> dmarc-noreply_at_freelists.org> wrote:
>>>>>
>>>>> Since all of my servers are in house behind numerous
>>>>> firewalls, do I need to patch everything? The performance hit is going to
>>>>> hurt. Do I need to do that for dev and testing servers which run with
>>>>> redacted data? I could need to double the amount of servers I own. Yes
>>>>> they are cheap, but it adds up after a while. What about licenses? Will I
>>>>> need to up them because I need more iron to do the same work?
>>>>>
>>>>>
>>>>>
>>>>> I agree that you can’t stop a fully prived account from
>>>>> reading memory under this scenario. It is a bad operating system that lets
>>>>> this happen. Given the say Linux was developed, it is easy for something
>>>>> like this to sneak through. Linux is a great o/s, but you get what you pay
>>>>> for here. The reason it is so popular is that it is so inexpensive. This
>>>>> is not an issue in AIX, Sparc, or HP/UX. They cost money because they have
>>>>> been designed and tested. They did not start out life as an alternative to
>>>>> windows.
>>>>>
>>>>>
>>>>>
>>>>> Wrapper on every syscall is probably the fastest fix. It
>>>>> is far from the best fix. Hopefully they will put in the correct fix.
>>>>>
>>>>>
>>>>>
>>>>> Liz
>>>>>
>>>>>
>>>>>
>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>> sts.org] *On Behalf Of *Mark W. Farnham
>>>>> *Sent:* Friday, January 05, 2018 8:38 AM
>>>>> *To:* niall.litchfield_at_gmail.com; andrew.kerber_at_gmail.com
>>>>> *Cc:* 'fmh'; 'ORACLE-L'
>>>>> *Subject:* RE: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> This also poses what I think is a relevant question for folks who
>>>>> place their physical RDBMS server(s) securely and only have privileged
>>>>> logons anyway. (You really can’t stop a fully privileged account from
>>>>> viewing memory or any other resources anyway and only in memory encryption
>>>>> can frustrate that if a bad actor has gained a privileged access to a
>>>>> server.)
>>>>>
>>>>>
>>>>>
>>>>> So, will there be an “insecure” patch to skip the overhead and rely on
>>>>> server access control?
>>>>>
>>>>>
>>>>>
>>>>> Then we can have a fresh round of the debate about whether “physical”
>>>>> or “virtual” is faster with the playing field thus tilted significantly in
>>>>> favor of “physical.”
>>>>>
>>>>>
>>>>>
>>>>> I also wonder for “virtual” servers whether this could be merely a
>>>>> “hypervisor” patch (which in ring security theory dating back to the 1970’s
>>>>> could establish a memory address bounded area at the privileged account
>>>>> layer (which should be a heckuva lot cheaper than a wrapper on every
>>>>> “syscall.”)
>>>>>
>>>>>
>>>>>
>>>>> DTSS is lookin’ pretty good right now. Still it was our own fault for
>>>>> not explaining clearly to enough to management that 100 million (plus)
>>>>> copies at $39.95 each was more than 12 copies at $10 million each. Sigh.
>>>>>
>>>>>
>>>>>
>>>>> mwf
>>>>>
>>>>>
>>>>>
>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>> sts.org <oracle-l-bounce_at_freelists.org>] *On Behalf Of *Niall
>>>>> Litchfield
>>>>> *Sent:* Thursday, January 04, 2018 10:58 AM
>>>>> *To:* andrew.kerber_at_gmail.com
>>>>> *Cc:* fmh; ORACLE-L
>>>>> *Subject:* Re: Meltdown and spectre
>>>>>
>>>>>
>>>>>
>>>>> There absolutely should be an OEL patch for this - for the RH kernel
>>>>> they'll probably take upstream - for UEK I'd expect an Oracle patch. I'd
>>>>> expect Oracle shops to be regression testing to determine the likely impact
>>>>> on RDBMS (and java app for that matter) performance.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 4, 2018 at 3:40 PM, Andrew Kerber <andrew.kerber_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>> I was wondering the same thing. But I dont think its up to Oracle to
>>>>> patch this, its going to be at the OS and firmware level. But everything I
>>>>> read says that its going be a huge performance hit, anywhere from 10-50%,
>>>>> and the higher end will be on IO bound systems.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 4, 2018 at 9:33 AM, Fred Habash <fmhabash_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>> Checked Oracle security bulletins but didn't find anything related.
>>>>> Did Oracle release an official statement for these vulnerabilities at least
>>>>> for the RDBMS and OEL.
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Andrew W. Kerber
>>>>>
>>>>> 'If at first you dont succeed, dont take up skydiving.'
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Niall Litchfield
>>>>> Oracle DBA
>>>>> http://www.orawin.info
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.orawin.info&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=Ent2QwI0UZIJhxZc_4tIFF6zE5BswrZloZ3PSouSC-s&s=tG0aJf6IYCqHy0hWApVNL3Fgpp7csC57ox5qflq6Org&e=>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Andrew W. Kerber
>>>>>
>>>>> 'If at first you dont succeed, dont take up skydiving.'
>>>>>
>>>>>
>>>>>
>>>>> Please visit our website at
>>>>> http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__financialservicesinc.ubs.com_wealth_E-2Dmaildisclaimer.html&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=DefUibHP8mOarbcy_Sqc0vqq2lYmneEXAHlsUQivcb8&s=Nt4EpbCt5o7Zw7ATaOlGCrtYlDrxT97Uey1C6LFQGJs&e=>
>>>>> for important disclosures and information about our e-mail
>>>>> policies. For your protection, please do not transmit orders
>>>>> or instructions by e-mail or include account numbers, Social
>>>>> Security numbers, credit card numbers, passwords, or other
>>>>> personal information.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> //
>>>>>
>>>>> zztat - The Next-Gen Oracle Performance Monitoring and Reaction
>>>>> Framework!
>>>>>
>>>>> Visit us at zztat.net
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__zztat.net&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=owvvbrhq6Z7kg7U-_DA7iMOlFl_IY0FC9C8vD3rwzL0&e=>
>>>>> | Support our Indiegogo campaign at igg.me/at/zztat
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__igg.me_at_zztat&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=_rErjKOWTCZSzV8SZaZVS6Pn6l_98ESD342VLu1FxDs&e=>
>>>>> | _at_zztat_oracle
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> -- Patrice
>>>> My profiles: [image: Facebook]
>>>> <http://www.facebook.com/home.php?#!/profile.php?id=100000206805521>[image:
>>>> LinkedIn] <http://ca.linkedin.com/pub/patrice-boivin/a/933/5a9>[image:
>>>> Twitter] <http://www.twitter.com/PatriceBoivin>
>>>>
>>>
>>>
>>
>

--
http://www.freelists.org/webpage/oracle-l