Hallo,
---
Next week Tue. 14.5. the newly founded F-Droid user-group will meet at
18:30 at Metalab. Everyone interested in Smartphones, Apps, Privacy,
Free Software, Custom ROMs, etc. is encouraged to join us.
further details: https://metalab.at/wiki/FDroidMeetupVienna
---
In einer Woche, am Di. 14.5. trifft sich die neu gegründete F-Droid
user-group um 18:30 im Metalab. Alle die sich für Smartphones, Apps,
Privacy, Freie Software, Custom ROMs, etc. interessieren sind herzlich
eingeladen teilzunehmen.
weitere Details unter: https://metalab.at/wiki/FDroidMeetupVienna
---
lg.
uniq
Hi Metalab-Community,
Mein Name ist Wolfgang Gaberl. Ich leite ein ASIC Design Büro der Firma
Broadcom in Wien 20. Wir suchen aktuell einen MitarbeiterIn für unsere
diversen Laboraufbauten und Messreihen. Die Anforderungen bei uns sind
durchwegs recht hoch und es fällt uns schwer einen geeigneten Mitarbeiter
zu finden. Nötig wären jedenfalls fundierte Kenntnisse in:
- Analoger Schaltungstechnik bis etwa 1GHz
- PCB Schematic und Layout, RF Layout, Impedanzkontrolle
- Messgeräte (VNA, SMU...), Anwendung, Gefahren, Umgang
- Programmierung eines Messaufbaus (Java, VB.net...)
- CPU/Microcontroller Programmierung
- Erstellung von Prototypenaufbauten (Überwachen und Beauftragen von 3D
Druck, Fräsen, usw...)
- Idealerweise auch Grundkenntnisse in optischer Fasertechnik
- Idealerweise auch Erfahrung mit FPGAs
Kurz gesagt wir suchen einen sehr versierten Bastler der auch die
dahinterstehende Theorie (elektrisch und mechanisch) gut versteht.
Wir würden Anfangs mit einem Werkvertrag beginnen in dem sich beide Seiten
kennen lernen können. Dafür gibt es bei uns mehrere abgeschlossenen
Arbeitspakete, die durchaus in Eigenregie zuhause oder auch bei uns
abgearbeitet werden könnten. Langfristiges Ziel ist für uns aber ein fest
angestellter und auch langfristig bleibender (!) MitarbeiterIn für unsere
Laborthemen. Den ersten Werkvertrag können wir gerne auch über Vermittler
abwickeln (Brunel).
Unten angefügt findet ihr noch eine genauere Tätigkeits- und
Anforderungsbeschreibung in Englisch.
Wer Interesse hat schickt mir bitte eine Bewerbung mit CV per Mail an meine
Mailadresse "wolfgang.gaberl(a)broadcom.com". Bitte im Betreff den Text "Job
Labor Wien" inkludieren, dann wird es für mich etwas einfacher.
Schöne Grüße
Wolfgang
--
Wolfgang Gaberl
Managing Director and Head of IC Design Team
Avago Technologies Fiber Austria GmbH
*A Broadcom Inc. Company*
office: +43 1 2288508 50 | mobile: +43 676 4069077 | fax: +43 1 2288508 99
Dresdner Strasse 43/DG | 1200 Vienna | Austria
wolfgang.gaberl(a)broadcom.com | broadcom.com
Managing Directors: Wolfgang Gaberl, Martin Weigert, Thomas Krause
Commercial Register Number: FN 261938d - Local Court: Commercial Court
Vienna
*_____________________________________________________________________________________________*
*R&D Engineer: Hardware Development Engineer, Industrial optical sensors,
Package and Test (2019-04-15)*
Want to go further in Research & Development? Here is where you take the
next step, working with the pioneering teams taking Broadcom's
world-leading products from the drawing board to the real world.
*Broadcom Vienna/Austria:*
We are based in Vienna the Capital of Austria right in the heart of Europe.
We focus on development of optoelectronic ASICs targeting fiber optic
transceivers and optical sensors for industrial, medical and automotive
applications. We are a worldwide leader in industrial fiber optics and
continuously expand our product portfolio to address emerging markets.
Therefore we intend to strengthen our team for hardware design around
optoelectronic ASICs with focus on testing and characterization.
*A typical description of the workflow and the included duties: *
· Together with the ASIC design team a measurement plan and the
practical realization for a full characterization and verification setup of
a mixed signal ASICs has to be developed
· Based on the above defined plan a measurement setup has to be
realized which includes typically
o Defining necessary sources and measurement devices
o Designing a schematic for all the necessary circuitry
o Realizing the schematic in a PCB design
o Development of software and/or firmware to run the setup
· As a starting point we already have a broad range of various
strategies and also components on hardware as well as software side which
can and should be reused for new measurement setups
· The measurement setups typically need to be fully automated
· ASIC characterization can start at sensor physics and integrating
optical and mechanical design within the measurement setups
· Analysis and debugging of low-level ASIC/sensor data
· Detailed issue description and qualified feedback to the IC
design team
· Continuous development and improvement of tests
· Contribution to modeling and simulation of electrical, optical,
and mechanical properties of sensor systems
· Issue product documentation and application notes
*Requirements:*
· A sound technical education and solid technical knowledge (e.g. a
higher technical institute HTL, university degree, etc.).
· Ideally 2+ years of experience in hardware and software
development
· Passion about electrical circuits and schematics, measurement
setups as well as solid know-how about high level measurement device
handling
*Desired proficiency in the following skills:*
· Professional experience in electrical lab environment (electrical
and also optical components and devices, typically <10GHz and low voltage)
· Expertise in high level measurement devices and their usage
· Excellent discrete circuit design know-how
· Experience with layout design, PCBs manufacturability, PCB
assembly, and circuit board start-up and test
· Experience in prototyping and electrical/optical measurement
· Sound experience in software/firmware development (currently we
use mainly Java and VB.net)
· Experience in basic mechanical setups and their design (2D/3D)
· Ideally CPU and micro-controller experience
· Ideally GAL/FPGA experience
· Broad interest in interdisciplinary work interfacing to
electronics, optics, mechanical structures, and communication systems
· Self-contained, accurate working style and ability to integrate
into teams across different functions and locations
· German and English communication skills, both verbal and written
since we are a very international focused company and team
*_____________________________________________________________________________________________*
Hallo Liebe Listen,
(verzeiht das Cross-Posting)
(Ist etwas länger, bitte ignorieren, wenn's den Aufwand
nicht wert ist. Bitte, bitte kein MS-Bashing draus machen,
nur weil Microsoft bei irgendjemand irgendwas triggert)
Das betrifft Inline Assembler in Lambda Expressions
als Parameter für Function Calls. Klingt sehr esoterisch,
ist sicher nicht daily business und nur für sehr spezifische
Szenarien relevant. Hoffentlich erwecke ich das akademische
bzw. philosophische Interesse von euch.
Mich interessiert die Meinung von "Code-Freaks" ob das im
typischen Coding-Alltag eine Rolle spielt oder es ein üblicher
Ansatz für sauberen und stabilen Code ist. Ich würde mich über
Antworten freuen, bin aber weder enttäuscht noch beleidigt,
wenn das bei euch kein Interesse findet oder der Aufwand, das
durchzulesen und eine objektive, fundierte Antwort zu schreiben
zu hoch ist.
Ich bin durch eine Meldung auf CERT.at-Discussion aufmerksam
geworden auf:
CVE-2019-0546, "Visual Studio Remote Code Execution Vulnerability."
bzw.
ZDI-19-448, Zero Day Initiative von Trend Micro.
Es geht um C++ Lambda Expressions die im speziellen Fall als
Parameter für einen Function-Call C++ Code übergeben und der
übergebene Code __asm enthält.
Meine Betrachtungen auf der CERT.at-Discussion Liste:
(Ich begrüsse auch hier objektive, fundierte Kritik)
-----------------------------------------------------------
(Übersicht als Timeline)
Oktober 2018 ist Simon Zuckerbraun (aka @HexKitchen) von
Zero Day Initiative auf einen Compiler-Fehler in MS-VS gestossen
Jannuar 2019 wurde CVE-2019-0546 publiziert:
"... Victim must voluntarily interact with attack mechanism"
https://nvd.nist.gov/vuln/detail/CVE-2019-0546
Und Microsoft hat am selben Tag publiziert:
"Exploitation of the vulnerability requires that a user open
a specially crafted file which was compiled with an affected
version of Visual Studio. In an email attack scenario, an
attacker could exploit the vulnerability by sending a
specially crafted project, or resource file, to the user and
convince the user to open the file."
Jan 2019 gibt es einen Patch für VS2017, __asm in Lambdas verboten:
Visual Studio 2017 version 15.9.5 Service Release -- released on January
08, 2018
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes
“This specific report, CVE-2019-0546, is about disallowing
inline assembly inside C++ lambda bodies. The said vulnerability
is about downloading and running untrusted code, which has always
existed in all releases prior VS2017 Update 9 that supported lambdas.
The scenario is not common coding practice and considering we've
always had this in all our prior releases and have not seen any
evidences of exploit it would not make sense to port the change
as hotfix from 15.9 to prior VS releases.”
(scheint eine direkte Nachricht an ZDI zu sein, kann keine
Ressource im Internet finden. Das Zitat ist dem untenstehen
Blog entnommen)
Februar 2019 publiziert Simon Zuckerbraun einen Blog dazu:
"The bug is triggered by a lambda expression meeting
these two conditions:
1) The lambda has an implicit capture, either by reference or by copy.
2) The lambda contains an __asm block."
Er äussert sich auch enttäuscht darüber, das MS einfach __asm in
Lambdas nicht mehr unterstützt (siehe oben) und führt weiter aus:
"I find it a bit amusing that Microsoft’s fix for Visual Studio 2017
was to remove support for __asm blocks within lambdas.
Und weiter unten:
"we still believe it worth patching and hope Microsoft reconsiders
in the future."
https://www.thezdi.com/blog/2019/2/28/finding-unicorns-when-the-c-compiler-…
April 2019 publiziert ZDI einen "Zero-Day" dessen Beschreibung
auf CVE-2019-0546 passt mit Credit HexKitchen (Simon Zuckerbraun):
https://www.zerodayinitiative.com/advisories/ZDI-19-448/
Das Datum des "initial report to vendor" ist identisch mit dem
Patch für Visual Studio.
(Meine Meinung: Möglicher Hintergrund ist, das Trend Micro mit
der Lösung von Microsoft unzufrieden ist oder dass Trend Micro
die Gelegenheit sieht Publicity zu bekommen. Es ist keine
dazu passende CVE zu finden, das scheint ein ZDI Alleingang
zu sein.)
Hintergrund Lambda Expressions:
Lambda Expression in C++ (Visual Studio):
" ...is a convenient way of defining an anonymous function object
(a closure) right at the location where it is invoked or passed
as an argument to a function."
Dabei wird ein Code-Block als Parameter für einen Funktionsaufruf
übergeben. Etwa so:
function(a, b, [] (x, y) {c-code})
\________ _______/
V
"Lambda Expression"
Wenn die Lambda Expression __asm enthält dann crasht das
bei Visual Studio, deshalb disallowed im Patch.
https://docs.microsoft.com/en-us/cpp/cpp/lambda-expressions-in-cpp?view=vs-…
-----------------------------------------------------------
Meine Vermutungen, Fragen, Bitten:
Vermutung:
Eine Lambda Expression als Parameter mit Inline Assembler bietet
kein klar definiertes Environment für Assembler Code im Gegensatz
zu Inline Assembler innerhalb einer normalen Function Declaration.
Frage:
Wie verhalten sich andere C++ Compliler in der selben Situation?
llvm, gcc, g++ etc?
Bitte:
Wäre es unverschämt zu fragen, ob eine Hackerin oder ein Hacker
ein kleines C++ PoC zu schreiben? Mein Coding ist zu eingerostet
und ich hab keine Erfahrung mit Inline Assembler.
Liebe Grüsse und danke im Voraus,
MiKa
