Re: Meltdown and spectre

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